- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Mon, 7 Aug 2006 08:51:06 -0400
- To: Christopher B Ferris <chrisfer@us.ibm.com>
- Cc: xml-dist-app@w3.org, xml-dist-app-request@w3.org
- Message-ID: <OF3FAD78D1.46718448-ON852571C3.00465296-852571C3.00469902@us.ibm.com>
doh! I omitted the change required for table 17 Next State column for row 2. It should be changed to read: "sending+receiving" or "receiving", and then immediately to "success" if no envelope is received. Cheers, Christopher Ferris STSM, Software Group Standards Strategy email: chrisfer@us.ibm.com blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440 phone: +1 508 377 9295 Christopher B Ferris/Waltham/IBM wrote on 08/07/2006 08:32:36 AM: > Fulfilling my AI, here is, what I believe to be the set of edits > needed to be applied to fully resolve > SC1, 2 and 3. > > Starting with the draft used to produce this editor's version: > http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2OptRespMEP.html > > Change Table 7 - "Receiving" row > > From: > '***Either a) Start of response envelope available in > http://www.w3.org/2003/05/soap/mep/OutboundMessage or b) indication > from the application that no such envelope is to be send in the > response.' > > To: > 'Start of response available in > http://www.w3.org/2003/05/soap/mep/OutboundMessage.' > > Change Table 17, row 2 column 3 from: > > The request has been accepted, but no response envelope is > provided. Any further application > processing is beyond the scope of this use of the 6.2 SOAP Request- > Response Message Exchange Pattern***. > > to: > > The request has been accepted, but either (a) no response envelope > is provided or (b) an envelope representing information related to > the request is provided -- such envelopes SHOULD be processed using > 2.6 SOAP Processing model. > > (note that the reference to sect 2.6 should probably be a hyperlink > to the relevant section in SOAP1.2 part 1) > > Finaly, Replace: > <current> > 7.5.1.5 Success and Fail > > "Success" and "Fail" are the terminal states of the Request-Response and > SOAP-Response MEPs. Control over the message exchange context returns to > the local SOAP node. > </current> > > with: > > <proposed> > 7.5.1.5 Success and Fail > > "Success" and "Fail" are the terminal states of the Request-Response and > SOAP-Response MEPs. Control over the message exchange context returns to > the local SOAP node. > > If the "success" state has been reached and if a SOAP envelope has been > received, then the local node is a SOAP Receiver as defined in (reference > to section 1.5.3 of SOAP Part 1] [1]), and in particular MUST obey the > requirement of [reference to SOAP Part 1 Section 2.1 "SOAP Nodes"] [2] to > process the message according to the SOAP Processing Model [reference to > Part 1 section 2.6] [3]. > </proposed> > > Cheers, > > Christopher Ferris > STSM, Software Group Standards Strategy > email: chrisfer@us.ibm.com > blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440 > phone: +1 508 377 9295 > > xml-dist-app-request@w3.org wrote on 08/01/2006 08:43:23 AM: > > > > > Fulfilling my AI regarding the historical record of where we were > > with regards to the ROR, I find that we > > had resolved all three issues (SC1, 2 and 3) and had slightly > > amended the proposed text, and that > > what remained was to do a thorough review (which does not appear to > > have been done). > > > > What isn't clear is whether there is a draft of the spec that > > reflects all of these changes. I suspect > > that there is not, and that we will need to start with Noah's draft > > and apply the edits from the > > resolutions to SC1, 2 and 3 and all of the other resolutions as > > outlined below. Once that has been > > produced, I think that we all need to do a thorough review and > > report any other necessary tweaks to > > make consistent. > > > > The following is the relevant bits collected from the minutes as > > well as from emails related to > > closing SC1, 2 and 3 from the end of April and beginning of May. > > > > Minutes of April 26 telcon seem to reflect that we had resolved SC1, > > 2, and 3 with proposed > > amendment from me (expressed in the minutes) and that Mike was to > > draft text for the > > modified text for the spec (not done). >From the minutes: > > http://lists.w3.org/Archives/Member/w3c-xml-protocol- > > wg/2006Apr/att-0014/2006-04-26-minutes.html > > > > [NEW] ACTION: Mike to Draft text for "before dashes" based on > > Chris's friendly amendment. [recorded in http://www.w3. > > org/2006/04/26-xmlprotocol-minutes.html#action02] > > (DONE) http://lists.w3.org/Archives/Public/xml-dist- > > app/2006May/0000.html > > [NEW] ACTION: Mike to Show the conclusions of SC3 to the mailing > > list. [recorded in http://www.w3.org/2006/04/26-xmlprotocol-minutes. > > html#action03] > > (DONE) http://lists.w3.org/Archives/Public/xml-dist- > > app/2006May/0001.html > > [NEW] ACTION: Noah to Draft proposed text after Table 17. [recorded in > > http://www.w3.org/2006/04/26-xmlprotocol-minutes.html#action01] > > (DONE) http://lists.w3.org/Archives/Public/xml-dist- > > app/2006May/0003.html > > > > From the minutes of May 3, 2006: > > http://lists.w3.org/Archives/Member/w3c-xml-protocol- > > wg/2006May/0003.html > > > > > 5. SOAP 1.2 PER > > > > > > Proposal for ROR > > > Reworked proposal: > > > http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0050.html > > > HTML Part2 proposal: > > > http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2OptRespMEP.html > > > > > > Issues: > > > > > > SC1: 202 semantics. Table 17 for status code 202 row. > > > http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0052.html > > > - I believe this is now moot, see (NM/MB exchange): > > > http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0008.html > > > - Yet now continuing 202 and RX (2 separate requests) thread (DH): > > > http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0009.html > > > - New proposed text from last week around Table 17. Mike will post > > > agreed material, Noah will post new clarifying text after Table 17. > > > PENDING > > > > Noah: Based on last week's discussion, we agreed that an HTTP 202 > > response could indicate an optional SOAP envelope will follow. Found > > that there is text around the table that relies on the fact that there > > is no response envelope. Proposed text: > > > > "The request has been accepted, but the server makes no commitment > > as to whether processing of the request has been completed. If a > > response SOAP envelope is provided, than it may represent a partial > > response or a status update on progress of requst processing; if no > > response envelope is provided, then any further application > > processing is beyond the scope of this use of the 6.2 SOAP Request- > > Response Message Exchange Pattern***." > > > > Mike: We already accepted text from Chris for this part of the table. > > > > Noah: Use Chris' text, unless the above is better. > > Next, text states that there will be immediate transition from > > "receiving" to "success" as soon as 202 is received. Should be from > > both "sending+receiving" and "receiving", if no envelope is received. > > > > DavidH: Comfortable with Noah's proposed text. > > > > Noah: Table 17 is in a section entitled "Requesting". But this > > transition is to "success", so also needed to draft text for 7.5.1.5 > > "Success and Fail". > > > > Mike: Does this add conformance criteria? > > > > Noah: No, it's just clarification. > > > > DavidH: This won't change existing "200" implementations, because they > > do this anyway. > > > > Noah: New proposed text: > > If the "success" state has been reached, either as a result of ... or ... > > [See IRC log at http://www.w3.org/2006/05/03-xmlprotocol-irc > > Access to log is forbidden at the time minutes are being submitted.] > > > > Noah: Bug in 7.5.1.4: > > Indicate status code 200 ... response includes soap envelope.... > > Need to remove this. > > Look for everywhere the spec implies that 202 has no envelope. > > > > ACTION: Yves to perform critical review of changes SC1, SC2, SC3 to > > ensure the result is complete. > > > > > SC2: Semantics of response message. 6.2.2 > > > http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0051.html > > > - reworked in last telecon. New text is at: > > > http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0023.html > > > If no more pushback, then this is the final text > > > DONE > > > > > > SC3: OutboundMessage abstraction > > > http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0050.html > > > - discussed at some length last week, search for SC3 > > > > > > http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Apr/att-0004 > > > /2006-04-05-minutes.html > > > - Chris has a action here > > > DONE - final text from Chris. Mike will repost to list. > > > > Noah in his response to the posted draft minutes wrote: > > http://lists.w3.org/Archives/Member/w3c-xml-protocol- > > wg/2006May/0004.html > > > > As minuted: > > > > > Next, text states that there will be immediate transition from > > > "receiving" to "success" as soon as 202 is received. Should be from > > > both "sending+receiving" and "receiving", if no envelope is received. > > > > I think that should be: > > > > Next, text states that there will be immediate transition from "receiving" > > to "success" as soon as 202 is received. Should be >to< either > > "sending+receiving" and "receiving", and then immediately to "success" if > > no envelope is received. > > > > Do I have that right? > > > > > > Christopher Ferris > > STSM, Software Group Standards Strategy > > email: chrisfer@us.ibm.com > > blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440 > > phone: +1 508 377 9295
Received on Monday, 7 August 2006 12:51:35 UTC