Re: Optional SOAP response; the transfer binding view

Thanks.  I should tell you that the conclusion on the call is to explore a 
blend of the approaches.  From the (unapproved) IRC log:

1) Base MEP is invariably request/response, with envelope optional in both
2) What was Response-only is documented as a specialization of that?
3) Maybe or maybe not we do another specialization to cover the 95% case, 
which is that there's an outbound SOAP envelope
4) Attempt to document it all in the style of Dave's draft, with the 
caveat that we check carefully for edge cases not covered
5) Editors discretion whether state machines in the bindings continue to 
"pay their way"

DaveO has an action to do the next draft, but will be looking at the 
version I did (I.e. what you've commented on) for suggestions on details 
of status code handling, etc.  I don't see any reason why the result 
shouldn't be as acceptable (or unacceptable) as mine was with respect to 
your concerns.

I do note one detail not covered in Dave's current draft, that I expect 
should be in the future.  RFC 2616 seems to imply that an entity is 
required on POST [1]. 


===================BEGIN QUOTE FROM RFC 2616 =============
9.5 POST

   The POST method is used to request that the origin server accept the
   entity enclosed in the request as a new subordinate of the resource
   identified by the Request-URI in the Request-Line. POST is designed
   to allow a uniform method to cover the following functions:

      - Annotation of existing resources;

      - Posting a message to a bulletin board, newsgroup, mailing list,
        or similar group of articles;

      - Providing a block of data, such as the result of submitting a
        form, to a data-handling process;

      - Extending a database through an append operation.

   The actual function performed by the POST method is determined by the
   server and is usually dependent on the Request-URI. The posted entity
   is subordinate to that URI in the same way that a file is subordinate
   to a directory containing it, a news article is subordinate to a
   newsgroup to which it is posted, or a record is subordinate to a
   database.

   The action performed by the POST method might not result in a
   resource that can be identified by a URI. In this case, either 200
   (OK) or 204 (No Content) is the appropriate response status,
   depending on whether or not the response includes an entity that
   describes the result.

   If a resource has been created on the origin server, the response
   SHOULD be 201 (Created) and contain an entity which describes the
   status of the request and refers to the new resource, and a Location
   header (see section 14.30).

   Responses to this method are not cacheable, unless the response
   includes appropriate Cache-Control or Expires header fields. However,
   the 303 (See Other) response can be used to direct the user agent to
   retrieve a cacheable resource.

   POST requests MUST obey the message transmission requirements set out
   in section 8.2.

   See section 15.1.3 for security considerations.
===================END QUOTE FROM RFC 2616 =============

Someone who knows more of the details will have to remind me how this 
squares with application/x-www-form-urlencoded.  In any case, if we're 
shifting to Dave's proposal that the Request envelope be optional in the 
base MEP, I think we'll need to explain in the binding what HTTP does in 
the case that WebMethod is POST and no outbound message is provided.  This 
is already covered by the binding for Response-only, but we're potentially 
openning a new path, which is MEPs that are not the one we call 
"Response-only", but which in fact have no request envelope.

Noah

[1] http://www.faqs.org/rfcs/rfc2616.html

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








Mark Baker <distobj@acm.org>
Sent by: mbaker@gmail.com
01/11/2006 12:51 PM
 
        To:     "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>
        cc:     xml-dist-app@w3.org
        Subject:        Re: Optional SOAP response; the transfer binding 
view


Ok, nice; I guess I should have looked at your proposal before sending
that. 8-)  I had only looked at DaveO's proposal.

I have one comment, and some editorial patches for your proposal which
I'll send in a separate message.

Mark.

On 1/11/06, noah_mendelsohn@us.ibm.com <noah_mendelsohn@us.ibm.com> wrote:
> I think the redraft I posted at [1] is consistent with the assumptions 
and
> conclusions in your note.  Specifically, the inboundMessage and
> outputBoundMessage properties continue to consistent of the entire SOAP
> level message, including things like the WebMethod when appropriate. All
> that's changed is that (a) the request/response MEP makes clear that the
> response messages for that MEP need not contain a SOAP envelope and (b)
> the HTTP binding makes clear that the correct embodiment of an otherwise
> successful "no envelope" response is an status code of 202.
>
> Noah
>
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0050.html
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>


--
Mark Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

Received on Wednesday, 11 January 2006 18:23:07 UTC