RE: Response envelope optional vs. response optional

+1 to Noah's position below, because it matches my architectural
leanings, and especially if indeed we can do the work as an erratum.

--Glen

> -----Original Message-----
> From: xml-dist-app-request@w3.org 
> [mailto:xml-dist-app-request@w3.org] On Behalf Of 
> noah_mendelsohn@us.ibm.com
> Sent: Wednesday, December 14, 2005 7:59 AM
> To: xml-dist-app@w3.org
> Subject: Response envelope optional vs. response optional
> 
> 
> 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.
> 
> 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.
> 
> 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 Wednesday, 14 December 2005 17:34:09 UTC