Re: Preliminary work on making envelope optional

Noah/All,

Nice job. Some comments on the revised HTTP binding.

6.2.2 Description
***The SOAP Request-Response MEP defines a pattern for the exchange of a 
SOAP message acting as a request followed by a message acting as a 
response. The response message MAY contain a SOAP envelope, or else the 
response MUST be a binding-specific message indicating that the request 
has been received. In the absence of failure in the underlying protocol, 
this MEP consists of exactly two messages.
I think that it may make more sense to state the following:
        The response message is a binding-specific response that MAY 
contain a SOAP envelope.
I would not make any claims as to what the response message indicates 
(e.g. whether or not the message was received).

In the normal operation of a message exchange conforming to the 
Request-Response MEP, a request message is first transferred from the 
requesting SOAP node to the responding SOAP node. Following the successful 
processing of the request message by the responding SOAP node, a response 
message is transferred from the responding SOAP node to the requesting 
SOAP node. 
How about: 
        In the normal operation of a message exchange conforming to the 
SOAP Request-Response MEP, a request message, containing a SOAP envelope, 
is ...

In Table 7 in the Transition column on the "Receiving" row it reads:
        ***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. 
I'm a little confused. The definition of the OutboundMessage is:
        An abstract structure that represents the current outbound message 
in the message exchange. This abstracts both SOAP Envelope and any other 
information structures that are transferred along with the envelope. 
It seems to me that in the case of an HTTP 202 Accepted response, that 
something needs to tell the binding that the message was accepted. I would 
have thought that that would constitute "other information structures", 
but maybe not? Does this mean that there's a missing property? Something 
that indicates to the binding layer the disposition of the received 
message? Just a thought.
Similarly, in the Action column corresponding to the above it says:

        ***Initiate transmission of response message. If an envelope is 
provided in abstracted in  
        http://www.w3.org/2003/05/soap/mep/OutboundMessage then include 
that in the response message. 
The part that says: "if an envelope is provided in abstracted..." seems to 
imply that the envelope is optional in the OutboundMessage (in the context 
of the responding SOAP node), which seems to suggest as I did above, that 
the disposition is actually a part of the abstraction of OutboundMessage. 
I think that it will be important that we make this clear and consistent. 
I personally think that in all cases, there is an OutboundMessage. It may, 
or may not as the case may be, contain a SOAP envelope. Thus, I think that 
we could leave the transition column above as: 
 
        Start of response envelope available in 
http://www.w3.org/2003/05/soap/mep/OutboundMessage 
Table 19
        ***Only if status line is 200, the SOAP message serialized 
according to the rules for carrying SOAP messages in the media type given 
by the          Content-Type header field. 
Actually, a SOAP fault should be accompanied by one of the HTTP response 
codes as defined in table 20. I think it would be best to say:
        Unless the status line is 202, the SOAP message ...
Cheers,
Christopher Ferris
STSM, Emerging e-business Industry Architecture
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 01/10/2006 07:40:32 PM:

> 
> Following up on my message of yesterday [1], I have updated the draft to 

> include a first cut at a revised HTTP binding [2,3].  I fixed one or two 

> other misstatements in yesterday's draft as well, so you should reread 
the 
> whole thing.  As expected, the changes are relatively straightforward, 
and 
> are mostly aimed at specifying the use of status code 202.  As with the 
> first posting, you can find all of the changed text by searching for 
> "***", which I used as a preliminary form of diff markup.  I'm sorry I 
> didn't get this done earlier, but perhaps we can have a preliminary 
> discussion on the call tomorrow.  I added a couple of ednotes as well.
> 
> Also, I seem for the moment to have lost control of the date line on the 

> title page.  It erroneously lists the revision date as tomorrow: 
"editors' 
> copy $Date: 2006/01/11 00:29:32 $".  I have no idea where the stylesheet 

> is getting this, as I've checked both the xml source and the dtd. Surely 

> I'm missing something obvious.  Since this is just a branch draft for 
> discussion, I won't worry about it for now.  If we decide to integrate 
> these changes as an official editor's copy then we'll have to fix it.
> 
> Again, I must apologize for not having also read and reviewed David 
> Orchard's draft.  Now that I've completed my action item, I can get back 

> to that.  I do think the direction signaled in [2] is workable, is a 
> modest change to our already published rec, and is generally promising. 
> Obviously I won't comment on the comparison with David's approach until 
> I've had a chance to read and think about it. 
> 
> Enjoy.
> 
> Noah
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0037.html
> [2] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2OptRespMEP.html
> [3] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2OptRespMEP.xml
> 
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
>