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: Work in progress [Fwd: Changes in update to contribution]

As noted in the attached email to the editing team early this morning, 
Jacques and I found a way forward that works for us on Section 2.  I am now 
working on the rest of the edits needed for tonight's (final!) draft.  Most 
of those edits have been discussed only within the editing team.

As a checklist for myself and to allow everyone to check I am do not forget 
something, these changes include (all line numbers from latest 

* updated content lengths that Iwasa provided

* follow through on editorial suggestions Mark Peel just provided (thanks 
again Mark!) to the editing team; we are at the 'add "the" before' point!

* change clause starting on line 175 to read
... (2) as a rule guaranteeing that if “Submit” completes successfully for 
a payload on the sending side, the “Deliver” operation completes 
successfully for this payload on the receiving side or else “Notify” (of 
failure) will be invoked on the sending side
based on some comments Jacques made on the "proofed version of 1.082 thread".

* remove first "only" in line 287, a typographic error in Mark's contribution

* avoid the "successful invocation" implications in the first sentences of 
Sections 3.2.1-3.2.3 (line 524 for example) with rewordings such as "When 
the GuaranteedDelivery Agreement Item is enabled, one of the two following 
outcomes SHALL occur for each Submit invocation on a Sending RMP:"

* change clause in line 828 from "A Receiving RMP supporting a received 
PollRequest" to "A Receiving RMP that receives a supported form of 
PollRequest", clarifying the meaning a bit

* replace two sentences starting at line 1031 with
If the specific RM Fault encountered was due to a problem with the Request 
header element, the Receiving RMP MUST set the value of the 
soap:Fault@faultcode attribute to "soap:Client" (for SOAP 1.1 messages) or 
the soap12:Fault/Code/Value element to "soap12:Sender" (for SOAP 1.2 
messages). If the specific RM Fault encountered was due to a problem with 
processing by the Receiving RMP, the Receiving RMP MUST set the value of 
the soap:Fault@faultcode attribute to "soap:Server" (for SOAP 1.1 messages) 
or the soap12:Fault/Code/Value element to "soap12:Receiver" (for SOAP 1.2 
to correct the SOAP 1.1 "versus" 1.2 issue Jacques pointed out and was 
mentioned in a response on the "Contribution suggestions just uploaded" thread

* addition of Delivery failure to Table 25, near line 1056 as another case 
for MessageProcessingFailure, based on resolution of comments from Jacques 
which started on the "proposed edits for enhancing composability" thread

* reword parenthetical comment starting at line 1092 to "(...; that is, any 
type not defined in this core namespace is allowed)", undoing a change to 
our meaning here and making the wording less confusing

* change introduction to bullets starting at line 1115 to "Groups 
undergoing termination on the Sending RMP and the Receiving RMP
pass through the following states:", avoiding discussion of a termination 
process and clarifying the states in question

* strike "associated with WSDL elements" at line 1809, based on a number of 
questions including the original "what changed in 1.08?" email.  No voices 
raised against this change.

Again, I am starting with the contribution I uploaded early this morning. 
In turn, that document is based on Mark Peel's 1.083 contribution[2] and 
some of my previous contribution[3] (started with the 1.082 root[4]).



--- Begin Message ---
I just uploaded a contribution[1,2,3] to our OASIS sub-site without 
notifying the TC.  The main reason is to give you a few hours this morning 
to check it improves on the issues Jacques and I discussed on the TC list. 
  Since we have received no comments besides Jacques' and my responses, I 
am working under the assumption that agreement between the two of us 
represents a solution the TC is comfortable with.  Note request for help in 
the last bullet near the end of this email.

For those playing along at home, the changes from my previous contribution 
(WS-Reliability-2004-08-07-drb.pdf) include:
* Moving Section 2.4.1 to be a new sub-section of 2.2, bringing the 
discussion of the RM operations together.

* Removing the remainder of Section 2.4 (just 2.4.2).  Jacques added this 
some time ago in response to some very old questions I asked.  I think we 
now agree the addition did not answer those questions and may confuse the 

* Removed all of the new paragraphs I added in Sections 2.5.1 through 2.5.3 
(now 2.4.1 to 2.4.3) because they only attempted (and failed) to link these 
sections to the previous 2.4.2 -- which no longer exists.

* Checked the formating of the Section references and updated a few (found 
one area of text which had made an entire sentence a hyper link!).

* Corrected the restrictions in 6.3, 6.3.1 and 6.3.2 to more obviously 
apply to the appropriate steps in the Poll RM-Reply Pattern.

So the specific changes in this contribution are:
* New Section 2.2.1 containing a slightly-edited version of the text 
previously in 2.4.1.  Describes how to map the RM operations to WSDL 

* In Section 2.3, added references to better explain the history of our 

* In same section, removed "correlation" bullet since our protocol does not 
require this.

* Removed all of Section 2.4 except text (2.4.1) added earlier in document 
(above).  This undoes a part of the changes Jacques made some time ago in 
response to our discussions (partially described in my "Summary of 
WS-Reliability 1.01* issues discussed over past week" email).

* Tightened up the SOAP MEP requirements in 2.5.1-2.5.3 (now 2.4.1-2.4.3) 
to support restrictions described in Section 6.

* Removed Section 5.2.  Most of this description is now in Section 2.  The 
table (28) in this section would mostly confuse the reader as the document 
looks today.

* A couple of minor corrections in Section 6, including new references to 
the appropriate sub-sections in Section 2.

* Narrowed at the end of Section 6.3 to apply specifically to the initial 
Reliable Message (rather than, say, the PollRequest message).

* Added similar restrictions for the PollRequest message and its response 
in Sections 6.3.1 and 6.3.2.  I am no longer sure these additions were 
necessary -- please check.  It seems right to discuss errors occurring when 
the PollRequest (and RM-Reply in the asynchronous polling case) messages 
are returned, however we did not do this before.  I am particularly unsure 
about the sub-sub-sub-cases of my addition to 6.3.2, which mention RM 
Faults and not different problems processing the just-received PollRequest 
or RM-Reply message.  I would appreciate some improvement suggestions here!

Any comments before I start with this tomorrow morning, adding the other 
decided changes?  I probably get up later than you do (I hope).



--- End Message ---

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