Re: Response envelope optional vs. response optional

My issue here is that "response" is ambiguous.  The current SOAP MEP
language only talks explicitly (as I understand it), about a /SOAP/
request and a /SOAP/ response.  Under the
extension/clarification/erratum, we're now talking about recognizing a
no-envelope response.  If you just look at SOAP traffic (which makes
most sense to me), then this is SOAP request and optional SOAP
response.  If you think of a response as something coming back, then
this is SOAP request and a SOAP or no-envelope response.  I'm much less
comfortable with this.  By that logic, "response only" is actually
request-response as well: A non-envelope request (the GET) and a SOAP
response.

The "cheese sandwich with no bread" issue is slightly different.  I
don't like the idea of defining a generic "request optional-response"
MEP and binding it to a one-way transport, where we know there will
never be a response.

[email protected] wrote:

>Anish:  thanks for your thoughtful reply.  I think this is very helpful in 
>moving us forward:
>
>Anish Karamarkar writes:
>
>  
>
>>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.
>>    
>>
>
>I mildly disagree.  As I mentioned in my earlier note, the crucial 
>characteristic of this pattern is that there >is< a mandatory response. 
>The client invariably waits for a response, and always gets one.  The only 
>question is whether that response carries an envelope.  I think it's a 
>meat and veggie sandwich in which the meat can be left out to suit the 
>taste of vegetarians. 
>
>Still, if we want to adopt the design and change the name to something 
>else reasonable that would be OK I think. For the reason above, I don't 
>think I'd want to call it Request/Optional-Response, though I might live 
>with that too if pressed.
>
>  
>
>>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.
>>    
>>
>
>I would disagree very strongly with talking about the subsequent delivery 
>of the SOAP Response in the cases where a 202/204 was returned.  My view 
>is that, with this pattern, there is no obligation to do anything further 
>at all after the 202/204, at least not at the SOAP level.  If some higher 
>level pattern chooses to deliver other SOAP messages as a result of this 
>interaction, so be it.  My intent was that this SOAP MEP also be usable in 
>cases where a single SOAP envelope was to be sent over HTTP, a 202/204 
>returned, and nothing further happens. 
>
>I think it's very important that we not be tempted into mixing higher 
>level messaging patterns into the SOAP MEPs.  The SOAP MEPs are a contract 
>that helps to make bindings interchangeable, IMO.  If two bindings 
>implement the same SOAP MEP(s), then the chances are good that you can 
>switch from one to the other.  So, if a non-HTTP transport implemented the 
>binding we're discussing, it too would be usable to deliver a message with 
>a wsa:ReplyTo.  In neither case would we be discussing how the actual 
>reply is to be delivered, as that is covered at a higher level by WSA.
>
>So, I don't want to talk about the higher level response.  If that means 
>renaming the binding then that's OK with me, but I'm not convinced it's 
>necessary.  Doing so may or may not make it a bit harder to take this 
>through the W3C process quickly.  In particular Req/Resp is a normative 
>part of SOAP 1.2, so other specs and implementations may in principle 
>refer to it by name.  If we change the name, then I think that's an 
>incompatibility of a sort, albeit a minor one operationally.  My vote for 
>now would be to keep the name.
>
>Thanks!
>Noah
>
>--------------------------------------
>Noah Mendelsohn 
>IBM Corporation
>One Rogers Street
>Cambridge, MA 02142
>1-617-693-4036
>--------------------------------------
>
>
>
>
>
>
>
>
>Anish Karmarkar <[email protected]>
>12/20/05 05:45 PM
> 
>        To:     [email protected]
>        cc:     [email protected]
>        Subject:        Re: Response envelope optional vs. response 
>optional
>
>
>[email protected] 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
>>--------------------------------------
>>
>>
>>
>>
>>
>>
>>    
>>
>
>
>
>  
>