W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2006

Re: Fw: multiple MEPs per binding

From: <noah_mendelsohn@us.ibm.com>
Date: Thu, 13 Apr 2006 23:20:59 -0400
To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Cc: xml-dist-app@w3.org
Message-ID: <OF9AE41C69.297741EF-ON85257150.00076C15-85257150.0012676F@lotus.com>

Anish Karamarkar writes:

> noah_mendelsohn@us.ibm.com wrote:
> > Anish Karamarar writes:
> > 
> > 
> >>the compatibility/interop issues can be handled by requiring that 
> >>only the new MEPs (ROR/FAF) include the HTTP header (the older MEPs 
> >>may include it as well, but will not be required to).
> > 
> > 
> > Indeed, though it seems like one more level of complexity, and perhaps 
> > 
> > more reason that existing HTTP implementations might not interact well 

> > with SOAP.  For example, I don't remember offhand what typical HTTP 
> > proxies will do with headers such as this (I'm flying at the moment 
> > don't have the RFC handy.)
> Would this be any different than how HTTP proxies handle SOAPAction http 

> header (in SOAP 1.1)?

Not sure.  I'm forgetting the HTTP rules on extra headers.  There may be 
no issue.
> >  So, I'm a bit reluctant to introduce this 
> > complexity without a compelling reason, but maybe there is one.  For 
> > it looks to me like we have 3 potential MEPs to be widely deployed, 
> > the two that are in SOAP 1.2 and already supported by the HTTP 
> > and the one-way.  The former are already well distinguished by 
> > and as you know I still think it would be a misuse of HTTP to support 
> > one way, unless the binding required a non-envelope response under the 

> > covers anyway. 
> > 
> Right, SOAP-response MEP (uses GET) or a one-way MEP (won't be supported 

> by our HTTP binding) is not a problem, but we have two MEPs req-res and 
> ROR that use POST. How does a receiver figure out which MEP was intended 

> by the sender?

Well, we decided to do ROR not as a new MEP, but on the theory that the 
original req/res was ambiguous and that we would clarify it.  As far as I 
know, there is only one MEP, but with clarified requirements as to whether 
there need be an envelope, and a clarified HTTP binding that more 
carefully explains the use of status code 202.  Right?  I'm told lots of 
implementations already take that interpretation, particularly if they are 

> The strange thing is that with request/optional response, you could 
> what appears to be a one-way on top of it.  In other words, have the 
> binding itself know about req/opt-resp, and on top of that build a 
> convention that says "in this mode, there is never an envelope in the 
> response, and indeed the application API will never show you the 
>  The only artifact of the response is that under the covers we'll wait 
> it before closing the socket.  I'm a bit nervous about having MEP's 
> out of other MEPs, but I think it would work in principle.  You 
> have an MEP (one way with under the covers acknowledgement) that can be 
> bound to any binding that supports request/opt-resp.   Not sure what's 
> best here.

I don't think we need to go there right now.  As I said above, I think all 
we've done is (somewhat post facto) clarified our intentions regarding the 
original SOAP 1.2 Request/Response.  My interpretation is that the term 
ROR is just one we're using among ourselves to refer to the clarified 

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Friday, 14 April 2006 03:21:09 UTC

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