Prelim Minutes WSRM TC Conference Call –July 20, 2004

The meeting of the WSRM TC  took place by teleconference

Tuesday, July 20, 2004, from 5:30 to 7:30 PM Eastern Standard Time

1 Draft Agenda:

1 Draft Agenda

2 Roll Call

3 Minutes Discussion

4 Action Item Review

5 Discussion of Comment Resolutions

6 Discuss results of CD Vote (closing at 7:00 PM during meeting)

7 Discussion of Document Progression Plans

2 Roll Call

Attendance:

First Name	Last Name	Email	Role	Company	Voting Level
Jacques	Durand	jdurand@us.fujitsu.com	Member	Fujitsu	1
Kazunori	Iwasa	kiwasa@jp.fujitsu.com	Secretary	Fujitsu	1
Tom	Rutt	tom@coastin.com	TC Chair	Fujitsu	1
Jishnu	Mukerji	jishnu@hp.com	Member	Hewlett-Packard	1
Robert	Freund	bob.freund@hitachisoftware.com	Member	Hitachi	1
Eisaku	Nishiyama	nishiy_e@itg.hitachi.co.jp	Member	Hitachi	1
Nobuyuki	Yamamoto	no_yama@bisd.hitachi.co.jp	Member	Hitachi	1
John	Fuller	jfuller@wernervas.com	Observer	Individual
Junichi	Tatemura	tatemura@sv.nec-labs.com	Member	NEC Corporation	1
Alan	Weissberger	ajwdct@technologist.com	Member	NEC Corporation	1
Abbie	Barbir	abbieb@nortelnetworks.com	Member	Nortel Networks	1
Mark	Peel	mpeel@novell.com	Member	Novell	1
Anish	Karmarkar	Anish.Karmarkar@oracle.com	Member	Oracle	1
Sunil	Kunisetty	Sunil.Kunisetty@oracle.com	Secretary	Oracle	1
jeff	mischkinsky	jeff.mischkinsky@oracle.com	Member	Oracle	1
Doug	Bunting	doug.bunting@Sun.com	Secretary	Sun Microsystems	1
Tony	Graham	Tony.Graham@Sun.com	Member	Sun Microsystems	1
Chi-Yuen	Ng	cyng@cs.hku.hk	Member	Univ of Hong Kong	1

Meeting is quorate.

3 Minutes Discussion

3.1 Appointment of Minute Taker

Tom Rutt will take minutes.

Minutes will serve to record issue resolutions.

3.2 Approval of previous meeting minutes

The minutes of the July 13 teleconf are posted at:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7803/MinutesWSRMTC071304.htm

Alan W moved to approve the minutes, Doug B seconded.

No opposition minutes approved.

4 Status of Action Items

4.1 Action 052503-1 (Tom Rutt) pending

Tom took an action item to complete the status column of

pre public review issues list, with correct URLs.

4.2 Action 060104-5 (Jacques) Pending

Action: Jacques, will propose further edits, on the FAQ for composability.

Still open, low priority

4.3 Action 070604-1 (Anish and Doug B) Closed

Action on Doug and Anish to come up with a proposal before the end of the week to resolve the schema for references.

Anish sent out a proposal

5 Discussion of Issues and editorial Comments

The following issues list includes items which have been resolved as of the output of the 7/6/1004 TC meeting:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7725/PublicCommentsIsssues-070604OutputB.html

The following additional issues and comments were circulated to the list for discussion.

These need to be resolved before we can vote on a next CD.

5.1 Comment on the ref Schema

· Minor technical issue (or two) in the reference.xsd schema
From Doug Bunting <Doug.Bunting@Sun.COM> on 24 Jun 2004 15:43:22 -0000

· Re: [wsrm] Minor technical issue (or two) in the reference.xsd schema
From Anish Karmarkar <Anish.Karmarkar@oracle.com> on 25 Jun 2004 22:10:52 -0000

Mail From Anish, posted just before the meeting:

· New schema elment/type decl in WSRM schema to include BareURI
From Anish Karmarkar <Anish.Karmarkar@oracle.com> on 20 Jul 2004 20:45:46 -0000

Tom,

Here is a proposal to address the issue raised by Doug [1] regarding the use of URI in the addressing container.

1) Below is the schema element and type decl that should be added to the schema at "ws-reliability-1.1.xsd" --

<xsd:element name="BareURI" type="BareURIType">

<xsd:simpleType name="BareURIType">

<xsd:restriction base="xsd:anyURI" />

</xsd:simpleType>

Additional changes needed:

1) Table 10, section 4.2.3.2 the value for the row 'Child element' is incorrect. ReplyTo element requires exactly one EII {any}.

2) Section 4.2.3.2.1, replace:

"The Sending RMP MAY omit this attribute, when the value of the ReplyTo element is expressed with a value of type URI."

with something like:

"The Sending RMP MUST omit this attribute, when the child element of the ReplyTo element is wsrm:BareURI"

3) Section 4.3.1, replace:

"The format or schema of the value of this element is specified by the reference-schema attribute. If the attribute is omitted, the default format of ReplyTo element is URI as defined in [RFC 2396]."

with:

"The format or scheme of the value of this element is specified by the reference-scheme attribute. If the attribute is omitted, the default scheme of ReplyTo element is wsrm:BareURI as defined in Section XXXX"

4) Add a new section that defines the wsrm:BareURI element consistent with definition of other elements in the wsrm schema (editorial). This section should also point to Section 6 HTTP binding for an example of how things work with a simple URI.

Anish: this is Left as editorial task, needs to be explained using a table or a new section. Leave for the editor.

5) There are a few places where the attribute on the ReplyTo element is called 'reference-schema' rather than 'reference-scheme'. A quick search and replace should fix this. (Note: this is unrelated to the issue raised by Doug)

6) Table 15 needs to be modified similar to table 10 in (1) above.

7) Section 4.3.1.1 needs to be modified similar to (2) above.

8) Section 6, the following lines need to be changed from:

"If a ReplyTo element present in a Request element or Poll Request header element, sent using the SOAP 1.1 protocol, contains only a URL and uses the 'http:' URL scheme, then the WS-Reliability response MUST be sent using the HTTP binding specified in section 6 of SOAP 1.1."

to:

"If a ReplyTo element present in a Request element or Poll Request header element, sent using the SOAP 1.1 protocol, uses the wsrm:BareURI (default) reference scheme and uses the 'http:' URL scheme, then the WS-Reliability response MUST be sent using the HTTP binding specified in section 6 of SOAP 1.1."

9) Changes to section 6 should also be made (similar to (8) above) for the SOAP 1.2 case..

10) example 12, and example 17 need to be changed to include the 'BareURI' element (as a child element of ReplyTo)

Hope this addresses the issue raised by Doug.

Thx.

-Anish

[1] http://www.oasis-open.org/archives/wsrm/200406/msg00176.html

Doug: I am happy with putting this in.

Ø Action Item: Editing team to put the Ref schema text changes proposed by Anish into the next editor’s draft, along with changes to Accommodate Chris F comment on ReplyTo specification.

5.2 Comments from Mark Peel

· Non-exhaustive proofreading pass on 1.05 spec
From "Mark Peel" <mpeel@novell.com> on 12 Jul 2004 22:11:46 -0000

· 1.05 inconsistency
From "Mark Peel" <mpeel@novell.com> on 12 Jul 2004 22:05:03 -0000

The above changes were agreed last week.

· Groups - Contribution-105-Peel-WS-Reliability.pdf uploaded

From mpeel@novell.com on 19 Jul 2004 16:56:45 -0000

This document reflects 1.05 consistency resolution, plus editorial changes, and rewordings.

Mark: I will send out a list of changes in here, which might require review.

Agreed that Editorial team will Mark Peel contribution 1.05 as a starting point for the next edits.

However, all these changes remain subject to review by the group.

· Additional 1.05 questions/clarifications

From "Mark Peel" <mpeel@novell.com> on 19 Jul 2004 18:46:47 -0000

The following readings (or their potential corrections) are unclear

to me.

119-120: Synchronous messaging applications require immediate knowledge

of the message status (e.g., Error)

Should "Error" read "fault"?

261-262: When an RMP supports both Deliver and Respond, then it MUST be

able to associate a payload obtained via Respond, with a payload

previously delivered (Deliver), based on Consumer demand.

What does "based on Consumer demand" mean? When the RMP supports

both Deliver and Respond, it seems to me it should be able to associate

Respond payloads with the Deliver payloads that evoked them whether the

Consumer wants the Respond's payload or not. Does it add something

meaningful, or should we strike that clause?

407-408: The messaging scope of these agreement items may vary, as

messages may be associated with a group.

The clause "as messages may be associated with a group" does not

explain why or under what circumstances messaging scope may vary (and

aren't all messages are associated with groups, even if they are

singleton groups?). Should we strike this clause?

835: A Sending RMP MUST include a PollRequest element when the

ReplyPattern agreement item has the value "Poll".

This language suggests the Sending RMP must add a PollRequest element

into any message with the RM-Reply Pattern set to Poll -- which

contradicts the examples given in 6.3.1 and 6.3.2 and would leave

WS-Reliability with no means of doing delayed acking. Suggested

rewording:

835: A Sending RMP MUST send a message which includes a PollRequest

element for a group whose ReplyPattern Agreement Item has the value

"Poll" some time before the group expires.

BTW, does this MUST apply even if the group does not require

Guaranteed Delivery?

Doug: This is an example of a general wording issue, which happens throughout the specification. We are wrapping up things that are not requirements as requirements. This is supposed to mean the sending rmp can poll whenever it wants to, and when it does is uses the PollRequest element. There should be no :”MUST” in this sentence.

Doug: I suggest an editing team. Volunteers are: Doug B, Jacques, Iwasa, Mark Peel. Sunil Continues as Schema Editor, as part of the team.

No opposition to this Editing Team being formed.

915: The Sending RMP MUST include the SequenceNumRange element when it

specifies which messages in a group are queried for status.

Since SequenceNumRange (or SequenceNumberRange: see below) has a

cardinality of 0 or more rather than 1 or more, I suggest this should

read

915: The Sending RMP MAY include the SequenceNumRange element to

request the status of 1 or more specific messages within a group.

1286: Note: In case a message is received with an ending marker, but

not all previous messages have been received, then the group remains

active. No termination process is initiated yet.

This note about the receiver side follows a description of sender side

behavior.

1931: Note: The expiry time is calculated at the time a message is

sent, but adding this duration to the time the message is sent.

This unclear note follows B.6.1 and B.6.3. Should it read

Note: the expiry time duration value is calculated at the time a

message is sent, but the Receiving RMP should add this duration to the

time it received the message.

Also, I found a discrepancy between the spec and the schema:

PollRequest/RefToMessageIds/SequenceNumRange in the 1.05 spec is

PollRequest/RefToMessageIds/SequenceNumberRange in the 1.1 schema.

While the schema rules, we may wish to alter the schema in this case, as

its name is inconsistent with the request element to which it refers,

i.e., Request/MessageId/SequenceNum.

Finally, a question. The group establishment logic outlined in 5.1.2

strongly implies a Receiving RMP cannot acknowledge messages received

for a group if it has not received the group's SequenceNum==0 message: a

message after the first might have invalid group items (e.g., using

groupMaxIdleDuration instead of groupExpiryTime) and would get faulted

after being ack'ed. Am I reading this correctly?

· Re: [wsrm] Additional 1.05 questions/clarifications

From Sunil Kunisetty <Sunil.Kunisetty@oracle.com> on 19 Jul 2004 22:09:11 -0000

>> 835: A Sending RMP MUST include a PollRequest element when the

>> ReplyPattern agreement item has the value "Poll".

>> This language suggests the Sending RMP must add a PollRequest element

>> into any message with the RM-Reply Pattern set to Poll -- which

>> contradicts the examples given in 6.3.1 and 6.3.2 and would leave

>> WS-Reliability with no means of doing delayed acking. Suggested

>> rewording:

>> 835: A Sending RMP MUST send a message which includes a PollRequest

>> element for a group whose ReplyPattern Agreement Item has the value

>> "Poll" some time before the group expires.

I think the MUST in this case should have been a MAY. Just because the Message

has a Poll ReplyPattern, it doesn't imply that the Sender MUST send a Poll request

for the same although it will in most cases. And hence MUST must have been a

MAY in this case.

-Sunil

Agreed to take these comments to the list to propose resolutions.

Editing team may propose changes in this area as well.

5.3 Comments from Chris Ferris

· Re: [wsrm] comments on ws-r 1.05
From Christopher B Ferris <chrisfer@us.ibm.com> on 13 Jul 2004 03:36:09 -0000

· Re: [wsrm] comments on ws-r 1.05
From Christopher B Ferris <chrisfer@us.ibm.com> on 13 Jul 2004 02:47:16 -0000

· comments on ws-r 1.05
From Christopher B Ferris <chrisfer@us.ibm.com> on 13 Jul 2004 00:22:30 -0000

· consolidated proposals for resolution of Chris F comments
From Tom Rutt <tom@coastin.com> on 20 Jul 2004 09:52:27 -0000

Email References used in table:

<JD5>

· FW: Re: [wsrm] Proposed clarificaiton resolutions to Ferris comments 1,2
From Jacques Durand <JDurand@us.fujitsu.com> on 18 Jul 2004 03:43:31 -0000

<ter2>

· Proposal to accomodate Chris Ferris comments - batch 2
From "Tom Rutt" <tom@coastin.com> on 16 Jul 2004 21:13:03 -0000

<DB4>

· Re: [wsrm] Proposed resolutions for ChrisF issues 3,4,6,8,10
From Doug Bunting <Doug.Bunting@Sun.COM> on 16 Jul 2004 05:07:36 -0000

· Re: Fwd: Re: [wsrm] Proposed clarificaiton resolutions to Ferriscomments 1,2
From Doug Bunting <Doug.Bunting@Sun.COM> on 16 Jul 2004 05:05:06 -0000

<JD3>

· RE: [wsrm] Proposed resolutions for ChrisF issues 3,4,6,8,10
From Jacques Durand <JDurand@us.fujitsu.com> on 16 Jul 2004 03:40:07 -0000

<JD2>

· RE: Fwd: Re: [wsrm] Proposed clarificaiton resolutions to Ferris comments 1,2
From Jacques Durand <JDurand@us.fujitsu.com> on 16 Jul 2004 00:10:11 -0000

<DB3>

· Proposed resolutions for ChrisF issues 3,4,6,8,10
From Doug Bunting <Doug.Bunting@Sun.COM> on 16 Jul 2004 00:05:09 -0000

<DB2>

· Refinements of comments 7 and 9 [Re: [wsrm] Proposed clarificaitonresolutions to Ferris comments 1,2,24,5,7,9,16,19]
From Doug Bunting <Doug.Bunting@Sun.COM> on 15 Jul 2004 22:47:27 -0000

<DB1>

· Re: Fwd: Re: [wsrm] Proposed clarificaiton resolutions to Ferriscomments 1,2
From Doug Bunting <Doug.Bunting@Sun.COM> on 15 Jul 2004 20:25:15 -0000

<JD1>

· [wsrm] Proposed clarificaiton resolutions to Ferris comments 1,2
From Jacques Durand <JDurand@us.fujitsu.com> on 15 Jul 2004 00:20:40 -0000

<ter1>

· Proposed clarificaiton resolutions to Ferris comments 1,2,24,5,7,9,16,19
From Tom Rutt <tom@coastin.com> on 14 Jul 2004 20:53:41 -0000

1, 2, 24.	<ter1> Need to clarify that no implementation details are prescribed for abstract RMP operations: Proposed clarification: Add at the end of line 85 the following sentence to the qos bullet: “ These abstract operations are associated with processing of an RMP, however implementation aspects regarding how, or when, they are invoked are not prescribed by this specification. “ <JD1> Although these ops are first mentioned in line 85, this reference is very general and does not call for such a detailed adjustment that early. In line 85, I would just add "These operations are defined in Section 1.5". </JD1> Add the following new paragraph between lines 105 and 106, before the Note “ The direction of the arrows for the qos contract abstract operations, shown in Figure 1, represents the direction of information flow associated with the operation. Implementation details of how these operations are invoked, including which entity invokes the abstract operation, are not prescribed by this specification. “ <JD1> OK, but I would remove second sentence if we use my rewording below for the Note, as it is redundant. <JD1> I think we need an even more explicit statement, for addressing comments 1,2 from CF: " These operations are abstractly defined here as transfer of information (message payload, error notice) between the RMP and external components (Producer, Consumer). This specification makes no requirement on how these operations should be implemented, and by which component. Defining the reliability QoS contracts does not require more concrete definitions, which are left to implementations. " I would place the statement in the "Note" after Figure 1, replacing and expanding on sentence in line 110 (" The interpretation of these operations is a matter of implementation.") <DB1> I agree with the general direction outlined in the attached discussion but think we should go a bit further. With regard to the set of definitions, we should be clear these operations define the abstract interface to a subset of the infrastructure on either the sending or the receiving side that may not be nearly this clearly separated. That is, the RMP itself is abstract in the sense that it has the abstract interface described using the submit, notify, deliver and respond operations. The RMP is also abstract because the infrastructure support for reliable delivery may be more or less comprehensive that what we have arbitrarily chosen to place within that bucket for the purposes of making our specification clear. This adds up to meaning the notify operation (for example) may or may not exist in a real deployment, not just that the producer might actually poll for errors. If we start with Jacques' suggestion for text below Figure 1: … above [As an aside, this point seems important enough not to relegate it to a (non-normative?) note and should be in the regular specification text.] I would re-word it slightly: " These operations and executable components are abstractly defined here to simplify discussion of the WS-Reliability protocol and not to imply a particular API or component separation. The separations described here between producer and consumer and their associated RMP do indicate the expected value of placing WS-Reliability support within an infrastructure component. However, any implementation choices leading to the externally observable properties discussed in this specification are equally valid. The operations themselves describe a transfer of information (payload or error notice) between external components (Producer, Consumer) and an associated RMP. Again, this specification makes no requirement on how these operations should be implemented, by which component or if these operations are explicitly present in an implementation. " <JD3> Overall the 1st part of this rewording looks fine to me, as it rightly emphasizes that the whole model (components + operations) is an abstract template that can be instantiated in many ways, depending on how we want the QoS contract to apply, between which parties. One edit: I believe the singular form should be used: "...any implementation choices leading to the externally observable properties discussed in this specification are equally valid" ---> "...any implementation choice leading to the externally observable properties discussed in this specification is equally valid" Other comments inline, for the operation definitions </JD3> <JD5> Lines 182-198: generalize the definitions of the four abstract operations “ Deliver: An abstract operation supported by the RMP. When invoked on a Receiving RMP, the operation makes the payload of one Reliable Message available to the Consumer. For example, in one specific implementation choice, the payload is placed into a queue by the Receiving RMP to be consumed by an application component. Submit: An abstract operation supported by the RMP. When invoked, the operation transfers payload data from the Producer to the Sending RMP (e.g., a request to the Sending RMP to take responsibility for the Reliable Message). Respond: An abstract operation supported by the RMP. When invoked, the operation transfers payload data from the Consumer to a Receiving RMP. Notify: An abstract operation supported by the RMP. When invoked, the operation makes available a response payload received by the Sending RMP, to the Producer, or makes available to the Producer the status of a Reliable Message (e.g., a notification that the Sending RMP failed to send a Reliable Message). “ with the following: ----------------------- “ Deliver: An abstract operation associated with a Receiving RMP. When invoked, the operation makes the payload of one Reliable Message available to the Consumer from the Receiving RMP. For example, in one specific implementation choice, the payload is placed into a queue by the Receiving RMP to be consumed by an application component. <JD1> The "associated with a Receiving RMP" might still be misinterpreted. I would replace 1st sentence with: "An abstract operation that controls a transfer from Receiving RMP to Consumer." Submit: An abstract operation associated with a Sending RMP. When invoked, the operation transfers payload data from the Producer to the Sending RMP (e.g., a request to the Sending RMP to take responsibility for the Reliable Message). <JD1> I would replace 1st sentence with: "An abstract operation that controls a transfer from Producer to Sending RMP." Respond: An abstract operation associated with a Receiving RMP. When invoked, the operation transfers payload data from the Consumer to a Receiving RMP. <JD1> I would replace 1st sentence with: "An abstract operation that controls a transfer from Consumer to Receiving RMP." Notify: An abstract operation associated with a Sending RMP. When invoked, the operation makes available a response payload received by the Sending RMP, to the Producer, or makes available to the Producer the status of a Reliable Message (e.g., a notification that the Sending RMP failed to send a Reliable Message). <JD1> similarly, "An abstract operation that controls a transfer from Sending RMP to Producer." plus a narrowing: replace "the status" by "the failure status". <DB1> With this background, we can be a bit more straightforward with our definitions of the operations. We have already described them as abstract and for the exposition of the text. This leaves us able to simplify the abstract interface and talk directly about invocation and information transfer. How about: " Deliver: An abstract operation that transfers the payload of one Reliable Message from Receiving RMP to Consumer. For example, in one specific implementation choice, the payload is placed into a queue by the Receiving RMP to be consumed by an application component. <JD3> on Deliver: So you propose to not use anymore the expression "making available". In that case we should warn that the notion of "transfer" above must also be understood in an abstract way, as a transfer of control (or of responsibility) on the payload, not necessarily as a physical transfer which may take place later (in which case we may not want to wait for this to happen before sending the Ack). E.g. an RMP may "deliver" by just setting a flag on payload stored in a persistent store, meaning availability to a COnsumer which may later complete the actual transfer by querying the store. </JD> <JD5> Answer to JD4 From Doug B: Whether payloads or control of payloads is transfered is a very low implementation detail that does not matter when we are talking about abstract operations on abstract components. I believe this only confuses the specification. <JD2> my concern was precisely to make sure that "transfer" remains abstract enough and is not understood in a too restrictive way, which could possibly lead a developer to believe (in my above example) that its RMP has to wait for the payload to be physically fetched by the COnsumer, before sending the ack for a delivery. (that's a possible interpretation, but not the only one.) To keep "transfer" abstract enough I propose to add a sentence like: "transfer to a component" in above definitions does not imply a complete physical transfer of data. It is, mor generally, the act of making data available in some way to the component. (see below my more complete proposal) </JD2> Notify: An abstract operation that transfers a failure status or contained payload of one Reliable Message from Sending RMP to Producer. The transfered status might include an indication the Sending RMP was unable to reliably deliver the message. The Sending RMP is NOT REQUIRED to invoke this operation for every Reliable Message submitted; it MAY invoke Notify for a subset of the completed Submit operations. <JD3> On notify: the last sentence ("it MAY...") is not clear, and talks of correlation between these ops that I believe should be addressed later in the doc in a more informed context, e.g. section 2.2. Also we may want to move the requirements (statements using the RFC keywords) out of these definitions, and in a more prescriptive section like 2.2. The prescriptive section (2.2) should also say the most basic: that an RMP MUST be able to invoke Notify (regardless how the op is implemented) as well as Deliver. The other operations (Submit, Respond) are to be invoked from outside.</JD> <JD5> Response from Doug on <JD3> Moving these sentences elsewhere is fine. I am not sure what is missing (or where) with regard to your last sentence. <JD> nothing missing... I was just saying there is no requirement attached to the invocation of (Submit, Respond) as the RMP is not supposed to invoke these. </JD5> Submit: An abstract operation that transfers the payload of one Reliable Message from Producer to Sending RMP. Essentially, the Submit operation is a request to the Sending RMP that it take responsibility for the Reliable Message. Respond: An abstract operation that transfers the payload of one Response Message from Consumer to Receiving RMP. When supported in the protocol, this payload data will be carried together with RM Reply headers (see below). The Consumer is NOT REQUIRED to invoke this operation for every Reliable Message delivered; it MAY invoke Respond for a subset of the completed Deliver operations. " <JD3> On Respond: same remarks as for Notify. Also the 2nd sentence seems not at its place in this a definition, which I believe does not need to mention all the rules associated with these ops. I propose to keep just the 1st sentence, in the def.</JD> <JD5> Response to JD3 from Doug: In another email, you agreed with the general use of forward references from this section. The second sentence above is a forward reference to the rules you mention, not those rules. JD: Forward refs are OK, my concern on your sentence #2 above, is that it is in fact a hidden requirement (the "will be" actually sounds like a MUST), which exposes deeper protocol ramifications than necessary in this section (which I tend to consider just as a glossary). So the sentence tells either too much or not enough, if left here. Instead, we could refer to the section that expands on it (e.g. "more detailed semantics is given in Section 2.2"). </JD5> <JD4> 1) and 2) follow-up: <JD4> in addition to proposed resolution (previous emails), we need to fix - or explain – the way we name these operations: we call them currently "RMP operations" at various places, but as noted these abstract operations are not necessarily supported by the RMP. So to be more precise we could rename them (QoS operations? or transfer operations?) or just explain that this naming does not mean all these ops are supported by an RMP. </JD4 <JD5> my proposal: A) for the terminology section, after compilation of previous other comments: (note again that these definitions do not pretend make explicit all the rules and semantics attached to the usage of these ops, which would be described elsewhere in the spec.) This is along keeping the terminology section as nothing more than a glossary. Note also that I use the term "message" instead of "payload" (see C.F. comment #15): although I don't see this as a mjor issue, CF has a point that RMP is a SOAP node (or processor)before all. "payload" may sound specific of an implementation. To be discussed in other mail. Deliver: "An abstract operation that transfers a message from Receiving RMP to Consumer. This operation is invoked by the RMP. More details are given in section... " Submit: "An abstract operation that transfers a message from Producer to Sending RMP. More details are given in section... " Respond: "An abstract operation that transfers a message from Consumer to Receiving RMP, as a response to a previously received message. More details are given in section... " Notify: "An abstract operation that transfers from Sending RMP to Producer, either a failure status of a previously sent message, or a message received as response. This operation is invoked by the RMP. More details are given in section... " </JD5> ------------------------- <JD5> B) in Section 2.2 that expands on "RMP operations", add: (after line 255 1st sentence that introduces the four ops) (mostly wording from Doug, +few edits: choices->choice, and some addition on "transfer".) "These operations and executable components are abstractly defined here to simplify discussion of the WS-Reliability protocol and not to imply a particular API or component separation. The separations described here between producer and consumer and their associated RMP do indicate the expected value of placing WS-Reliability support within an infrastructure component. However, any implementation choice leading to the externally observable properties discussed in this specification is equally valid. The operations themselves describe a transfer of information (message data or error notice) between external components (Producer, Consumer) and an associated RMP. This "transfer" does not imply a complete physical transfer of data. It is, more generally, the act of making data available in some way to the component. This specification makes no requirement on how these operations should be implemented, by which component or if these operations are explicitly present in an implementation." [note: other edits may be necessary in 2.2. or elsewhere. But note that I'd prefer to leave the section 1.2 as is and not overload it with more details on Deliver/Submit/Respond/Notify - although that's where we talk first about these ops - as this is not essential to the purpose of this section (to convey the general RM concepts and scope)] </JD5> Doug B: At some point Jacques and Doug need to come to agreement on this, and post it to the list. Jacques: I agree, it is mostly a wording issue here that we have. We have to be precise enough to define the contract, but not to overly constrain implementations. As Chris F pointed out, we need to keep away from Implementation details. Ø Action: Jacques an Doug will propose a resolution to Chris F comments 1,2, 10,19, and 24 for discussion by the TC.
2	See comment 1
3	<ter2> Improper reference for ws security Proposed resolutions: Lines 151: change “ OASIS WS-Security 2004 “ to “ OASIS Soap Message Security 1.0 “ Line 155: change: “ WS-Security 2004 “ to “ OASIS SOAP Message Security 1.0 [WSS] “ Line 250: change: “ WS-Security “ to “ OASIS Soap Message Security 1.0 [WSS] “ <DB3> lines 151/5 and 250/1 should have a normative reference to the OASIS SOAP Message Security 1.0 spec not "WS-Security" ð As agreed (I believe) during the teleconference, make the change Chris suggested and reference the specification in both places using the correct term. Tom: I hear No opposition to including this proposal in next editor’s draft.
4	<DB3> line 489/90 reads: ... Why is this only a RECOMMENDATION? "It is RECOMMENDED to NOT resend a message for which an RM-Reply with one of the following Fault types has been received:". ==> change to "A Sending RMP MUST NOT resend a message for which it has received an RM-Reply with one of the following Fault types:" I am not sure where group termination due to an error should be covered though expect that would be somewhere in chapter 5. I do agree both the sending and receiving RMP should terminate a group as soon as such a fault is identified (for the receiving RMP) or received (for the sending RMP). This is complicated because the sending RMP may have to retry or poll before it shares this understanding, meaning the receiving RMP cannot "forget" the group immediately. <JD4> <JD> I guess the reason that is only a recommendation, is that preventing such resending is not essential to the RM protocol. (E.g. similarly, we never say that as soon as an Ack is received, any resending MUST stop.) It is just not paramount (nor always feasible?) to strictly enforce this, implementation-wise, although this is an optimization. As for the dis-ordered sequence of which one message has been faulted, it is indeed an optimization that we have not done, to terminate the group when one of its messages has been faulted as above (we currently would wait for the faulted message to expire, to terminate the group.) So we could update 5.1.3.5 (Termination by ordered failure) by adding to the "triggering event" line (both in sending RMP and receiving RMP): "...or a message is faulted with one of the codes mentioned in section 3.2.1" </JD> <DB4> For (4), I do not understand a MAY / MUST for stopping the "resend loop" after receiving a Fault without a MAY / MUST for stopping after receiving an acknowledgement. In both cases, I would prefer MUST since to do otherwise just wastes RMP time. This would also be one of those nice externally observable requirements. Doug B: whether this is a requirement or a recommendation depends on the consensus of the group. Jacques: I do not have a strong opinion, I do not see a strong opinion to make it a must. An underlying principle in our spec is that the receiving of Faults is not strong requirement for protocol, because faults can be lost. Doug B: the requirement is not actionable if you do not receive the fault. Doug Moved to reword as Tom proposed, No second. Motion fails for lack of a second. If someone cares they should take it to the list for further discussion. Doug: We still need to have the group termination issue complete. This is a sub issue. Agreed to leave open for resolution of sub issue.
5	<ter1> WSRM TC has agreed to fix unnecessary use of Soap 1.2 terminology Proposed resolution, agreed at July 13 WSRM TC meeting: Line 67-68: change sentence: “ WS-Reliability is a SOAP Module (as defined by [SOAP 1.2]), which fulfills reliable messaging requirements that are critical in some applications of Web Services. “ to: “ WS-Reliability is a SOAP based specification, which fulfills reliable messaging requirements that are critical in some applications of Web Services. “ Lines 166-170: change “ Reliable Messaging Processor (RMP): A SOAP Node (as defined by [SOAP 1.2]), or a subset or superset thereof, capable of performing Reliable Messaging as described by this specification. With regard to the transmission of a Reliable Message from one RMP to another, the former is referred to as the Sending RMP, and the latter as the Receiving RMP. An RMP may act in both roles. to: Reliable Messaging Processor (RMP): A SOAP processing element, capable of performing Reliable Messaging as described by this specification. With regard to the transmission of a Reliable Message from one RMP to another, the former is referred to as the Sending RMP, and the latter as the Receiving RMP. An RMP may act in both roles. <JD4> <JD> Good point, although the "node" definition in SOAP 1.2 Part 1, section 1.4.1 appears to be a general one (not depending on 1.2 specific features). So we could use the term "SOAP processor" instead as Tom suggests, and say that in case of SOAP 1.2, it is a SOAP node, and in case of SOAP 1.1, it complies with similar requirements: "...enforcing the rules that govern the exchange of SOAP messages and accesses the services provided by the underlying protocols through SOAP bindings." I think what we want to convey in the RMP definition is that (1) an RMP implements SOAP protocol and some underlying binding so that it can do messaging, and (2) an RMP understands RM SOAP headers. </JD> [C.F.]...It makes for a cleaner specification if one defines behaviour in terms of destination and source because it is entirely feasible that a component might implement only one of those roles. As defined, WS-R requires that a conformant implementation of an RMP implement both roles which would limit its applicability to certain use cases such as small footprint devices or in cases where reliability was only needed in one direction. Also, what is with the "a subset, or superset thereof". What does that mean exactly? <JD> I think these concerns were addressed in the latest contribution (July 7) which is not the one Chris used. - new section 2.2 ("RMP operations") explicitly says an RMP can be implemented for sending, and/or receiving (lines 256-257) - the "subset/superset" part was removed from the def. </JD> <DB4> For (5), I am not sure what you are suggesting but suspect your comments work with the proposal in Tom's "1,2,24,5,7,9,16,19" email. Jacques: while the term Soap node is to soap 1.2, but we could state that this processor is a soap. Agreed to leave this to the editing team to propose the proper wording in the next draft for review.
6	<ter2> Better definition for Reliable message Proposed clarification: Line 171-172: change “ Reliable Message: A message for which some level of reliable delivery is required. “ to “ Reliable Message: A SOAP message carrying a wsrm:request header block. “ <DB3> line 171/2 defines the term "reliable message". This seems unnecessary. ==> change "Reliable Message: A message for which some level of reliable delivery is required." to "Reliable Message: A SOAP message containing a <wsr:Request> header block." Note: I am comfortable with mixing such concrete definitions with the various abstract terms we use to illustrate our model. If others would prefer our definitions have a consistent abstraction level, what do they suggest for this definition? <JD4> <JD> fine with me: only the terms that refer to notions that the spec does not want to define further (yet wants to define properties about), need be "abstract". In the present case, this forward reference is OK (since we say that the glossary can do forward references.)</JD> No disagreement with this change. Agree to use Xpath notation in this case. Agreed that Editing team will apply the proposed change to Reliable message definition using the Xpath notation.
7	<ter1> Message Delivery is not the end of Receiving RMP processing Proposed clarification: Lines 204-206: change “ Message Delivery: The action of invoking the “deliver” operation for a Reliable Message. This action marks the end of the RMP processing for this message. “ to “ Message Delivery: The action of invoking the “deliver” operation for a Reliable Message. <DB2> Actually, this does not cover the problems Chris identified with failed Deliver operations nor the explicit connection we have made between message delivery and sending an acknowledgement (when required). I suggest: "Message Delivery: Completion of the Deliver operation for a Reliable Message." Agreed that editing team is to apply Doug’s fix to the next editor’s draft. “
8	<ter2> Definition of PollRequest message Proposed clarification: Lines 221-225: change “ PollRequest Message: A polling message for Acknowledgment Indication(s). A Sending RMP may send a PollRequest Message for polling of Acknowledgment Indication(s) regardless of RM-Reply Pattern of the original Reliable Message. For example, the Sending RMP may send PollRequest Message to retrieve Acknowledgment Indication for a message originally sent using Callback RM-Reply Pattern. “ to “ PollRequest Message: A message sent by the Sending RMP to the Receiving RMP that requests that it respond with RM-Reply information.“ “ <DB3> line 217 [actually 221-225] defines the term "PollRequest Message" ... leave out the embellishments. ==> change "PollRequest Message: A polling message for Acknowledgment Indication(s). A Sending RMP may send a PollRequest Message for polling of Acknowledgment Indication(s) regardless of RM-Reply Pattern of the original Reliable Message. For example, the Sending RMP may send PollRequest Message to retrieve Acknowledgment Indication for a message originally sent using Callback RM-Reply Pattern." to "PollRequest Message: A message the Sending RMP sends to the Receiving RMP, requesting RM-Replies for identified earlier Reliable Messages. Support for this message is REQUIRED as part of the Poll RM-Reply pattern (see section 2.5.3). This message MAY also be used to augment other RM-Reply patterns." Doug: this is touched on by one of Jacques earlier comments, which could be taken care of later. No opposition to Editing team incorporating Doug’s fix for PollRequest Message definition to the next draft.
9	<ter1> Use of the word implement with Abstract operation Proposed clarification: Lines 256-257: change “ An RMP acting in the role of a Sending RMP MUST implement Submit, and notification of failure (Notify). An RMP acting in the role of a Receiving RMP MUST implement Deliver. “ with “ An RMP acting in the role of a Sending RMP MUST support use of Submit and Notify. An RMP acting in the role of a Receiving RMP MUST support use of Deliver. <DB2> An important part of the issue here was implications around who implements what. The phrase "support use" is not dissimilar enough to avoid these implications. I am also unsure why we are bothering with the "acting in the role of" wordiness. Finally, I see nothing in the specification requiring a sending RMP to use AckRequested, meaning that Notify should also be optional (for a more extreme reason, admittedly, than Respond is optional). I suggest: "A Sending RMP MUST support the Submit operation. A Receiving RMP MUST invoke the Deliver operation for every valid, in-order and non-expired message it receives." No opposition to editing team incorporating Doug’s proposal to replace the two sentences in next draft.
10	<DB3> line 265/8 reads: ... getting perilously close to implementation detail "An RMP which supports both Submit and Notify MUST be able to associate a failure notification (Notify) with the related submitted payload(Submit). In case the notification of payload is supported, the RMP MUST be able to associate a received payload(Notify) with a previously submitted payload(Submit)." ==> This text or something similar was the subject of an earlier discussion in the TC which may not have completed to everyone's satisfaction. I would prefer deleting this paragraph. It is only an indication to the developer how to design their API were they to choose a direct rendering of the RMP component. <JD4> <JD> but this is just the counterpart requirement to what we say earlier in same section about the need to associate a Respond invocation to a previous Deliver invocation. We know an RMP MUST be able to do so (this is part of the semantics of Respond). Why then is this OK while it is not OK to require also that on the Sending side, similarly, a Notify invocation must be associated with a previous Submit invocation? </JD> <DB4> Agreed, I focused on the particular paragraph Chris mentioned and missed the previous one. I would therefore suggest both paragraphs should be removed. Agreed to leave open for now, and to add this to the Doug and Jacques action item with the Comment 1.
11	<ter2> Table does not show Reply to as complex type Proposed clarification: Lines 758-766: change “ 4.2.3.2 Element: Request/ReplyPattern/ReplyTo A Sending RMP MUST include this element for a message with “Callback” value for Value element. The Sending RMP MUST NOT include this element for a message with “Response” or “Poll” value for Value element. It is to specify the endpoint for the initial Sending RMP to receive a callback Acknowledgment Indication or RM Fault Indication. If present, the format of ReplyTo element MUST be specified by the reference-schema attribute. If the attribute is omitted, the default format of ReplyTo element is URI as defined in [RFC 2396]. Table 10 ReplyTo Element Cardinality 1 Value String Attributes reference-schema Child elements None 4.2.3.2.1 Attribute: Request/ReplyPattern/ReplyTo/@reference-schema This attribute is to specify the format or schema of the value of the the ReplyTo element. The Sending RMP MAY omit this attribute, when the value of the ReplyTo element is expressed with a value of type URI. “ to “ 4.2.3.2 Element: Request/ReplyPattern/ReplyTo A Sending RMP MUST include this element for a message with “Callback” value for the Request/ReplyPattern/Value element. The Sending RMP MUST NOT include this element for a message with “Response” or “Poll” value for the Request/ReplyPattern/Value element. It is used to specify the endpoint for the initial Sending RMP to receive RM-Reply information. The format of the child element of Request/ReplyPattern/ReplyTo/Ref MUST be specified by Request/ReplyPattern/ReplyTo/@reference-scheme, if the attribute is present. If the attribute is omitted, the default format of the child element of Request/ReplyPattern/ReplyTo is URI as defined in [RFC 2396]. Table 10 ReplyTo Element Cardinality 0 or 1 Value None Attributes reference-scheme Child elements {Any} (representing the reference) 4.2.3.2.1 Attribute: Request/ReplyPattern/ReplyTo/@reference-scheme This attribute is to specify the format or scheme of the value of the child element of Request/ReplyPattern/ReplyTo. The Sending RMP MAY omit this attribute, when the child element of Request/ReplyPattern/ReplyTo is expressed with a value of type URI. The type of this attribute is xsd:anyURI. “ Lines 863-875 change “ 4.3.1 Element: PollRequest/ReplyTo A Sending RMP MAY include this element. If present, then the Receiving RMP MUST send the RMReply information in a new request to the endpoint specified by this element. If not present, the RM-Reply MUST be sent back on the response of the Poll request itself. The format or schema of the value of this element is specified by the reference-schema attribute. If the attribute is omitted, the default format of ReplyTo element is URI as defined in [RFC 2396]. Table 15 ReplyTo Element Cardinality 1 Value String Attributes reference-schema Child elements None 4.3.1.1 Attribute: PollRequest/ReplyTo/@reference-schema This attribute is to specify the format or schema of the value of the ReplyTo element. The Sending RMP MAY omit this attribute, when the value of the ReplyTo element is expressed with a value of type URI. “ to “ 4.3.1 Element: PollRequest/ReplyTo A Sending RMP MAY include this element. If present, the Receiving RMP MUST send the RMReply information in a new request to the endpoint specified by this element. If not present, the RM-Reply MUST be sent back on the response of the Poll request itself. The format of the child element of PollRequest/ReplyTo MUST be specified by the PollRequest/ReplyTo/@reference-scheme, if the attribute is present. If the attribute is omitted, the default format of the child element of PollRequest/ReplyTo/Ref is URI as defined in [RFC 2396]. Table 15 ReplyTo Element Cardinality 0 or 1 Value None Attributes reference-schema Child elements {Any} (representing the reference) 4.3.1.1 Attribute: PollRequest/ReplyTo/@reference-scheme This attribute is to specify the format or schema of the value of the child element of PollRequest/ReplyTo. The Sending RMP MAY omit this attribute when the child element of PollRequest/ReplyTo is expressed with a value of type URI. The type of this attribute is xsd:anyURI. “ Tom: proposed taking this along with Anish’s proposal, to produce the next version of the document. Doug: the syntax description could be pulled out as a separate section and referenced from the two. Agreed to having editing team Make a new subsection with just the common text, and refer to it in both places. Agreed to apply these edits on ReplyTo specification to the next draft, along with those of Anish on Ref schema.
12	<ter2> Clarification of scope Proposed clarification: Lines 430-431: change “ • If GroupExpiryTime is used for a messaging scope, then the item GroupMaxIdleTime MUST NOT be used, and vice versa. “ to “ • If GroupExpiryTime is used for a group scope, then the item GroupMaxIdleTime MUST NOT be used, and vice versa. “ Jacques: Messaging Scope could be either group or message. I would suggest to remove the word scope. Change “group scope” to “group” in the proposal above. No opposition to Jacques proposal. Editing team to incorporate the change.
13	<ter2> Wording Proposed clarification: Lines 484-485: change “ A Sending RMP that has not been able to receive an acknowledgment for a sent message, MUST notify the Payload Producer of a delivery error. “ to “ A Sending RMP that has not received an acknowledgment for a sent message, after applying its resend policy, MUST notify the Payload Producer of a delivery error. “ Alan: I propose to delete this sentence, because it is an implementation matter. We should make this part of the implementers guide. Doug: I agree with Alan’s proposal. Jacques: I can agree, as long as the definition of Notify includes the delivery erro. No opposition to deleting sentence. Editing team to incorporate this change into next draft
14	<ter2> Implication that Sending RMP must compare payloads Proposed clarification Lines 507-508: change “ • Two message instances that carry different payloads MUST NOT share the same Message Identifier. “ to “ • Message instances resulting from separate invocations of Submit MUST NOT share the same Message Identifier. “ Jacques: the new wording is better. But the original wording was not intended to imply comparistion No opposition to change. Editing team to incorporate into next draft
15	<ter2> Message is what Sending RMP deals with, not payload Proposed clarification Lines 509-511: change “ • Two message instances that share the same Message Identifier - such as the resending mechanism generates - MUST carry exactly the same payload(s) and the same reliability headers. “ to “ • Two message instances that share the same Message Identifier (such as generated by the resending mechanism) MUST have identical reliability headers and convey the payload from the same Submit invocation. “ Doug: This does not solve the problem that both versions would allow things to change when the message ID has not change. Two message instances which share the same message Id must not be changed when resent. Doug: “When resending a message with the same message ID, the message contents must not be changed.” Tom: what about WSS, would it change any timestamps changing the signature on a resend. Agreed to the simpler wording from Doug. Editing team to incorporate into next draft
16	<ter1> MUST ignore extra information is too strong a constraint for a spec Proposed clarification Lines 601-604: change sentence “ If a message contains additional elements not described in this specification, the Reliable Messaging Processor MUST ignore those elements. “ to “ If a message contains additional elements not described in this specification, the Reliable Messaging Processor MAY ignore those elements. Doug: I agree with the MAY. No opposition to this change. Editing team to incorporate into next draft. “
17	<ter2> constraints on sequence number for ordered deliver in wrong place Proposed clarification: Lines 669-767: Delete “ If the MessageOrder element appears in the message received, the Receiving RMP MUST NOT deliver the message until all messages with the same groupId value and a lower number value have been delivered. “ and add the following new paragraph after Line 793: “ If the MessageOrder element appears in the message received, the Receiving RMP MUST NOT deliver the message until all messages with the same Request/MessageId/@groupId value and a lower Request/MessageId/@number value have been delivered. “ Editing team to incorporate into next draft.
18
19	<ter1> definition of Payload Proposed clarification Lines 173-174: change “ Payload: Subset of message data that is intended for the consumer of the Reliable Message. “ to “ Payload: Message data that is transferred from or to an RMP through the use of an abstract RMP operation. Jacques: Put this with the action item of Jacques and Doug to proposed a more abstract definitions. --
20	<ter2> clarification of term scope Proposed clarification Line 402: change “messaging scope” to “scope” Agreed change for editing team to incorporate into next draft.
21
22	<ter2> Redundant text is not clear Proposed clarification Lines 496-497: remove “ When the NoDuplicateDelivery agreement item is enabled, a payload submitted only once to the Sending RMP MUST NOT be delivered twice or more to the consumer party. “ since the following paragraph states the same requirement more clearly. Editorial team will take this into consideration and suggest an imporvement.
23
24	See comment 1)
25
26
27	<ter2> redundant text should be removed Proposed clarification Lines 217-218: remove “ For the Callback and Poll RM-Reply Patterns, RM-Replies for multiple Reliable Messages MAY be included in a single Reliable Messaging response. “ since this constraint is clearly stated in specification of Response element. No opposition to this proposed change. Editing team to incorporate into next draft
28	<ter2> Term “smallest scope” is unclear Proposed clarification Line 408: change “ The smallest scope of applicability for each RM Agreement item is: “ to “ Agreement items applying to the Message Scope MAY be applied at the Group Scope. The default scope of applicability for each RM Agreement item is: “ Editing team to incorporate into next draft.
29	<ter2> redundant constraint is misleading Proposed clarification Lines 541-542: remove “ • From one sent message to the next in the same group, the sequence number MUST increase by one, starting with value 0. “ since this is clearly stated in the definition of sequence number values. Agreeed Editorial fix to be applied
30	<ter2> Exclusive Or not clear Lines 666-668: change “ In a request message, the sender MAY include either a @groupExpiryTime or a @groupMaxIdleDuration corresponding to the group termination parameters specified in Section 5.1.2. “ to “ In a request message, the sender MAY include either a @groupExpiryTime or a @groupMaxIdleDuration, but not both, corresponding to the group termination parameters specified in Section 5.1.2. “ Agreed fix for editing team to apply to next draft..
31
32
33
34
35
35
36, 37	<ter2> Fault specs are misleading Proposed clarification Line 1081: change the table row “ InvalidMessageId This fault is sent in any of the following cases: 1. If @groupId (for MessageId or RefToMessageIds ) doesn’t exist, or if exists, and the value is wrong or invalid. 2. If number attribute in SequenceNum element doesn’t exist, or if exist, the value is invalid or wrong. 3. Attributes (from and to) of SequenceNumRange doesn’t exist, or if exists, the values are invalid or wrong. “ To: “ InvalidMessageId This fault is sent in any of the following cases: 1. If @groupId (for MessageId or RefToMessageIds ) is not present, or is present with an invalid value. 2. If @number in SequenceNum element is not present, or is present with an invalid value. 3. Attributes (from and to) of SequenceNumRange are not present, or are present with invalid values. “ No opposition to editorial change. Editing team to apply to next draft.
37
38
39
40
41
42	<ter2> extensibility not described in Specification Text Chris Ferris pointed out that the main body text which specifies the header elements does not describe the extensibility expressed in the schema. In fact, the only place where extensibility is shown, which is in the figures 6 and 7, shows it incorrectly (with the any at the end). Proposed clarification: Lines 562, 567, and 588: remove the boxes with “any” from figures 6 and 7. Lines 600 – 602: change “ In a case where the text of the specification is shown to be in conflict with schema statements, the schema statement prevails. If a message contains additional elements not described in this specification, the Reliable Messaging Processor MUST ignore those elements. “ to “ In a case where the text of the specification is shown to be in conflict with schema statements, the schema statement prevails. The schema for some of the elements specified in this section includes specification of extensibility elements and attributes. The extensibility features expressed formally in the schema are specified in section 4.6. If a message contains additional elements or attributes not described in this specification, the Reliable Messaging Processor MAY ignore them. “ Line 1128: add new section 4.6 “ 4.6 Extensibility features of Schema The schema namespace with prefix wsrm, which is part of this specification, specifies extension mechanisms for some schema elements. The following elements, which have a complex sequence type, are specified in the schema to allow the presence one or more extension elements, of type xsd:any, at the beginning of the sequence, as well as one or more extension attributes: * Request * Response * PollRequest * NonSequenceReply * SequenceReplies * ReplyRange “ No opposition to incorporating this change. Sunil will review to see if there are others. Editing team to incorporate into next draft

5.4 Comments from Doug Bunting

· drb comments on 1.05
From Doug Bunting <Doug.Bunting@Sun.COM> on 13 Jul 2004 05:08:42 -0000

As amended in Minutes of 7/13 meeting.

line 10

editorial

Is Iwasa really the only editor?

Add at least Sunil and Jacques, who contributed mucho editing time.

Let Jacques, Sunil and Iwasa Discuss this together.

Resolved by having a new editing group, in the final document everyone in the group will be listed.

line 17

editorial

A committee draft is a static indication of the TC's view at a particular time. Once the document is anything other than a working draft, this line is incorrect and inappropriate.

Delete this line.

Agreed fix for editing team to apply.

lines 25-26

editorial

Have we created a blank errata sheet or do we have a plan to do so? If not, these lines should say something about "when available".

Change "The errata page for this specification is at" to "If necessary, the errata page for this version of the specification will be located at" and confirm this location is under TC control.

Agreed fix for editing team to apply.

line 67

minor technical

WS-Reliability is a number of SOAP modules, not just one. It also seems very odd to describe a protocol with specific message exchanges added to the application interaction (producer / consumer interface in our terms) simply in terms of the syntax added. Finally, as Chris also mentioned in his initial comment 5, this reliance on SOAP 1.2 terminology implies a SOAP 1.1 -only implemenatation is not conformant.

Remove "is a SOAP Module (as defined by [SOAP 1.2]), which"

Joe C: how about SOAP based capability

Jeff: “is a SOAP based specification, which”

General agreement on Jeff’s proposal as the proper resolution.

Agreed fix for editing team to apply.

lines 78, 81

editorial

"Under this aspect" adds nothing to either of these points.

Remove these phrases.

Agreed fix for editing team to apply.

lines 105-106

editorial

"On the sending side, like on the receiving side" adds nothing.

Delete this phrase.

Agreed fix for editing team to apply.

lines 117-119

editorial?

Bullet about "application level synchronous messaging" has never made sense. The bizarre semi-clarification in bullet conflicts with the value duplicate elimination might add if the producer (in our terms) wants to repeat messages until it gets the response it expects.

Delete this bullet.

Agreed fix for editing team to apply.

Table 2

minor technical

Our specification is supposedly useful for both SOAP 1.2 and 1.1. If we need a namespace prefix only for SOAP 1.1, something is very wrong in our specification.

Add some SOAP 1.2 examples and define namespace prefix for that namespace here.

Doug: We do not define a prefix for Soap 1.1. We never use soap 1.2 in the examples.

Doug: one soap 1.2 example would fix this.

Ø Action: Editing team to propose fix Doug B comment 9.

Section 1.3

editorial

This "conventions" section seems the appropriate place to describe what in the document is normative. Normative is not mentioned until page 41 at the moment! Are examples and notes normative, for example? Are the examples without "(Normative)" in the subject non-normative? Is the associated schema normative (see lines 600-602)?

Describe what in the document is normative.

This is a question of writing it down in the spec. Members should proposed text to clarify what is normative in the spec.

Doug: this is part of the issue that Mark mentioned on line 835. We have a number of places where we personify elements and make required statements on their behaviour.

After the next draft, all members should provide comments on this point.

6 Discussion of Kavi Ballot for CD 1.05

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7751/WS-Reliability-ED105.zip

Passed the Kavi Ballot to become CD 1.05.

All voting members voted yes.

Ø Action: Tom Rutt to update cover page as CD 1.05 and place Zip file on server in Drafts folder.

7 Discussion of Document Progression and future meeting schedule.

Tom: can the editors apply the edits we have agreed to today by the close of business of next Monday.

Action: editing time to apply agreed edits from today’s minutes by the end of next Monday.

Proposals for remaining action items should be posted to the list by next Monday.

Action: tom will post an Action item list with remaining technical items as explicit action items.

At this point we can keep the targets for a next CD ballot on Aug 3, with fallback to Kavi ballot initated on Aug 3 (if not Quorate).

Alan : we need to continue to plan the Implementor’s guide work after the spec is completed.

Alan moved to adjourn, Jacques seconded.

Meeting adjourned.

wsrm message

1 Draft Agenda:

2 Roll Call

3 Minutes Discussion

3.1 Appointment of Minute Taker

3.2 Approval of previous meeting minutes

4 Status of Action Items

4.1 Action 052503-1 (Tom Rutt) pending

4.2 Action 060104-5 (Jacques) Pending

4.3 Action 070604-1 (Anish and Doug B) Closed

5 Discussion of Issues and editorial Comments

5.1 Comment on the ref Schema

5.2 Comments from Mark Peel

5.3 Comments from Chris Ferris

5.4 Comments from Doug Bunting

6 Discussion of Kavi Ballot for CD 1.05

7 Discussion of Document Progression and future meeting schedule.