Web Services Resource Access Working Group Teleconference

11 Mar 2009


See also: IRC log


Ashok Malhotra, Oracle Corp.
Asir Vedamuthu, Microsoft Corp.
Bob Freund, Hitachi, Ltd.
David Snelling, Fujitsu, Ltd.
Doug Davis, IBM
Fred Maciel, Hitachi, Ltd.
Geoff Bullen, Microsoft Corp.
Gilbert Pilz, Oracle Corp.
Jeff Mischkinsky, Oracle Corp.
Katy Warr, IBM
Li Li, Avaya Communications
Mark Little, Red Hat
Sreedhara Narayanaswamy, CA
Sumeet Vij, Software AG
Tom Rutt, Fujitsu, Ltd.
Vikas Varma, Software AG
Wu Chou, Avaya Communications
Yves Lafon, W3C/ERCIM
Bob Natale, MITRE Corp.
Prasad Yendluri, Software AG
Ranga Reddy Makireddy, CA
Bob Freund, Hitachi, Ltd.
Vikas Varma, Katy Warr


Agenda approval done

Editor's draft review

Asir: Use CVS notification for a checkin...to review.

<dug> for some reason why cvs won't send in my cvs update comments

<Yves> also I can make a snapshot at a specific location, easy to do

<dug> well, just doing a cvs diff by date works too

Asir: Use CVS labels and compute automatic diff.

<Yves> yes, we could do a "make snapshot" "make tags" etc...

<asir> what about a diff version

Bob: make a snapshot once a month.
... Asir help the editors to compute the diffs

<Yves> there should be a diffspec.xsl as well

<Yves> http://lists.w3.org/Archives/Public/public-ws-resource-access-notifications/ is indeed only for bugzilla now, I can make it extended to add cvs commits

<scribe> ACTION: Yves notification setups [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action02]

<trackbot> Created ACTION-38 - Notification setups [on Yves Lafon - due 2009-03-18].

The working group agrees to monthly review of snapshots.

Asir: Suggested to have summary of change logged at bottom of spec.

Resolution: Add change log at bottom of each spec.

Bob: Executive summary of changes log for public?

Dug: Who will maintain it?

Bob: Look into the executive summary option later.
... First snapshot review - April 1st

Resolution: First snapshot review - April 1st.

Issue-6400 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6400

<Bob> Revisit 6400 due to request for overnight review

<Bob> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0051.html

Li: Change subscription & port to Subscription & Porttype.

<li> change SubscriptionEndPort to SubscriptionEndPortType

Resolution: Resolve 6400 by changeing SubscriptionEndPort to SubscriptionEndPortType in the previous tentative resolution

Issue-6500 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6500

Geoff: Proposed close with no action

Dug: Want to keep GetMetadataResponse for consistency across spec.

<li> EndTo endpoint cannot use wrap interface to receive SubscriptionEnd message because it is a protocol message, not an event message

<dug> <mex:GetMetadataResponse ...>

<dug> <mex:MetadataSection...> ... </mex:MetadataSection> *

<dug> xs:any *

<dug> </mex:GetMetadataResponse>

<Bob> For minutes edit, move Li's comment above start of issue-6500 discussion

Alternative proposal by Dug above

<Bob> It was noted that extensibility is already in the schema, but not in the text

<Bob> Dug: In that case it gets down to just re-naming the element

DaveS, Asir asking for use cases.

<Bob> Dave: What are the use-cases for extending the response?

Katy: Don't rename mex:metadata.

<dug> Katy: go back to original proposal

Bob: Any objection to the proposal.

Geoff: Object, 6398 need to be looked at first.

Gil: No need to add dependency on 6398.

Bob: Any objection to the new proposal?

Geoff, Asir object, asking for more time

Doug Ashok : How much time is required.

Dug: Agains adding dependency of 6398 in 6500.

Gil: Time line to put forward formal objection for 6398?

Bob: Will look at 6500 later.

Issue-6413 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6413

<Katy> proposal at http://www.soaphub.org/public/files/w3c/t-rt-merge-v2.doc

<Yves> why defining Dialect as an attribute and not as a child element of wst:GET ?

<dug> yves - could be done that way - but there some concern from MSFT folks when we first worked on that they wanted to be able to detect an unknown dialect asap and an attribute was easier than going down one level.

<Yves> dug - what is the namespace of Dialect attribute then? having a wstr:dialect element sounds easier as an extension point than adding an attribute in wst: everytime you want to do such add-on

<dug> well, since we believe that RT will be fundamental to T's use it makes sense to have it part of the same namespace

Geoff: Why are we doing it, as of now there are no issues raised regarding WS-Transfer and WS-RT complexity.

Dug: WS-RT only makes sense in presence of WS-Transfer.

<Bob> Dug argues (amongst other things), that RT reduces the need for transactional support, since it would reduce collisions

<Bob> Dave: If they were written together then the inconsistencies would be resolved, but then ought to be split

<DaveS> 1) Generally splitting is better.

<DaveS> But:

<DaveS> 2) Consistency is needed between T and RT. Merging will fix these.

<DaveS> 3) Prevention of rouge extensions that duplicate RT function.

<DaveS> 4) Interaction semantics between the two capabilities is more transparent.

<DaveS> 5) Encourage wider uptake of the full capability of T + RT.

<DaveS> - Develop together and the split

<DaveS> - Restrict transfer as we split them so as to capture semantic interaction,

<Zakim> asir, you wanted to talk about the history

<Wu> "<DaveS> - Develop together and the split" - Do you mean "Develop together and then split"

Asir: -Duplication, overlap, needs to be handled on case-by-case bases.

<DaveS> yes: Develop the specs together to clarify semantics, overlap, common issues. Then split if the result really looks to complex.

Bob: I am against fully merging the two specs since those who do not wish the functionality in RT may want to implement onlt T without the uncertainties of interop problems caused by optionality.

<Katy> Adding to Dave's list above

<Katy> 6) From Editorial and WG point of consolidating proposals across the 2 specs is far easier (wrt time and effort) when they are merged

<Yves> is dialect fragment or conneg?

<dug> http has fragment support

<Bob> http frags are a user agent function

<Zakim> asir, you wanted to respond to Doug

<Zakim> Yves, you wanted to say is dialect fragment or conneg?

<dug> +1 to yves - transfer is missing a ton of http features

<asir> +1 to Yves for using SOAP extensions

<asir> that is what Resource Transfer does today

Katy: IBM has implementation of WS-RT.

<Geoff> +1 to dug for RT not being as mature at T

<dug> bob - I was referring to the http range headers not the user-agent stuff

<Katy> My comment was: we were reluctant to implement rt due to bp compliance issues with the wst base spec

DaveS: Obligation of smooth transpiration for present implementation.

<Yves> if it is a fragment, should it be part of the EPR?

Bob: Important considerations

1 - Common stuff should be commonly defined.

2- RT Fragments, is an extension; is it a common operation; is it an optional feature?

3- Some RT Features have questions, problems, unclear, broken

<Geoff> is the value of doing this work, greater than the amount of work required to achieve it?

Bob: Does the working group consider frags to be an extension?

<scribe> ACTION: Katy produce a document on frag support as an extension. [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action03]

<trackbot> Created ACTION-39 - Produce a document on frag support as an extension. [on Katy Warr - due 2009-03-18].

<asir> I promised to add my statements on 6413 to the IRC

<asir> here it is

<asir> If there are any overlap between T and RT, those should be identified as separate issues and resolved

<asir> If there are any duplication between T and RT, those should be identified as separate issues and resolved

<asir> If there are any inconsitencies between T and RT, those should eb identified as separate isseus and resolved

<asir> if any of the current RT issues apply to Transfer, the WG will address them across specs

<asir> We acknowledge the 2 possible cases - simple use case and non-simple use case. We have seen umpteen impls of the simple use case and we have plenty of interop evidence. We do not not seen any implementations of the non-simple use case.

<asir> If any of the RT issues (filed by Microsoft) apply to Transfer then the WG would consider that and address it as well. This is similar to how the WG processed 6428 against Eventing whose resolution was applied to all 5 specifications

<asir> Re bunding specs will increase market adoption and interop - this is a myth. Market adopts value not required and optional features. Bundling is not the solution

<asir> Re WS-Man created a domain specific fragment transfer - RT was born in 2006. WS-Man was born in 2002. It is common for a feature to be born in a domain specific way and then promoted in a generic manner at a later date

<asir> RT did not carry the consensus of the authors during its dev and submission (only IBM and Intel submitted, Microsoft and HP did not).

<asir> There wasn't consensus to add RT to the charter ...

<asir> RT frag transfer is an extension of Transfer (from the SOAP Processing Model point of view)

<asir> In order to not burden current dependant specs on Transfer we believe that the extension should be in a separate specification

<Bob> scribe: Katy

Follow up to Tag/Mex RT conversation

Asir: Ashok polinted out may not get response for tag
... from tag
... Bob suggested waiting until the last call review
... we are concerned about time and following the Tag discussion
... What we could do is put each issue in bugzilla and consider proactively addressing each of the issues
... then Bob could take these issues to the tag
... We volunteer to get these issues out and propose draft resolutions

Ashok: There are 2 issues 1) why WS use EPRs rather than URIs? What answer should we give?
... 2) We could consider what does a naked HTTP GET on the URI return?

Gil: Think we should address any issues at LC and not pre-empt

DaveS: Don't want unecessary energy spent on this.

Asir: Understood, concerned about potential blocking issue

Bob: Being prepared is good. I am hearing mixed discussions regarding how much preemptive work should be done
... If we use the issue process (this is public and debated and requires closure before last call).
... These are not proper issues yet- there are other ways to approach

DaveS: We can prepare a document and discuss at next F2F
... I will work with you on this.

Ashok: Issues in a WG are opened against documents, what would these issues be opened against

Asir: WS-T (2) and WS-RT (1)

Ashok: What could we say here

Asir: We could say: for 1st issue: This has been considered by the ws-ra working group and this is what we have decieded (unified voice)
... for 2 propose: SOAP response pattern binding to HTTP GET

<Yves> see http://www.w3.org/TR/soap12-part2/#soapinhttp

<scribe> ACTION: Asir and DaveS to collaborate on a discussion document about how to proceed [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action05]

<trackbot> Created ACTION-40 - And DaveS to collaborate on a discussion document about how to proceed [on Asir Vedamuthu - due 2009-03-18].

Issue-6399 Output only in WS-Enum

Dug: Propose same solution that we accepted for WS-Eventing subscription end

<dug> proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0054.html

<dug> and change EnumEndPort to EnumEndPortType

Bob: no objects

RESOLUTION: 6399 resolved

Issue-6595 WS-Eventing Specify behaviour for empty filters

<dug> proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0055.html

<dug> an amendment: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0056.html

Gil: described issue
... Dealing with filters that will never evaluate to true - event sources should try to indicate this

Geoff: As Doug said, we need to ensure that it is clear that the generation of this fault is only at subscribe time

Wu: Concerned that the client may use this to test what the event source supports - interop issues

Gil: This is for simple situations where the filter is easily understood

<Bob> It is possible for the request to contain a filter that will not evaluate to true for the lifetime of the Subscription. Although this condition cannot be detected for all dialects, implementers are advised to check for it when possible and, in response to the Subscribe request message, OPTIONALLY to a Subscribe request

<Bob> message generate a wse:EmptyFilter fault.

<dug> It is possible for the Subscribe request to contain a filter that will not evaluate to true for the lifetime of the Subscription. Although this condition might not always be detectable, implementers are advised to check for it when possible and, in response to a Subscribe request message, OPTIONALLY, generate a wse:EmptyFilter fault.

Wu: not sure about 'impls advised to check for this'

Gil: It is just advice

Wu: But this is not preferred

Li: I recognise that this is a very annoying situation but it's hard to imagine how implementations could check this - e.g. xpath

Gil: This is intended for filter dialects with finite values. Just when it's possible. Impls could do basic checks
... A key thing is to advise subscribers that an extra fault could be gen'd when it is clear that there will never be notification messages

Wu: I am concerned with wording still - 'advised' text

<scribe> ACTION: gpilz work with Wu on text for 6595 [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action07]

<trackbot> Created ACTION-41 - Work with Wu on text for 6595 [on Gilbert Pilz - due 2009-03-18].

Alternate proposal for 6429

Gil: Outlined key aspects. EventTypemsg in its own schema plus attribute extensibility
... in wsdl dfn notifyEventMessage has hdr notify verb and body notify element
... in soap binding hdr part is bound to soaphdr and body bound to soap body
... Motivation was to put metadata in header. wse:NotifyVerb in header - tooling will expose this verb as a parameter
... for e.g. msg bus scenario

dug: This proposal splits the service level data between the body and the headers
... This concerns me and I would like some time to discuss with implementation teams
... 1 week's delay

Wu: I propose separate this into 2 issues: 1 agree to have standard interface and separate issue of where to put the action

Geoff: Agreeing with Doug again! Would like time to consider also

gpi: we need crisp texts prior to closing this issue, this proposal is just the form

Wu: Let's close what we have decided and separate out a new action in order to deal with the extended proposal

Gil: The current proposal is not complete for incorporating into the document. Would be nice to have text describing when wrapped would be good.

Wu: Explanationary text should be in primer

Gil: reference to format in appendix would help

Wu: we can create text changes

<gpilz> other probs with current text for 6429: (a) text discusses including the "concrete WSDL" in wse:NotifyTo, how is this done?

<scribe> ACTION: Wu to examine current spec and generate new text for group review [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action08]

<trackbot> Created ACTION-42 - Examine current spec and generate new text for group review [on wu chou - due 2009-03-18].

Li: Could the verb be a ref param?

Gil: No because the notification type is a constant across the lifetime of the subscription

<gpilz> (b) text says "concrete WSDL can be retrieved by the Event Source use WS-MEX" how?

Li: Agree with Wu that we should close this issue and treat the enhancement as a sep one


Li: This is the proposal that treats the format as an element (rather than an attribute)


Dug: Would like to see text describing processing order - filter should be on unformated event

Wu: Agreed this is a good comment. Another issue though.

<scribe> ACTION: Dug to open a new issue for this [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action09]

<trackbot> Created ACTION-43 - Open a new issue for this [on Doug Davis - due 2009-03-18].

Geoff: What if can't support format element

Dug: It is an optional element that must be understood
... text decribes that the implied value is unwrapped
... must process or send a fault - not just ignore

Asir: It needs adding to migration path

<asir> migrationPathNeeded

<Yves> "The keyword migrationPathNeeded has been added."

<asir> All hail to the power of consensus!

RESOLUTION: 6428 is resolved

Issue-6431 WS-Eventing add resume subscription

Li: Subscribe has authentication and authorisation costs so overhead if you need to unsubscribe/resubscribe
... 3 way handshake required
... pause and resume will reduce this cost

Dug: On overflow do you retain 1st 5 or last 5
... for interop should specify


Dug: Consider adding a line one way and change it later if required?

Geoff: Do we need to discuss the value of adding pause and resume?

Wu: value of pause and resume is highlighted in web services roadmap document (item 5)
... We think this is useful. I am sensitive to Geoff's comment so we could make this an optional feature

Dug: 2 things that should add to proposal. 1) clarify whether buffering of msgs happens before/after filtering
... 2) Retain parameter on pause and response. I would prefer the pause to fail if the request cannot be granted

Geoff: would like time to consider

<asir> perhaps, in another specification

Ashok: This is extra functionality, not fundamental to the core spec

DaveS: If client does not have pause/resubscribe then can it attain same function by unsubscribe/subscribe

<Bob> k

Wu: pause/resume is a short hand so does not break interop (as it's a shorthand for unsub/sub) but retain message number is not shorthand

gpilz: how would I know whether event source supported pause resume?

Dug: policies

Wu: this is optional

More time for decision requested

<scribe> ACTION: Li to address Doug's 3 concerns [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action10]

<trackbot> Created ACTION-44 - Address Doug's 3 concerns [on Li Li - due 2009-03-18].

Issue-6498 Define the fault action URI


RESOLUTION: 6498 Resolved as defined in proposal (editors update uri name)

Issue-6404 Mex dialect

Dug: Mex dialect=group of things that service should return to client to indicate what's needed for communication
... but what if the service has metadata that the client might need (but client doesn't know about)
... At extensibility to enable service to add this 'extra' metadata stuff
... on top of that add 'all' dialect
... then worry about default

Geoff: Our 'whateverdialect' = Doug's Mex dialect

<dug> 'whateva' used to mean "random - even zero"

Geoff: also think that there should be a just mex dialect
... mex=the mex dialects
... whatever=the mex dialects plus optional extras
... mex=mex defined dialects crucial=mex plus other stuff that need to talk to service

gpilz: Should rename 'mex'

<gpilz> 'mex' should be renamed 'defined'

gpilz: Confusion is when a bag of dialects is named the same as a dialect itself

<gpilz> from smallest to largest (schema | wsdl | policy | policyAttacment), defined (set of previous), crucial (defined plus sections requester may not know about), all (everything available to the provider)

Dug: The 4 dialects in the metadata spec are fairly arbitrary. Also they can be gotton by separate requests. So the 'mex' (or 'defined') dialects is not much use.

<dug> none = mex = the stuff the services thinks the client needs to talk to it - minimum = tables in mex

<dug> all (new uri) = everything under the sun the client is allowed to see - ie. dialect=*

asir: Interop testing refer to proposal for 6420 (closed as dup of this one). This proposal talks about min

Dave: I like the idea that the service knows what you need to talk to it
... eg if I don't need policy documents - why would I return them?

<marklittle> Hi Bob

<Bob> Hi

Dug: There's a difference between returning anything and what's required by the client to talk

<Bob> ?

<Bob> Katy requests time to conferr with the mothership

Katy: Concerned about the overlap of these dialects - the same information may be passed back in policy and wsdl dialects - a huge amount of data in duplicate
... Puts great requirements on service and large data transfer

<Zakim> asir, you wanted to answer Katy's q

<DaveS> If we had only all and default (meaning what the service thinks the client needs), what interop or migration problems does this raise?

Ashok: Not clear where policy documents should be returned on receipt of policy dialect

Katy: policy and policy attachment dialact not clearly defined

Asir: Policy references give the link to the policy documents
... policy dialect is not useful on its own but is useful in a wider exchange

Dug: concerned that we are overengineering and will confuse people

<asir> well .. at the discretion of a provider .. you may or may not return duplicates

Dug: no longer a for-loop service needs to interpret

<asir> other specifications may define these dialects ..

Geoff: Don't let us forget the key issue - the communication bootstrap 'what do I need to talk to you'

<asir> but for the standards that have already sailed and relevant to WS should be specified in this doc

gpilz: just two different things 1) individual dialacts and 2) bootstrap info

bob: we need to write up and understand
... few primer words to describe expected usage
... (primer like - might be doesn't need to be in primer)

katy: Issue for describing dialect uri's


bob: The critical set is what the provider needs to communicate?

consensus to this.

bob: do we agree that 'all' is useful?

dug: Use case metadata browser

ashok: or another non-specified dialect (e.g. legal)


bob: is it true that a provider can provide optimisation?

consensus to this.

bob: What about the current 'mex' which is a subset of all?
... do we need to define this piece called 'mex'?

<asir> that was awesome Bob!

<dug> none==critical, all=all, allow for list of dialects

<Bob> Agreement:

<Bob> no dialect == everything that the provider considers important with the ability to optimize

<Bob> dialect="ALL" == all known metadata with ability to optimize

<Bob> one can specify a dialect list on the getmetaadatarequest

RESOLUTION: issue 6404 resolved

Issue 6418


Geoff: This may no longer be valid now that we are specifying the format
... But clarifies if the (optional) content is not there, then the service decides

Dug: Is this a duplicate?

Asir: it's superceded by another issue

RESOLUTION: superceded by 6405, no editorial action required. Issue closed.

Issue 6533 - safeness of operations


Yves: Part of semantic alignment between http and transfer. Work out whether you can retry a request

asir: concerned that the contents of the table is not there - i.e. for each operation state what is safe and what is not

<asir> also we need to see the wording from RFC 2616

<Yves> proposal is getting inspiration from http://tools.ietf.org/html/rfc2616#section-9.1

<asir> agree .. suggest that we prep a concrete proposal prior to closing

Dug: clarification required. Yves - is there something in the spec that would lead you to believe that the transfer get is not safe?

Yves: The spec says nothing so it is not clear.

Bob: and proposal was inspired by RFC 2616

Dug: The spec already implies to me that there is no side effects to a get. What is broken?

Yves: Nothing broken, would just like this explicitly stated

<asir> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0045.html

Asir: proposal above

<Yves> after a first delete, you may have an error, but in both cases the resource won't be there ;)

<Yves> but it would be abusive to say that the second delete would result in an operation on a resource

<Yves> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-06#section-7.1

Asir: Should steal 2616 def - Get is idempotent and safe; put and delete are idempotent

<Yves> "A sequence that never has side effects is idempotent, by definition

<Yves> so doing nothing on a second delete is idempotent

<Bob> +1 Yves

Dug: I agree that we should have the table and as an editor would like the whole text so can just cut-and-paste

<scribe> ACTION: Yves to create red-line text for this issue [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action11]

<trackbot> Created ACTION-45 - Create red-line text for this issue [on Yves Lafon - due 2009-03-18].

<Geoff> thanks everyone, thanks Bob and host IBM, signing off now...

<asir> +1


Geoff and Asir request time to think.

<Bob> short break

<dug> http://www.dannysbarbque.com/html/morrisville.html

Issue-6641 Where we get the XSD


<Ashok> This document is also available in these non-normative formats: XML, XHTML with visible change markup, Independent copy of the schema for schema documents, A schema for built-in datatypes only, in a separate namespace, and Independent copy of the DTD for schema documents. See also translations.

<Ashok> http://www.w3.org/TR/xmlschema-2/

<Yves> http://www.w3.org/2003/Editors/

<Yves> is the best play to find out

Dug: propose namespace still points to rddl, rddl points to everything, end of spec reference to xsd is a direct uri
... (as in proposal above)

RESOLUTION: Resolved 6641 as described above

Summary of Action Items

[NEW] ACTION: Asir and DaveS to collaborate on a discussion document about how to proceed [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action05]
[NEW] ACTION: Asir/Dave to collaborate on a discussion document about how to proceed [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action04]
[NEW] ACTION: Dug to open a new issue for this [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action09]
[NEW] ACTION: Gil work with Wu on text for 6595 [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action06]
[NEW] ACTION: gpilz work with Wu on text for 6595 [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action07]
[NEW] ACTION: Katy produce a document on frag support as an extension. [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action03]
[NEW] ACTION: Li to address Doug's 3 concerns [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action10]
[NEW] ACTION: Wu to examine current spec and generate new text for group review [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action08]
[NEW] ACTION: Yves notification setups [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action02]
[NEW] ACTION: Yves to create red-line text for this issue [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action11]
[NEW] ACTION: Yves, notification setups [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/03/14 14:32:58 $