OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Prelim minutes of WSRM TC 5/11 TC meeting

the prelim minutes are attached.

Please send any corrections to the list.

Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003

Prelim Agenda of WSRM TC Conference Call –May 11, 2004


The meeting of the WSRM TC  will take place by teleconference 

Tuesday, May 11, 2004, from 5:30 to 7:30 PM Eastern Standard Time

(UTC - 5)



1         Draft Agenda:

Draft Agenda to WSRM TC Conference Call

1 Roll Call

2 Minutes Discussion

2.1 Appointment of Minute Taker

2.2 Approval of previous meeting minutes –

3 Action Item Status Review

4 Discussions of unresolved editorial comments

5 Discussion of Document progression

6 Discussion of FAQ for WS-Reliability


2         Roll Call


First Name

Last Name




Voting Level





University of Hong Kong






Sun Microsystems






Sun Microsystems




































NEC Corporation






NEC Corporation















































TC Chair







Cyclone Commerce






Booz Allen Hamilton




 Meeting  isquorate.


3         Minutes Discussion

3.1      Appointment of Minute Taker

Tom Rutt will take minutes.


Minutes will serve to record issue resolutions.

3.1      Approval of previous meeting minutes


The corrected minutes (correcting the statement by Sunil on composibility) for the f2f are posted at:


Alan moved, Joe C seconded.


No opposition, minutes approved.

The minutes of the May 4 teleconf are posted at:


Need to add Jeff M to the attendance list for the May 4 telecon meeting.


Post new minutes with Jeff’s name on we will vote next week.

4         Status of Action Items

  ·  action item list from 5/4 meeting
From Tom Rutt <tom@coastin.com> on
6 May 2004 16:48:06 -0000


4.1 Action editors-1  (Marc and Doug) Pending
Marc G and Doug B to updated issues list to reflect agreements in CD .992.
- open
Tom send email again on changes required.
4.2 Action 042904-1  (Tom and Iwasa) needs discussion
Action: Iwasa and Tom will provide text for the new fault code and the 
reference to it in the section of text Alan cites.
Added GroupAborted error code to draft .996, however the paragraph which 
was cited to add the MUST return sentence was deleted. Did not add a 
sentence. Could add the following sentence somewhere:
When group processing is aborted, the Receving RMP MUST return 
GroupAborted fault for all non-delivered messages which have not had an 
RM reply sent.
4.3 Action 042904-3  (Jacques) Pending
Jacques took an action item to propose this new subsection on special 
considerations for wsdl request/response operations.
Will incorporate into next draft.
4.4 Action 042904-4  (Jacques) Pending
Jacques took action item to add appropriate text to also clarify that an 
RM-Fault must be returned if the message cannot be delivered because the 
requested reply pattern is not supported
leave open 
4.5 Action 042904-7  (Iwasa) needs discussion
Action: Iwasa to apply all editorial changes from Tonys mail, except 
for those he considers in need of discussion.
Completed on 4/30, there are a few comments that require further 
discussion at May 4 TC teleconf.
   Closed, will discuss items from Tony.
1.6 Action 050404-1 (Iwasa)
Action on Iwasa to add new annex pointing at schema with the 
disclaimer of precidens.
4.7 Action 050404-2 (Iwasa)
Action: Iwasa should check if item 7.13 is done.
4.8 Action 050404-3 (Iwasa)
Action iwasa needs to clarify resolution of item 10.3.
4.9 Action 050404-4 (Iwasa)
Iwasa has action item to update figures to get rid of application layer.
4.10 Action 050404-5 (Iwasa)
When used with soap 1.1, the soap1.1 mustUnderstand attribute MUST be 
present with value equal to 1 in all RM header blocks.
When used with Soap 1.2, the soap1.2 mustUnderstand attribute MUST be 
present with value equal to 1 in all RM header blocks.
Also: Version number should be in the title of the document as version 1.1.
Joe Chiusano moved to accept this change, Bob F seconded.
No discussion.
No opposition, motion passes.
Aleady been applied to schema and text.
Iwasa: action to ensure the two statements are included. Incorporate 
version 1.1 in title of spec.
4.11 Action 050404-6 (Iwasa and Tony G)
Action: Iwasa and Tony should work to resolve Tonys non resolved comments
4.12 Action 050404-7 (Iwasa and Jacques)
Jacques, took action, with Iwasa, to produce a new editors draft .997 
by Friday. Indicate which public review coments are resolved.



5         Discussion of Issues and editorial Comments

The following issues list includes open items which need further discussion:



5.1      PC7.1 Targeting headers


·  about "next" role/actor
From Jacques Durand <JDurand@us.fujitsu.com> on
5 May 2004 19:31:28 -0000

Title: about "next" role/actor


Should we say anything about the use of "next" role/actor on RM headers?

> (Pete Wenzel) Line 98: Says "This specification addresses end-to-end reliability,

> and is not concerned with intermediaries." However, there is nothing to

> prevent someone targeting Reliability headers to "next" role/actor.

> This case should be explicitly forbidden, rather than left undefined.


The use of "next" seems inappropriate in general, as our model ignores intermediaries.

However I would not forbid this:

after all, the receiving party may have deployed several SOAP nodes to process incoming messages, the first one being supposed to handle reliability. So this may be a topology that is assumed between sender and receiver, even if an unlikely one. (E.g. we could imagine that there is a reliability contract between each pair of intermediaries.)



warn that reliability headers should not be targeted to SOAP intermediaries, unless it is the intent that the reliability contract  precisely ends at the first intermediary.




Jacques: Peter Wenzel remarked that it would not make sense to target an rm header to the next role.   Peter Furniss complained about this strict restriction, especially when a soap node may be a gateway implementation.


Tom: will it be normative.


Jacques: I propose to place some text in the messaging model section regarding implementation transparency.


Tom: is this intended to be an editorial clarification.


Pete: Peter Furniss scenario of non reliable from intermediary to ultimate recipient.  I am willing to allow that situation.


Doug:  I am not entirely sure if it is reasonable to go beyond our original requirement.  I am worried about text on the document, without review by the group.  On the underlying issue, we accept as group that we allow intermediaries, but I am worried about adding.


Tom: would leaving the text as is satisfy Pete W.




Motion to resolve issue as close with no change, seconded by Doug.


No opposition, motion passes..



5.2      PC9.2 Group Aborted Fault


·  RE: [wsrm] Number of fault messages to send after the receiver aborts ordered delivery for local reasons
From "Alan Weissberger" <ajwdct@technologist.com> on
5 May 2004 22:25:31 -0000



I agree with your rewording below



----- Original Message -----

From: Jacques Durand

Date: Wed, 5 May 2004 13:31:45 -0700



"After sending 5 abort faults in response to 5 received messages after ordered delivery has been aborted for the group, the receiver will stop sending the abort fault."


that is better, yet could be worded something like:

-  "receiving RMP MUST publish a GroupAborted fault for each one of the 5 first messages received for the aborted group, and MAY do so for subsequent messages." (so it is possible to accommodate other policies, e.g. exponential back-off. Also "publish" accommodates "poll" cases.)


We might still have a general provision for handling denial of service attacks (not just in hat case), that say that in case  of suspicious pattern of communication that creates an obvious burden on the receiver, the receiver may decide to drop

any sending duty required by this spec, and send another special fault about this ?



Tom: why not three.  The SNMP word, rpc on top of udp, uses three resends.
Jacques: keep faulting for every new message, but not do this forever.  If it is obvious the sender is igmoring the faults, this group abort fault would not be sent again.  This number, 3 or 5 , is the minimum the receiver is required to send for each message.
Tom: I am concernte that this should be a profiling decision.
Doug: this group aborted fault occurs only when the group has been aborted, but has not been cleaned up.  I think it is inappropriate that if the receiving system crash immediately after aborting the group, that it be required to remember the ability to send that fault.
Tom: I agree with Doug.
Jacques:  The origin of this issue was that group aborted fault only makes sense that the group is still active on receiver side.


All processing for the groupID associated with the

reliable message request has been aborted by the

Receiving RMP.  No subsequent messages within

that group will be delivered by the Receiving RMP.

Jacques: I am happy with the definition of the fault as is. No additional text required to resolve this issue. If we add text for one fault type, do we have to add it for the rest.  
Tom: Issue on not supported feature: this is application specific, leave to profiles.  

Ø Action: Tom will reopen issue on not supported feature fault for discussion at next week meeting.

Bob F: I agree this detail can be left to profiles.
Jacques: this is not critical to the reliablility protocol.  An implementation would still work if it sends no faults at all.  Faults could be viewed as convenience feature.  We need to be consistent across the spec.
Bob F Moves that group abort issue is already Resolved by draft .996, Iwasa secondse.
No opposition motion passes.

5.3      Editorial comments from Tony Graham (items PC11.x)


Mail from Tony Graham:


·  Re: [wsrm] New Editor's draft .996 posted (with Jacques Refactoringchanges)
From Tony Graham <Tony.Graham@Sun.COM> on
3 May 2004 22:30:18 -0000


5.3.1      PC11.6


1. Line 178: example.org


   example.org (and example.net and example.com) are reserved for

   examples and documentation.  See

   http://www.rfc-editor.org/rfc/rfc2606.txt for the explanation.


   Using example.org makes it obvious that it is an example and avoids

   any conflict with a domain name that is in use or will one day be  in use.






Tony Graham


Title: line 178 of .993

Description: section 1.5 line 178 Change "wsr-example.org" to "wsr.example.org" or "example.org/wsr" toproperly use the "example.org" example domain name.

Proposal: Pending. Is it allowed to use _example.org_? wsr-examples.org was not registered yet the point of I picked up, so it is no problem so far. Need to make sure with example.org domain for its use

Resolution: yes we are shoulg use example.org/wsr


Ø Action: Iwasa to apply PC11.6 resolution

5.3.2      PC11.11


2. Line 288, 304: Why must the time be identifiable?


   I would like this to be explained to me.







Tony Graham


Title: Section 1.6 line 288, 304

Description: Why must the time be identifiable? Why is it not sufficient to just preserve the order of submissions, e.g., in a queue?

Proposal: Need resolution. (Not applied)Proposal: replacing _The time_ with _The order_



Ø Action Tony will take PC 11.11 to email discussion


5.3.3      PC11.14


3. Line 329: Reliable Messaging Fault Indication for failure to

   receive a message


   Another thing that I would like explained to me.







Tony Graham


Title: line 329 of .993

Description: How can a "Reliable Messaging Fault Indication" signal a failure to receive a message when this specification "expects that the transport layer will not deliver a corrupted message" (line 1308) and there are no fault codes for non-delivery of messages?

Proposal: Needs resolution.



Tautology, if not received how can it give a fault.


Remove “to receive or”    


Doug: it is a failure to invoke the deliver operation.


It signals to the Sending RMP of the referred message that there

was a failure to invoke the deliver operation for the message.


Agreed editorial.


Action: editors will place into next draft.


5.3.4      PC11.15


4. Line 366


   My comment had to do with the sentence construction.  Looking at

   the comment in the preliminary minutes, it seems likely that the

   sentence will change anyway.






Tony Graham


Title: line 336 of .993

Description: A reply may now include multiple Acknowledgment Indications.

Proposal: Needs text, if required.






Tony Graham


Title: line 366 of .993

Description: "between the application layer, the sender and receiver RMPs" does notscan.

Proposal: Needs discussion. I believe we shouldn_t mention RM is a contract between application and RMP. Reliable Messaging is for between Sending RMP and Receiving RMP only, but not application and RMP. We can_t guarantee the delivery to the application and should not do that when we don_t define neither protocol between RMP and application, nor RMP API. Even in the ordering case, we don_t guarantee the delivery of a message to the application, and it is completely appropriate. In conclusion, we should not say the RM agreement is an agreement between application and RMP. Sending RMP can_t and shouldn_t guarantee the delivery of a message to the application.



The line 336. has nothgin to do with multiple acks


Tony: Action to send to the list the exact change required on the .996 text.

5.3.5      PC11.2

5. Line 388, 390, 392


   My braino.  It should be "Change 'details' to 'details.'." but I

   was thinking too much about periods so the wrong word came out.







Tony Graham


Title: Section 1.7.2, RM Agreement Items

Description: Line 388, 390, 392Change "period" to "period.".

Proposal: I don_t understand this comment. Need clarification




Ø Iwasa: action to add period if missing for PC11.20


5.3.6      PC11.24





Tony Graham


Title: Section 3, Reliability Features

Description: "Business payload" is undefined.

Proposal: Line 499Needs definition for Business payload or replacement text

Resolution: still open

5.3.7      Misc






Tony Graham


Title: section 1.3 notiation conventions

Description: section 1.5 - xml declarations in example

Proposal: Remove the XML Declarations since they are unnecessary. This was kept in the example, since it is necessary when example includes HTTP header, according to Sunil_s comments



Tony: we could leave to the Editors. 


Doug: the xml declaration is an optional part of an xml instance.  Soap does not require the xml declaration.  As long as it is in utf-8 any parser should work.


Suggested  to remove to xml declarations in the examples.


Leave open have discussion on email.






Tony Graham


Title: Lines 229, 260, 262 of .993

Description: Use 'straight' quotes instead of 'smart' quotes around attribute values.

Proposal: Kept them as-is for consistency with example1 ,2 and 3



Doug: smart quotes make the examples invalid.  They are not allowed in XML examples.


Ø Action: Iwasa will turn smart quotes to normal quotes.  Tom will send the required edits to remove smart quotes to Iwasa


Agreed not yet applied.


Tools autocorrect need to be fixed.


5.4      PC13 HTTP POST as Mandatory






Tom Ruttl


Title: HTTP POST Binding Clarification

Description: We need to clarifiy that the mandatory binding in the spec is to use htttp post.This is not stated clearly.In fact we need to clarify the exsting lines 1310, 1311, 1312"(3) The Acknowledgment Message is sent with another HTTP connection from the Receiving RMP to the Sending RMP. Example 15 is an example of this message.(4) The HTTP response for (3) has no HTTP message body. Example 14 is an example for this HTTP Response."to require an http post request.This clarification is needed, for interoperability, to avoid the use of http get when http post is expected.

Proposal: Needs discussion




Need to clarify that HTTP POST only is used in mandatory mapping.


Need to add something to conformance section about HTTP POST binding and conformance.


Sunil: The WSDL 1.1 defines soap http bindings. We are soap only.




What is the conformance requirement of this spec with respect to soap over HTTP.


The soap binding we have could be normative but optional complienace point.


Define a compliance point in the conformance section. For this compliance point.


Sunil The protocol is supposed to be transport agnostic.  There has to be a soap binding to transport.


Anish: you can use a binding which supports soap.  Is it enough to say HTTP post binding.  We could say HTTP post method.  It would be more appropriate to state WSDL 1.1 soap binding. The bindind defined in soap 1.1


Tom:  Agreed in principal,  we will define a normative soap binding, but not require that binding for conformance.


We talk about WSI compliant in another section.  This is only meaningful with http binding.


Ø Action: tom will start email discussion on this normative statement of our soap http post binding, and proper conformance text.



5.5      PC14 Extensibility of ReplyTo attribute






Anish Karmarkar


Title: replyTo attribute extensibility

Description: For the poll and callback pattern WS-R has an attribute 'replyTo' of type xs:anyURI. The value of this attribute in the request message specifies the poll/callback location. This is problematic for the following reasons: AnishEmailMay04

Proposal: Meeting discussion: perhaps making ReplyTo an element with open content (any) for extensibility) with default restriction (in absence of other agreements) for HTTP POST Binding to be a URL for HTTP requestNeeds discusion




·  Proposal to resolve the WS-R issue regarding 'replyTo' attribute
From Anish Karmarkar <Anish.Karmarkar@oracle.com> on
11 May 2004 17:55:37 -0000



Here is a proposal to resolve the issue [1], that I raised, regd. replacing the 'replyTo' attribute in WS-R with an extensible addressing container.


This proposal replaces the 'replyTo' attribute with a 'ReplyTo' element with an open content and defines the referencing scheme when the reply-to is a URI. This allows WS-R to be used with URI and makes it extensible to use other addressing schemes (WSRef, EPR or whatever may emerge out of other standards TCs/WGs).


The crux of the proposal is as follows:


1) The replyTo attribute is used in two places: a) On the ReplyPattern element, and b) PollRequest element. This attribute is replaced with an element called 'ReplyTo' described below.


2) Define a new global schema type and element (in the existing WS-R NS) as follows:


<xsd:complexType name="ServiceRefType">


   <xsd:any namespace="##other" processContents="lax" minOccurs="1" maxOccurs="1"/>


  <xsd:attribute name="reference-scheme" type="xsd:anyURI" use="required"/>



<xs:element name="ReplyTo" type="wsrm:ServiceRefType"/>


The value of the attribute reference-scheme specifies the "type" of the addressing scheme. One such scheme for using URIs is defined in (3) below.


3) Use the URI "http://www.ietf.org/rfc/rfc2396.txt" for the value of the reference-schema attribute when the reply-to address is a URI


4) For the type PollRequestType convert the attribute 'replyTo' to an element 'ReplyTo' of type 'ServiceRefType' with minOccurs=0. PollRequestType schema type will be as follows:


<xsd:complexType name="PollRequestType">


    <xsd:extension base="wsrm:HeaderBaseType">


        <xsd:element name="RefToMessageIds" type="wsrm:RefToMessageIdsType" maxOccurs="unbounded"/>

        <xsd:element ref="wsrm:ReplyTo" minOccurs="0"/>






5) For the type ReplyPatternType make it a complex content containing sequence of two elements 'Value' and 'ReplyTo as follows:


<xsd:complexType name="ReplyPatternType">


    <xsd:element name="Value" type="wsrm:ReplyPatterTypeValues"/>

    <xsd:element ref="wsrm:ReplyTo" minOccurs="0"/>





Details of changes required:


1) Modify the schema as stated above.


2) Remove line 644


3) Table 5:

s/none/Value, ReplyTo

remove "replyTo(URI"


4) Section 4.2.3 will have to change to say that the element 'Value' can have the values 'Response', 'Callback' or 'Poll'. In addition, a table for element 'Value' and 'ReplyTo' will have to be added. The description of replyTo attribute has to change to describe the element wsrm:ReplyTo. The meaning of the attribute 'reference-scheme' will have to be added along with the special value "http://www.ietf.org/rfc/rfc2396.txt".


5) Section 5.3, add a table for describing the ReplyTo element


6) Table 9 should be modified to remove 'replyTo(URI)' from the attribute row and 'ReplyTo" element should be added to the child elements row.


7) Replace lines 742-745 with the description of the 'ReplyTo' element, similar to (4) above.


8) Table 16, penultimate row, 2nd column:

s/replyTo attribute/ReplyTo element


9) replace 1331-1332 as follows:




<ReplyPattern replyTo="http://wsrsender.org/abc/wsrListnener">










  <ReplyTo reference-scheme="http://www.ietf.org/rfc/rfc2396.txt">







10) Line 639, 723, 986, 1376, 1379, 1390, 1437, 1438, 1448, 1453: s/replyTo attribute/ReplyTo element


11) replace 1466-1473 as follows:




<PollRequest xmlns="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1" replyTo=”http://wsr-sender.org/xyz/servlet/wsrmListnener” soap:mustUnderstand="1">

  <RefToMessageIds groupId="mid://20040202.103832@wsr-sender.org">

    <SequenceNumberRange from="0" to="20"/>








<PollRequest xmlns="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1"" soap:mustUnderstand="1">

  <RefToMessageIds groupId="mid://20040202.103832@wsr-sender.org">

    <SequenceNumberRange from="0" to="20"/>


  <ReplyTo reference-scheme="http://www.ietf.org/rfc/rfc2396.txt">







12) Section A.V.F (lines 1775-1777):

Replace the section to conform to the new schema type wsfm:ServiceRefType




A.V.F. ReplyTo URI

This property is identified by the QName "wsrmf:ReplyTo" and corresponds to the semantics

specified by the WS-Reliability reply-to. The type of this property is xs:anyURI.






A.V.F ReplyTo

This property is identified by the QName "wsrmf:ReplyTo" and corresponds to the semantics

specified by the WS-Reliability reply-to. The type of this property is wsrm:ReplyTo.




13) In section A.VI,


a) add:


<xs:import namespace="http://www.oasis-open.org/committees/wsrm/schema/1.1"/>


after line 1784


b) add a namespace prefix 'wsrm' corresponding to the NS  http://www.oasis-open.org/committees/wsrm/schema/1.1


c) and replace 1797 with:


<xs:element name="ReplyTo" type="wsrm:ServiceRefType"/>










Anish: there are several TCs which are struggling with something similar.  In my proposal I have included the complex type in our name space.  Do we want to put it into a separate namespace, such is with wsrmf 


Doug: I was wondering why you decided to use a required attribute rather than describing a default to simple URI. 


Anish: There was no particular reason to not do this. 


Tom: I agree that this be the default for the attribute.  If someone chose to put it in is it still valid.


Doug I do not see the need to be explicit, as long as the default is described.


Anish: specifying defaults in schema has been difficult.


Doug: defining leaving out the optional value not being present, our protocol defines the default.


Doug: Describe the semantics of leaving it out in text, with it being an optional attribute.


Anish: He is also saying we do not need to define the value.  Sending nothing means that


No disagreement.


Anish: I can come up with wordings now but I am not sure people are ready.


Doug: we have another open issue on whether this is in a separate name space.  In my opinion it should, and I appreciate the fact that Anish pointed this out.


We need this to discuss before voting on a proposal next week.  We should not be making changes without discussing this on the list.


Anish: I would like the namespace of this new element type in a separate namespace controlled by WSRM that would be a good thing.  WSS has done something like this.


Doug: from my perspective is that it eases other specs to use this feature, by not bundling it in with all our other stuff.


General agreed that this be in a separate namespace.



Remove point 3,

Describe semantics of not present.

In schema make attribute optional.

Suggest a namespace for service ref type.


Ø Anish action to provide amended proposal on reply to element, target for approval at next meeting.


Initiate discussion,.




6         Discussion of Document Progression.


Iwasa to have a new editorial draft done.  By the end of this week. Friday morning US.


.997 draft.


Can resolve all open issues by next Tuesday evening meeting



CD ballot possibliy initated. Two weeks from today May 25


Another cd ballot by May 25.


Could have the June 15 date for submission


Pete: I think after we vote to accept anish proposal we have to decide whether it is a substantive change.


The TC process states there should be another public review period.


Tom: we could have a one week public review.


Action: time will check with Karl on this process issue.


Bob F it is up to the committee to decide what


Jacques: 30 days for a new public review seems like a waste of time.


Doug: there are two questions: 1) do we as a TC believe the changes are substantive enough to require another public review , 2) is Karl ready to send out an announcement for public review longer than one month.


We could make a case that we are only asking to review the changes since the last review.



7         Frequently Asked Questions


·  Updated WSRM FAQ
From Tom Rutt <tom@coastin.com> on 11 May 2004 01:11:54 -0000


The question:


Q: How does the WS-Reliability protocol relate to WSDL operation types?



There are three reliable messaging reply patterns which may be used with WS-Reliability:

·        Response RM-Reply Pattern: the outbound Reliable Message is sent in a request of the underlying protocol and the RM-Reply is sent in a SOAP header element in the response message of the underlying protocol that corresponds to the request.

·        Callback RM-Reply Pattern: the RM-Reply of a previous message is contained in a SOAP header element an underlying protocol request of a second request/response exchange (or a second one-way message).

·        Polling RM-Reply Pattern: a second underlying protocol request is issued to the receiver of a previous message, in order to obtain a RM-Reply. The RM-Reply can be either contained in the underlying protocol response to this request or in a separate underlying request from the receiver to the sender. This polling pattern is generally expected to be used in situations where it is inappropriate for the sender of reliable messages to receive underlying protocol requests (behind the firewall cases) or to avoid resending bulk messages often.


The current answer is only about reply patterns.

Ø Jacques; Action: Jacques will write an answer to this question. 

After that we can decide if we need another question about reply pattern specifically.

Jacques: reply pattern question should be about a more general question about firewall and delayed response use cases.  This would be a better way to introduce the requirements to motivate the reply patterns.


Have an email discussion on this one.  Put this topic on agenda for next week.


Put this whole FAQ on the block for email discussion before next week.


Jacques: It is worth it to spend time on the FAQ.


Target an agreement on intial faq by next week.


Bob F moved to adjourn. Anish seconded/


Meeting adjourned at 7:27 PM


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]