status of ROR

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

status of ROR

Christopher B Ferris

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: [hidden email]
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
Reply | Threaded
Open this post in threaded view
|

Re: status of ROR

Christopher B Ferris

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: [hidden email]
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295


[hidden email] 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: [hidden email]
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
Reply | Threaded
Open this post in threaded view
|

Re: status of ROR (part deux)

Christopher B Ferris
In reply to this post by Christopher B Ferris

All,

As I was reviewing the changes, I was struck by the following text in Noah's draft [1] in sections
7.5.1.3 Sending+Receiving and also in 7.5.1.4 Receiving,

To wit:

        ***Similarly, receipt of any response entity-body with a status code of 202 is not normative.
        If such an unexpected response is of type "application/soap+xml", then SOAP processing of
        that response is beyond the scope of the specification for this binding.

While I think that this is technically correct, I think that it is somewhat misleading, and I also think that
it is inconsistent with the resolutions in my previous email in which we say that the response
envelope, if present, SHOULD be processed according to the SOAP process rules in 2.6.

I would therefore offer this proposed amendment:

        *** Similarly, although receipt of any response entity-body with a status code of 202 is not normative,
        in the event that such a response entity body is of type "application/soap+xml", then the response
        envelope SHOULD be processed in accordance with 2.6 Processing SOAP Messages [2]

[1] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2OptRespMEP.html
[2] http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#procsoapmsgs

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: [hidden email]
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295


[hidden email] 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: [hidden email]
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
Reply | Threaded
Open this post in threaded view
|

Re: status of ROR (part deux)

noah_mendelsohn

The reason I'm not entirely supportive of Chris' proposal is that it's not
entirely clear to me that in all cases where a 202 is received we want the
receiving bit of software to act as a SOAP node.  You could imagine 202
being used as a sort of tunnel, in which the transport is being used to
move around SOAP envelopes, and only some of the places those envelopes
land need be SOAP nodes.  Furthermore, if an MEP or binding calls for SOAP
processing, then I think it should answer some other questions, such as
where to deliver faults that may result from such processing.  I'm not
strongly against telling that story about envelopes received with 202's,
if that's what everyone wants, but I am against telling the story vaguely
or incompletely.  So, my current inclination is either to stick with what
I've got (mild preference for that), or to write a somewhat more complete
story, starting with what Chris drafted, but adding some words about how
no normative rules are provided for further transmissions of faults
generated by such processing, maybe say that this binding makes no
statement as to whether such a node is to act as the ultimate receiver (we
don't say that about other messages either, though perhaps we should, but
in this case it seems to me that the situation is so bizarre from an MEP
point of view that it's of some value to be explicit.)  Not sure how much
time it's worth tuning up things like this.

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------





Reply | Threaded
Open this post in threaded view
|

Re: status of ROR

noah_mendelsohn
In reply to this post by Christopher B Ferris

I have prepared and checked into CVS a new editors' draft at [1,2]. Please
accept my regrets for tomorrow's telcon, as I will be flying back from the
schemas meeting.

The following describe the changes since the previous editors draft, using
Chris' instructions as a guide.

> Starting with the draft used to produce this editor's version:
>        
http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2OptRespMEP.html 

Done.  I merged the soap12-part2OptRespMEP.xml into soap12-part2.xml.
Diffs suggest that I did the merge faithfully and did not unintentionally
back out other changes (actually, I didn't find any conflicts), but it
would be good if anyone who knows of changes made since 2005/12/21 would
doublecheck that they have survived intact.

> 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.' 

Done.


> 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.

Done.

 > (note that the reference to sect 2.6 should probably be a hyperlink
> to the relevant section in SOAP1.2 part 1)

In keeping with the style of similar references, the exact text is now:

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 the SOAP
Processing model (see SOAP 1.2 Part 1 >>>[SOAP Part 1]<<<, section >>>SOAP
Processing Model<<<).

The >>>XXX<<< are added in this email to show where hyperlinks are.
>>>[SOAP Part 1]<<< is our traditional reference to the biblio entry for
SOAP Part 1, and >>>SOAP Processing Model<<< is a direct link to 2.6 in
part 1.  Essentially the same construction is used elsewhere in Part 2,
though it should be noted that there are also several places where part 2
asks you to use the SOAP processing model without hyperlinking it.   I
think what I've checked in is one of the several acceptable forms, but I
suppose we could entertain motions to make them all consistent.   I
believe they've been inconsistent in style all along.

> 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>

Done, modulo similar editorial license on the form of hyperlinks to part
1.

So, I think we're all set with the merge that Chris had requested, and I
believe that I have fulfilled my editorial responsibility to the group on
this, at least for now.

Noah

[1] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.xml
[2] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.html

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Christopher B Ferris <[hidden email]>
Sent by: [hidden email]
08/07/2006 08:40 AM
 
        To:     Christopher B Ferris <[hidden email]>
        cc:     [hidden email], [hidden email], (bcc:
Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: status of ROR



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: [hidden email]
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

[hidden email] 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: [hidden email]
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295


Reply | Threaded
Open this post in threaded view
|

Re: status of ROR

Christopher B Ferris
In reply to this post by Christopher B Ferris

Thanks, Noah

Christopher Ferris
STSM, Software Group Standards Strategy
email: [hidden email]
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295


Noah Mendelsohn/Cambridge/IBM wrote on 08/23/2006 01:24:20 AM:

> I have prepared and checked into CVS a new editors' draft at [1,2]. Please
> accept my regrets for tomorrow's telcon, as I will be flying back from the
> schemas meeting.
>
> The following describe the changes since the previous editors draft, using
> Chris' instructions as a guide.
>
> > Starting with the draft used to produce this editor's version:
> >        
> http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2OptRespMEP.html
>
> Done.  I merged the soap12-part2OptRespMEP.xml into soap12-part2.xml.
> Diffs suggest that I did the merge faithfully and did not unintentionally
> back out other changes (actually, I didn't find any conflicts), but it
> would be good if anyone who knows of changes made since 2005/12/21 would
> doublecheck that they have survived intact.
>
> > 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.'
>
> Done.
>
>
> > 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.
>
> Done.
>
>  > (note that the reference to sect 2.6 should probably be a hyperlink
> > to the relevant section in SOAP1.2 part 1)
>
> In keeping with the style of similar references, the exact text is now:
>
> 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 the SOAP
> Processing model (see SOAP 1.2 Part 1 >>>[SOAP Part 1]<<<, section >>>SOAP
> Processing Model<<<).
>
> The >>>XXX<<< are added in this email to show where hyperlinks are.
> >>>[SOAP Part 1]<<< is our traditional reference to the biblio entry for
> SOAP Part 1, and >>>SOAP Processing Model<<< is a direct link to 2.6 in
> part 1.  Essentially the same construction is used elsewhere in Part 2,
> though it should be noted that there are also several places where part 2
> asks you to use the SOAP processing model without hyperlinking it.   I
> think what I've checked in is one of the several acceptable forms, but I
> suppose we could entertain motions to make them all consistent.   I
> believe they've been inconsistent in style all along.
>
> > 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>
>
> Done, modulo similar editorial license on the form of hyperlinks to part
> 1.
>
> So, I think we're all set with the merge that Chris had requested, and I
> believe that I have fulfilled my editorial responsibility to the group on
> this, at least for now.
>
> Noah
>
> [1] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.xml
> [2] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.html
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>
>
>
> Christopher B Ferris <[hidden email]>
> Sent by: [hidden email]
> 08/07/2006 08:40 AM
>  
>         To:     Christopher B Ferris <[hidden email]>
>         cc:     [hidden email], [hidden email], (bcc:
> Noah Mendelsohn/Cambridge/IBM)
>         Subject:        Re: status of ROR
>
>
>
> 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: [hidden email]
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
> [hidden email] 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: [hidden email]
> > blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> > phone: +1 508 377 9295
>