Re: Response envelope optional vs. response optional

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

+1

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


This makes the name of the SOAP MEP a misnomer. As DavidH calls it: a 
cheese sandwich with no bread.
The Request-response MEP consists of a Request SOAP env and a Response 
SOAP env.
Either we have to rename the SOAP MEP or specify how the Response SOAP 
env may be delivered (using a different HTTP connection) when the 
202/204 status is used.

> * 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.
> 
> That's it.  Maybe or maybe not we later add a true one way MEP, in which a 
> response is never allowed.  That's implementable over HTTP, but it's not a 
> good match to the case where a response may sometime be sent.  If there's 
> even a chance that a response will be sent, then you need to pick an 
> explicit time to say "no, I'm not sending one after all".
> 
> Noah
> 
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
>

Received on Tuesday, 20 December 2005 22:45:50 UTC