Re: Response envelope optional vs. response optional

On Wed, 14 Dec 2005, noah_mendelsohn@us.ibm.com wrote:

>
> I think I'm coming close to a position on MEPs that I can personally
> support, and perhaps that IBM will formally endorse.
>
> In considering this discussion, it's slowly occurred to me that there is a
> crucial difference between making the response envelope optional, and
> making the whole response optional.   In the former case, you get an
> explicit confirmation from server back to client that there will in fact
> be no envelope.  In the case that the response as a whole is optional, or
> in one way, the client never hears back "ok, we're done".   This
> difference is important.  When you have a connection-oriented
> request/response underlying protocol such as HTTP, it's essential that the
> responding application at some explicit point in time either send a
> response or otherwise terminate the connection;  in the case of HTTP in
> particular we will likely do this by deciding to send a 202, though Chris
> suggests that 204 may be useful at times.  With a true one way, you
> wouldn't even know where to send that indication.

Well, there is a _big_ difference between 202 and 204, with 202 you can't 
tell if the envelope (even the null one) has been processed successfully 
or not. To be "truly" one way, 202 is the best option as it ensures that 
the underlying protocol did its job, but without any information from the 
SOAP stack.
In many connection oriented protocols, you can have formal confirmation 
(or at least string hints) that the data (the SOAP envelope) has been 
transfered, it is one of the property of the underlying protocol used.

We may have the following model
202 -> One way with nowhere to send fault
204 -> One way with a well known place to send fault  (of course it won't
        be 204 if there is a fault)

> With that background, here's the position that currently seems most
> attractive to me:
>
> * Modify the current request/response binding to state that the inclusion
> of an envelope in the response is optional (but not that the response as a
> whole is optional, in the sense discussed above.)
>
> * Modify the HTTP binding to make clear which status codes (presumably 202
> and maybe 204) map to the "no envelope response".
>
> * We take the mention of 202 in the current HTTP binding and the
> widespread implementation of it as evidence that the original
> recommendation was contradictory.  Per W3C process, this allows us to
> issue an erratum compatible with any legal reading, and we can reasonably
> say that this proposal fits that model.  The likely result of this would
> be to publish something like a SOAP 1.2 second edition.

In previous discussion, we talkd about the identification of the MEP in 
use by the originator, GET would map to a response only, while POST would 
map to the request-response.
Having the 202 in here forbid the client to know which MEP is expected 
(unless there is a tighter coupling, like the application knows from a 
WSDL description what to expect). Even worse, the GET -> 202 scenario is 
allowed? What does it mean?

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Received on Wednesday, 21 December 2005 14:24:02 UTC