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: Preliminary minutes from Wed F2F

Prelim wed minutes attached.

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

Title: Bob Freund provided a new bridge number to allow us to dial in at the meeting

Prelim minutes WSRM TC Face To face Meeting (Day 1) at New Orleans Marriott


wed, April 28, 2004, from 9:00 am to 5:20 PM Central Daylight Time


There was a conference bridge available on both days from 10:00 AM to 12:00 Noon CDT both days.


1         Introduction


1.1      Draft Agenda

To insert


1.2      Roll Call

Last Name




Voting Level




Cyclone Commerce














TC Chair





















NEC Corporation





NEC Corporation




Prosp Member
















Sun Microsystems





Sun Microsystems





Univ of Hong Kong



2         Approval of Meeting Minutes from 4/20 meeting


Motion to approve Minutes of last meeting from Bob F, Doug B seconded.


No opposition 4/20 minutes approved.


3         Action Item Status Review


3.1      Action 033004-3 – (Jacques) Pending

Jacques took action item to propose new FAQ text for the ws-reliability 
features. – open
Close by taking text from Sunil’s slides for the faq

3.2      Action 033004-6 – (Tom) Pending

Need a general question on how can ws reliability be used with other ws 
reliability protocols. Answer : we design it as orthogonal, to work with any other ws- reliability protocol. An example on why we have a reply to element of our own would help.
Tom Rutt agreed to send a suggested question and proposal out. - open

3.3      Action editors-1 – (Marc and Doug) Pending

Marc G and Doug B to updated issues list to reflect agreements in CD 
.992. - open

3.4      Action 041304-1 – (Jacques) Needs Discussion 4/14/04

- Jacques will send an email to initiate email discussion on poll 
response for fault conditions


·  treatment of aborted out-of-order seq
From Jacques Durand <JDurand@us.fujitsu.com> on 14 Apr 2004 00:15:05 -0000

Closed will discuss with issues

3.5      Action 041304-2 – (Iwasa) Needs Discussion – 4/20

- Iwasa to consolidated agreed comments in text with 
change bars against CD .992. A list indicating which meeting minutes’ 
agreed changes were applied should also be included.

·  Groups - UpdatesListFromCD10Mar2004-0.992.pdf uploaded
From kiwasa@jp.fujitsu.com on 20 Apr 2004 14:41:05 -0000

·  Groups - WS-Reliability-2004-04-19.pdf uploaded
From kiwasa@jp.fujitsu.com on 20 Apr 2004 14:40:08 -0000





3.6      Action 042004-1 – (Jacques) Pending



Ø Action: Jacques will propose the text changes to the document to remove retry parameters

Provided for the agreements section 1, still open for section 3 and the annex

3.7      Action 040201-2 – (Pete) Pending



Action: Pete will provide an input to the F2F on the RMP / soap processing model to help resolve the XMLP WG’s concern.. Include a proper definition of RMP



3.8      Action 040201-3 – (Tom) Pending



Action: Tom should put general document restructure on the agenda.

To discuss after resolving technical issue.


3.9      Action 040201-4 – (Tom) Pending




Tom took an action a proposal to clarify when the Receiving RMP may need to send a SOAP fault to close the WSDL level response.



3.10Action 040201-5 – (Jacques) Pending



Jacques will take an action to write a proposal to try to resolve Martin C’s comments.



4         Public review comments from OASIS Panel Discussion


The group formulated a set of public review comments.from the presentation by Chris Ferris:


Cf1:  Two schemas and namespaces are unnecessary for two soap versions.



Cf2:  Why are soap faults not used for RM-Fault?



Cf3: Not Acking until delivery to the application causes unnecessary delays?



Cf4: Unclear if the spec can compose with WS-Addressing or WS-MD?



Cf5: Persistence model will not work on devices with non volatile storage?



Cf6:  Mandatory Expiry time requires synchronization of clocks:



Cf7:  There is unnecessary complexity in the spec, headers have unnecessary elements making them larger than necessary?


Tom Rutt took an action item to provide draft resolutions for discussion by the TC.



5         Editors Draft .993 Status Review


Sunil moved to accept all changes in editors draft .993 and its associated schema, Alan seconded.


No opposition, motion passes.


6         Status of Public Review




10:30 12:00 Noon – Issues and Editorial comment resolutions


6.1      Comment 9.2





agreed text not yet applied

Faults for Aborted Ordered Deliver

treatment of aborted out-of-order seq


Action on Tom and Iwasa to provide text.



Out of order sequence:

We talked about two Issues that are not unrelated,
yet after review, I believe only one remains:

----- Issue 1:

Should the Receiver warn the Sender that an out-of-order sequence has been
aborted on the Receiver side, due to a reason other than message expiration?
(in case of message expiration, the Sender can - generally - deduce the failure).

Position 1: This can't be more than just an optimization, as the reliability
contract would not be broken anyway (would not cause delivery of un-ordered messages !)
And also we never rely on error messages for critical RM logic.
Note also that any further "quantitative" aspect of RM (e.g. about max length of
out-of-order sequence) is out of scope for V1 (line 103, sec 1.2)

Position 2: This is more than just an optimization, as it is a special failure case
with potential high cost if not dealt with as efficiently as possible:
without knowledge that a sequence has been given-up, cumulative and useless
resending (and new sending) may overwhelm the Receiver.
We fault individual messages for various reasons, including lack of storage resource,
so why not fault such a multi-message failure?


Opinion: In case a Poll request is used by the sender, it does not cost much to give
notice of the failure (see example in Issue #2 below) in the poll response.
So even if we see this notification as no more than an "improvement" (Position #1)
we can fault the dropped messages in the response.
But when callback is possible - and requested - should the Receiver send:
(a)- nothing at all
(b)- a special PermanentProcessingFailure for the entire group (so will that look like responses we do for "singleton" groups?)


Agreed on New RM-Fault type to indicate the failure of an entire group.  It MUST be sent by Receiving RMP for any request on that aborted group.


In the poll response the final reply range will indicate that fault code, with the range of sequence numbers which were not delivered by the Receiving RMP.


Faults will continue to be sent for each message received after the group is aborted.


Name of new fault should be “GroupAborted


Action: Iwasa and Tom will provide text for the new fault code and the reference to it in the section of text Alan cites.


Action: Sunil will update schema for new fault code in the message processing failures sector.


c)- a PermanentProcessingFailure for each dropped message.
I personally favor (b) as a consistent complement to my opinion in poll request
case. A MAY or a MUST? I think again its just an optimization, so a MAY is OK.


----- Issue 2:

When we talk of generating Faults, and how to get them to Sender in case neither
callback or response pattern is possible. In that case, Polling is the only way a
Sender can get faults generated on Receiver.

Well, it appears that the Poll response can actually give the fault code,
so the issue is moot(so much for me).
A response to a poll about an aborted sequence, (assuming Position 2)
 would look like:
      <SequenceReplies groupId="mid://20040202.103832@oasis-open.org/">
        <ReplyRange from="0" to="5"/>
        <ReplyRange from="6" to="15" fault="wsrm:PermanentProcessingFailure"/>

NOTE: should we have a new fault code: "InvalidGroupId" for requests
concerning groups that are non-existent (possibly because already terminated?)


6.2      Comment 7.10




1025-1030: Example in which SOAP Fault may also convey an RM Acknowledgment requires a confusing or impossible processing order. (Process RM headers, remember that an Ack needs to be sent, continue with header processing and SOAP Body validation and finally "application processing space outside the realm of the receiving RMP".)  How does the RMP know when all processing has been completed, then intercept a possible SOAP Fault in order to attach its Ack?


Action Item to Tom Rutt for proposing better text.


Re: [wsrm] response to action item to clarify soap faults and WSRMresponses


Jacques too action item to incorporate the latest proposal from Tom and Pete into a new section on request/response.





Tom Rutt clarification of soap faults and RM faults:

This is the proposed text changes, taking into account Pete Wenzel's comments:


Clarification of Soap Faults and wsrm:response


Lines 1025 – 1030



“Example case 1:


For the WSDL Request/Response operation type, an operation request which was successfully delivered by the receiving RMP to the receiving application may result in an application-level Fault, (e.g., one specified in the WSDL description for the operation), to be returned.


In such a case, when the response reply pattern is in use, the SOAP fault message associated with this application-level Fault MUST carry the Acknowledgment indication in a wsrm:Response element within its Soap header.


This is required so that the Sending RMP gains knowledge of the successful Delivery of the Reliable message request, even though the operation encountered an application-level fault condition associated with the processing of the WSDL request/response operation.



line 1031 - 1047:




*Example case 2:*


A message with an RM Fault indication MUST NOT be delivered to the receiver by the receiving RMP. In this case, when the Response RM-Reply pattern is in use, a WSDL operation response will not be available for the receiving RMP to return with the RM-Reply including the RM-fault indication. In such a case, the Receiving RMP MUST cause an wsrm:Response to be sent in the header of a soap:fault message.


This same condition arises when the message in the request is a duplicate of a prior delivered message with Duplicate Elimination in use. The Receiving RMP, in such a case, when the Response reply pattern is in use, has no meaningful WSDL response to return for that WSDL request/response operation, so it MUST cause a soap:fault to be returned. The difference in behaviour with this duplicate elimination condition, is that an RM-Fault indication is not sent for that request in the soap:fault message, but an acknowledgement indication is sent.


In cases where a receiving RMP MUST NOT deliver a WSDL request/response operation request to the receiver, that receiving RMP MUST initiate the return of a SOAP Fault message, associated with that request, as follows:


   * If the RM-Fault indication was due to a problem with the request

     header element, a SOAP client fault MUST be returned.

   * If the RM Fault encountered was due to a problem with processing

     by the receiving RMP (including the inability to return a response

     due to Duplicate Elimination), a soap:server fault must be returned.



Tom: Need to clarify that we do not provide reliability on the response of wsdl request response operation, thus if duplicate is send due to sender not receiving first response, the receiving rmp will not have the prior response buffered to send in this condition.


Bob: we need to get rid of redundant sentences because people may think there is a difference.


There are special considerations for WSDL request response operations.


Jacques: the concept of wsdl request/response should occur in a specific section early in the document explaing how wsdl request/response operations would be designed to work with ws reliability.  Need an explicit section of wsdl request response operations, and this fault text could go there.


Jacques took an action item to propose this new subsection on special considerations for wsdl request/response operations.



6.3      Comment 7.11




1990: Remove appendix if there is nothing to say here; the sole item listed is already done (App A)

agreed not yet applied

Agreed to delete appendix D futures list


6.4      Comment 7.12




The specification contains no reference to the schemas. 

agreed not yet applied

The two schemas should be listed in the normative appendix, and introduced at an appropriate location in the text, perhaps at the beginning of Section 4


Agreed to have a new normative appendix which points at the schema URL.  It also has to have the precedence statement copied from the schema.


At publication time the OASIS staff can decide to place the actual schema text.




6.5      Comment 9.1





agreed, not yet applied

Retry Parameters

reworded section on agreements

Jacques presented his proposal.


for now update second level in poace, to move to new level 1 section after Jacques reorganization action item.


Comment 9.1 – new proposal for rm-agreement first level section.

Jacques presented his new proposal.


Agreed to remove (s1) from section 2.4 of proposal.


There was discussion on the description of the expiryTime agreement parameter.


Bob: the precision of the expiry time should not be finer than the expected skew of the clocks between sender and receiver.  Perhaps using a timestamp, plus a time to live interval, would help this.


Jacques: on the wire it is date/time currently.


Bob: if the purpose is to have a course control we could get away with a course interval.


Bob: we always have a clock, but it may be grossly skewed from other system’s values.  We are creating a new cause of protocol failure if we rely on clock synchronization.


Bob: what degree of clock skew can our protocol tolerate.


Tom: we need a solution for the case of the receiving RMP having the wrong year (say 2003 instead of 2003) set by the sys admin after a disk restoration.


Bob if you have two values you give the receiver more information.  If the sender sends time time plus time to live interval  the receiver can calculate the average skew.


Leave open


Alan: two values are required to cover the case of a resend.


Defer discussion of time skew issue until Thursday morning.


Jacques continued reviewing his proposal for new section 2.


Change line 114 “smallest scope allowed” to “smallest applicable scope allowed”


Tom: currently the constraints are in the protocol section.


Jacques moved, Bob seconded to incorporate his proposal with the changes noted above.




6.6      Comment 3.14



Line 408-406:  If a reply pattern is sent that had not been previously agreed upon, it will be rejected, with a Fault message: Non Supported Feature returned to the sender

Alan suggested: MUST BE

agreed in princ but text still


Doug B: we tend to not use word reject, for this is to the sender end.  This needs to use the deliver operation terminology.


Agreed in principle.  Leave wordsmithing for action item.


Jacques: the text regarding MUST send for faults should be stated in a general manner to accommodate polling or delayed callback.  A single section to explain what “sending a fault” means. 


“Sending an RMfault must be interpreted differently depending on the reply pattern in use.”


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


6.7      Comment 3.16




Section 3.3. Guaranteed Message Ordering Failure Case


closed see 9.1

Line 563-565:  Is the decision to abort ordered delivery totally implementation dependent?  Can we specify a Maximum Persistance time parameter for a received out of order message, so that after that time receiver aborts ordered delivery.  Otherwise, a skimpy implementation could give up almost immediately vs a robust implementation trying to recover for a much longer time after receiving multiple out of order messages without receiving any retransmitted sequential messages


Jacques took action item to propose clarification about faults for aborted ordered delivery.


6.8      Comment 3.17




Line 726: groupExpiry Time attribute:

Clarification:  No mention whether this parameter can be changed.  Suggest forward reference to line 1148- 1149. 6. Line 1148- 1149

agreed not yet applied

Suggest reference to appropriate section


Add the following to both groupexpiryTime and groupMaxIdleTime definitinons in


“Constraints on allowd values for this attribute are specified in section 5.


6.9      Comment 7.6




Section 1.5: Examples are placed in an awkward location.  Should appear after the protocol & features are described.  Suggest moving them to a non-normative appendix

agreed , text position to be determined

Agreement to move examples to a later section or annex of the document, position to be determined.


6.10Comment 7.9




569: Sequence Number is not a Feature; it is simply a mechanism used to Implement Guaranteed Message Ordering.  Should not be given equal status to the other 3 features.


Defer to the general document restructuring exercise.


Jacques took an action on where to move the current section 3.4, with perhaps a re-title of section 3.  Jacques will also propose a new document structure to accommodate this and other problems he encounters.

6.11Comment 8.1




Only one area needs major tree surgery: section 1.7 should be merged with appendix II and placed in its own top level section. This is the part of the doc that threw me most.

accom by 9.1

new section on reliability agreement


6.12Comment 8.2




Line 101 - 114: editorial: delete all these lines  as its castes too much doubt on the spec

agreed changes not applied

<JD> How about rewording instead like:

"Reliability is often associated with QoS quantitative measures, in areas other than Web services (e.g. networking). Thresholds such as rate of failures, minimal size of persistent store, average latency, and more generally quantitative measures that may appear in service level agreements, are out of scope for this version."

 <MC> fine </MC>


6.13Comment 8.3




Line 150 - 271: editorial: I find it strange that we launch into example messages without any form of introduction.    Maybe better to insert a paragraph to explain a scenario from whish these messages are derived. And also there really should be an fuller explainaion of a the reliability elements.

accom see 7.6 and 8.x

<JD> we have some explanation at the end of each example. We could move this up before introducing each example, instead of after. 

<mc> the text is very terse. If you look at other specs they really walk though all the relevant elements and explain what is going on </mc>

[Jacques Durand] Let us ask our editor, I think there was some intent to give an up-front flavor of the headers, that the reader could go back to as s/he progresses through the spec. (I expressed in the past my preference to see these examples at the end of doc, but can understand this rationale. Now, question remains how much walk through can we do up-front without much knowledge of the spec...)


Discuss with document reorganization, could move examples into a later section or annex.

agreed to put examples later in the document.


6.14Comment 8.4




line 358: editorial: the whole of section looks out of place. It uses a lot of terminology that has not yet been introduced. It is also strongly related to appendix II. I suggest moving the whole of 1.7 into a new top level section after section 5 (i.e. make it a new section 6) and then merge in appendix II.

accommodated by 9.1

<JD> the problem with moving the agreement definitions after Sec 5, is that we refer to them throughout the spec, starting with Sec 3, when introducing RM features. Why not have a new section between Sec 2 and Sec 3 (i.e. previous Sec 3 becomes 4, etc.) However, when doing so I would not import the entire Appendix A/II up front, as I think it is unsettling for the reader who expects to get right at the core features with as little distraction as needed... so I would provide some introduction material on the rationale for adding capability info to WSDL, and the approach recommended, and then refer to Appendix A for the hard stuff. Also if we combine the agreement and the   f&p stuff, clearly state that even if they complement each other, they don't need each other. </jd>


<mc> maybe i missed something but thr agreement stuff is sort of meaningless without a way to express it. Granted there may be many ways to do this, with f&p being one of them. If this is what you mean then fine. </mc>


<jd> We thought this over, and  concluded that agreements can remain abstract and still be meaningful here: in fact, it is the only proper way to connect to "outside" agreements while keeping their representation open. We describe our RM features like: "if <agreement-item-XYZ> is enabled (or has value ABC), then the message protocol must look like this, the behavior must be like that." Just describing the protocol on teh wire was ignoring the agreement aspect. Also, some features like resending messages (and related parameters, like # of retries, etc) would not even appear in the message protocol. We needed to be able to talk about the behavior they cause even if they don't have a concrete representation. </jd>


<mc>Generally though, the agreement stuff is very detailed, and the detail is launched into without any overview of rationale. This is my main concern so even putting that in its own section may not help. </mc>

[Jacques Durand] Agree. Will propose something.


6.15Comment 8.5




line 444: editorial: I suggest adding a paragraph or two here that does provide a very high overview of the model. The subsequenst sub section dive into details without giving the reader an overview on which to elaborate. I suggest using the text in the pre-Tc version that was published:


"In the Reliable Messaging Model described in this document, the sender node sends a message to the receiver node directly (i.e., intermediaries are assumed to be transparent in this specification). The receiver node sends back an Acknowledgment  message to the sender node. Figure 1 shows this model. Figure 1 Messaging Model"


This should provide enough context

agreed not yet applied

<JD> Isn't that very similar to the first bullet item of 2.1 ?

No problem with this rewording though.

But the transition to 2.2 (and Figure 1) probably calls for another sentence like:

" the basic exchange patterns described in 2.2 derive from the above messaging assumptions.

Reliability features defined in this specification will in turn rely on these patterns." 


<mc> fine </mc>

6.16Comment 9.3






Document Reorganization


Jacques took action item to propose document restructuring.

7         New Comments from Sunil


More editorial comments:

1.  Changes to the Examples

-         XML payload uses namespace prefixes such as xlink, xsi, schemaLocation which are never used. 

Agreed editorial change

-         HTTP Headers for RM Requests mention a POST with a ‘/abc/servlet/wsrListner’. It will be good to make it more meaningful such as ‘/abc/servlet/wsrEndpoint’ or ‘/abc/servlet/wsrExampleEndpoint’.

Agreed editorial change

-         For Callbacks, response POST context URI doesn’t match the replyTo URI in the request

agreed editorial change

-         Why did we have 2 separate examples (Example 3 for Ack and Example 4 for Fault) for the same Poll Request (Example 3). It will be good if we can collapse Example 4 into Example 3 by adding the ReplyRange sub-element (for msg. 15) into Example 3’s <SequenceReplies> element.

Agreed editorial change

-         It will be good to add the attribute last=’true’ to the 3rd Message in Example 6 (SequenceNum Element). This way we will have illustrative example to show the usage of this (‘last’) attribute.

Agreed editorial change

2. Figure Updates:

Most of the figures use the word ‘Application Layer’, we need to better quantify what we mean by ‘Application Layer’ or say something like ‘Application Layer/SOAP Processor’.

Agreed that the word application and application layer need to be changed to more abstract terms (perhaps producer and consumer).

Jacques took action item to propose appropriate change to using word application.

3. Chapter 1/Section 1.6/Polling RM-Reply pattern/Line 352

Just add the word “poll” to better qualify it, i.e., make it “contained in the underlying protocol response to this poll request or in a separate …”

Agreed editorial change

4. Chapter 2/Section 2.3/Lines 483.

Line 483 states “This Message Identifier relies on the notion of group. A message always belongs to a group”.

The above is incorrect. A message can be independent/singleton or in a group.

We need to reword it.

Agreed to following editorial changes:

Line 413 414 488 of .993,  Delete parenthetical statements

Line 1193 – change “singleton groups,” to “groups”

5. mustUnderstand attribute used in tables 1, 9,12 must use lower case ‘m’ for mustUnderstand. It will be much better if we can qualify it as soap:mustUnderstand so as to distinguish this attribute with other RM specific attributes.

Agreed editorial changes

6. Chapter 4/Section’number’ attribute.

Reference to number attribute on lines (734,735) should start with a lower case ‘n’.


Lines 732-733 should be changed as follows:

The value of this attribute MUST be unique within the same group, and the combination of MessageId’s groupId attribute value and SequenceNum’s number attribute  MUST be globally unique to be used as a Message Identifier.

Agreed to change first para of section 4.21 to:

“Two messages with the same groupID, MUST NOT use the same sequence number value.”

7. Chapter 4/Section’last’ attribute/Lines 751-758

-         ‘False’/’True’ should be ‘false’ & ‘true’

-         We also need to mention that

Agreed to:  Remove “(Default value)” and add new sentence:  “When this attribute is not present, its value defaults to false.

We also need to mention that the first message in the group can also have this attribute with a value ‘true’, i.e., to indicate the first message in the group is also the last message, something similar to a singleton message.

Jacques: this is useful guidance; however has no normative impact on an implementation.  Perhaps a separate implementer’s guide could hold such statements, along with rationale for the decisions we made.

Bob: sometimes our guidance to the implementer breaks up the flow of the normative text.  We can go for a more concise readable document with normative specification.

Jacques: very few OASIS voters are developers.  Such reviewers may not appreciate implementation guidance.

Jacques it does not hurt to have a guideline document.  As I do my action item for the document reorg, I will put any such removed guidance text into a preliminary cut at the implementers guide.  And will place Sunil’s sentence above with that text.

8.      Section 4.4/Response Element.

Comments on replyPattern

1)      replyPattern on line 908 must start with a lower case ‘r’

Agreed editorial change.

2)      Did we decide that this is optional? I remember being it  mandatory to avoid potential errors. Schema says it mandatory.


Agreed to align text with schema delete “which defaults to the value “Response


Mention the cardinality of attribute clearly when describing the attribute itself. We do mention sometimes at the element (that has this attribute) level. Examples:

1)      Mention that replyPattern attribute (line 937) is a MUST (see above comments).

2)      Mention that groupId attribute of NonSequenceReply (line 961) is a MUST.

3)      Mention that groupId attribute of SequenceReplies (line 972) is a MUST.

4)      Mention that the fault attribute of ReplyRange element is optional (Line 992)

1, 2, 3, and 4 above agreed as editorial changes

9.      Section 4.4.1 (NonSequenceReply)

While the ‘fault’ attribute is listed in Table 13, it is not described below. We need to describe this something similar to ‘fault’ (lines 992-995) attribute for ReplyRange. We need to mention that this is optional too.

Agreed editorial change add:

(2) fault attribute

This attribute is used to indicate a Reliable Messaging Fault code which was encountered while

processing the message. The Receiver RMP MUST NOT include this attribute for an acknowledgment indication.


10.  Section 4.5/Fault Codes/Lines 1008-1012.

I think this paragraph needs to be reworded. A suggested one would be:

Agreed to delete following text

The WS-Reliability protocol does not directly map our Reliable Messaging Faults to the

SOAP Fault model.


The SOAP Fault model is used for reporting faults due to the request payload, which fits the

SOAP fault model better. Thus a response may have a SOAP Fault message, but the reason for

the SOAP fault would be due to problems associated with the WSDL operation message payload.

(E.g., A problem with the soap:body of a request message or the inability of the Receiver RMP to

return the WSDL response in the soap:body of when using the Response RM-Reply pattern).


and add appropriate FAQ question with the following answer:

The SOAP Fault model was not used for RM Faults because:

-         SOAP Fault model doesn’t support batching of Faults which this protocol requires.

This text should also go into the new implementer’s guide document, along with other rationale text for the decisions we made.

Alan: I am concerned that such changes might delay the time to final specification.

Tom: we probably will have enough technical changes to justify another review round anyway.

11.  Section 4.5.1/Line 1037 should be: “Invalid Message Format Faults”. (plural Faults).

Agreed editorial change.

12. Will the final version have Appendix C(Revision History)? If not, could we remove it from the specification move it to a different document.

Agreed to remove appendix C and instead maintain a new parallel document on the server with this information.


8         Tony Graham editorial comments:

Section 1.1, Purpose of WS-Reliability



Line 74


Change "The purpose of WS-Reliability is to address reliable messaging

requirements, which become critical" to "WS-Reliability addresses

reliable messaging requirements, which are critical".



Line 77


Change "This specification is intended as an initial proposal for

defining reliability" to "This proposal defines reliability".



Section 1.2, Scope and Definition of Reliable Messaging



Line 81


Change to "This specification focuses on the SOAP layer and

envelope. It defines reliable messaging as the mechanism supporting

any of the following requirements:".



Line 88


Change to "Within this scope, this specification supports:".



Line 92


Change to "Some features are out of scope of this specification, yet

this design is compatible with their implementation.  They are:".



Section 1.3, Notational Conventions



Lines 121-127


The formatting on this list doesn't make it very clear.  Should it be

redone as a table?



Line 122


Change "e.g." to "E.g.,".



Line 128


Add the namespaces from the similar table in Appendix A and remove the

table in Appendix A.



Section 1.5, Examples of Messages Compliant with WS-Reliablity



Remove the "xmlns:xlink", "xmlns:xsi", and "xsi:schemaLocation"

namespace declarations and attributes from the examples since they are



Remove the XML Declarations since they are unnecessary.



Line 178


Change "wsr-example.org" to "wsr.example.org" or "example.org/wsr" to

properly use the "example.org" example domain name.



Lines 182-183


Change "No Duplicate Delivery" to "Duplicate Elimination" and change

"Ordered Delivery" to "Guaranteed Message Ordering" to match the terms

used in line 90.



Lines 239-242


The explanation should also explain the NonSequenceReply element.



Lines 229, 260, 262


Use 'straight' quotes instead of 'smart' quotes around attribute




Section 1.6, Terminology



Line 283


Change "e.g," to "e.g.,".



Line 288, 304


Why must the time be identifiable?  Why is it not sufficient to

just preserve the order of submissions, e.g., in a queue?



Line 292


Move to the next page (i.e., keep it with the following paragraph).



Line 294


Change "Reliablity feature" to "reliability features".



Line 297


Remove "A Message Identifier is".  Remove the comma after "header".



Line 302


Remove "Message delivery is".  Change "deliver" to "Deliver".



Line 304


Change "(application)" to "(e.g., the application)".



Line 316, 317, 319


"Acknowledgment messages" are not defined.  There are now only

"Acknowledgment indications".



Line 329


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?



Line 336


A reply may now include multiple Acknowledgment Indications.



Line 340


Remove one of the spaces in "in  a".



Line 353


Make the sentence begining "This polling pattern is generally

expected..." into a note following the definition since this sentence

is more a comment than a definition.



Line 355


Change "behind the firewall cases" to "e.g., when behind a firewall".



Lines 297 to 356


Reorder the definitions to reduce the forward references:


Message Identifier

Duplicate Message

Message Delivery

Reliable Message

Acknowledgment Indication

Acknowledgment Message (new definition)

Reliable Messaging Fault Indication

Reliable Messaging Reply

Response RM-Reply Pattern

Callback RM-Reply Pattern

Polling RM-Reply Pattern

PollRequest Message



Section 1.7, The Reliability agreement



Line 357


Change "agreement" to "Agreement" to match the capitalization style of

similar headings.



Line 362


Change "notify operations on" to "and notify operations at".



Line 366


"between the application layer, the sender and receiver RMPs" does not




Section 1.7.2, RM Agreement Items



Line 388, 390, 392


Change "period" to "period.".



Lines 388-406


Should this list be a table with "Name", "Value", and "Definition"




Section 1.7.3, Messaging Scope of Agreement Items



Line 415


Change "is affecting" to "affects".



Section 2, Messaging Model



Line 450


Change "message" to "messages" twice.



Line 458


Change to "The three ways to send back an Acknowledgment message or a

Fault message are as follows:".



Line 461, 467, 474


Remove "With this message reply pattern,".



Line 463


Change "The figure 1" to "Figure 1".



Line 468


Change ")," to ")".



Line 469


Change "The figure 2" to "Figure 2".



Line 488, 491


Change "In case" to "When".



Section 3, Reliability Features



Line 499


"Business payload" is undefined.



Section 5, Operation Aspects and Semantics



Line 1263


Number the table and make this the title for the table.



Line 1271


Why are "Supported" and "Disallowed" so large?



Appendix A



Line 1604


Change the section numbers to "A.1.", etc.



Line 1605


Add a space after ")".



Line 1606


Change "supported/required" to "supported or required".



Line 1628


Merge this section into Section 1.3.






Tony Graham


Action: Iwasa to apply all editorial changes from Tony’s mail, except for those he considers in need of discussion.



9         Liaison activities with EbMS  - joint meeting


Met jointly.


Alan: can EBMS be used with WS-Reliability.


Ian: today the answer is no.


Ian: the main issue for discussion is how eb-ms can use ws-reliability in a future version of eb-ms.


Tom: we are trying to facilitate a-future version of eb-ms being able to use ws-reliability.


Jeff T: we would need to have a ws-reliability header in a message but used in a non-reliable manner.


Jeff T: they have a need for messageID but not for reliability purposes.  We need a reference to a message ID. 


Doug B: There is a need to use message correlation features in eb-ms without need for guaranteed delivery or duplicate elimination.


Iwasa: The current spec has all three qos values optional.  Guaranteed delivery, duplicate elim, and ordered delivery are all optional.  If neither are present in an rm-request without syntax errors, there will be no rm-reply under the current ws-reliability protocol.  However, a header being broken would cause an rm-headerFault returned.


Doug: ref to message id in ws-reliability supports single or multiple references to messages.


Doug: this is ok.


Ian: another discussion is how to reorganize grouping of the header blocks to work out what is what. 


Doug: the ws-reliability TC has also discussed putting our header blocks in a common wrapper header element.


Ian: my point of view is that we could define a common style for having grouping elements to identify which specs are in use.  Wss has a security container.


Sunil: having wrappers might affect composition.


Jeff T: having a wrapper can ease implementation.  One handler can be dispatched for all ws-reliability features.


Doug B: the reason to ask the question here is to, if we agree, we can send a message to the tab for a common style.


Matt M: putting things with a common default namespace in the same header type can ease implementation as well.


Jacques: Hamid, in our TC, wanted a way for the rmp to make decisions without looking into the soap body.  He wanted to have an attribute to put in the reliability header to distinguish whether an rm-request is piggybacked with a rm-reply.


Sunil: this is purely style concern, however I like it, because it puts a context around the headers named simply request and response.


Ian: this allows implantations which are not properly namespace aware.  It allows for evaluation of an xpath by a processor which is not fully namespace aware.


Jeff: it helps the readability of the schema.


Ian: if wsrm TC decides to add a common header wrapper (as WSS and each ws-caf spec drafts) then Tom and I as chairs should send a note to the TAB to recommend a common specification practice for OASIS specs.


Take it as a public comment from eb-ms group on suggesting a common security header.


In the future, when there are TC meetings collocated, we should ensure that the only overlap time for eb-ms and wsrm TC is joint meeting time.


10   Sunil new issues


Sunil: for a group we say qos should be the same for all messages in the group.  If so, why do we have to send the qos parameters every time.  Why not send them only on the first message for the group.


Jacques: the first time the receiver receives a message from the group takes those qos values and use them for the lifetime of the group.


Tom: could send them until the first ack is seen by the sending RMP.


Will discuss on Thursday.


Sunil: if the receiver demands a qos level, but the sender does not assert it, how does the receiver react.


Tom: we discussed this in the past that the receiver can send a soap client fault in this case. 


Jacques: but this will not work for wsdl one-way operation type.


Tom: we decided this condition is out of scope of this spec.


Jacques: receiver side only enforces reliability requirements visible in the protocol.  The concern Sunil is expressing is out of the scope of this specification.


Tom will send a pointer for the original issue resolution in this area.


11   Planning for Future CD Balloting


Most aggressive timing: assuming 3 implementations by May 10


May 29 : Final Editors draft posted


May 3 – member editorial review comments due


May 4 – TC votes for editorial changes, and to initiate final CD 1.0 ballot


May 5 – CD ballot begins


May 12 – CD ballot closes


May 14 – Submit package to OASIS for OASIS Standard Processing


Alternative: to agree on all changes by May 4 TC meeting


Editors post final review draft by Friday May 7.


May 11 meeting we vote on a CD 1.0 completely ready to go.


May 14 – submit to OASIS.


Tom should put out a call for IPR claims.


Look at this tomorrow.

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