W3C home > Mailing lists > Public > xml-dist-app@w3.org > December 2005

Response envelope optional vs. response optional

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 14 Dec 2005 10:58:34 -0500
To: xml-dist-app@w3.org
Message-ID: <OF55B55600.48CFB58E-ON852570D7.0056A344-852570D7.0057C713@lotus.com>

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 Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Wednesday, 14 December 2005 15:59:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:28 UTC