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

[Fwd: Re: multiple MEPs per binding]

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Tue, 28 Mar 2006 23:03:39 -0800
Message-ID: <442A314B.2010405@oracle.com>
To: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
Forgot to cc the ML.


attached mail follows:


Not sure if this was discussed in the last two concalls (which I did not 
attend) as I haven't gone through the minutes yet, but 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).


noah_mendelsohn@us.ibm.com wrote:
> Anish Karamarker writes:
>>Shouldn't we then provide a way to specify what binding/MEP is being
>>used at the protocol level. I.e., a HTTP header
> I'm pretty sure we considered and rejected this, given that the two MEPs 
> we implemented were already distinguished by GET.  I think there are at 
> least a few reasons to proceed with caution in this area:
> 1) compatibility:  the binding we have is workable today, and requiring 
> the header will raise questions regarding interoperation between old-style 
> implementations that don't send the header and those that expect it.
> 2) interoperation with Apache-style servers:  we note in the SOAP Rec that 
> you can put an ordinary application/soap+xml format file up on Apache and 
> our current binding will correctly retrieve and process it using GET. 
> Perhaps more importantly, an implementation of our binding will respond to 
> a garden-variety GET, as might come out of a browser, web-crawler, etc. If 
> we don't recognize requests without the header, then I think we break 
> those scenarios.
> 3) W3C Process:  I think this is an incompatible change.  We'd need to 
> rename the binding, if only to call it version 2 or some such, and we'd 
> have to go through a new CR I would think.  We'd then be hung up in moving 
> forward until implementations were done.
> I'm not saying there isn't some merit to the idea in principle.  In 
> practice, I suspect that the considerations above outweigh any advantages, 
> at least in the short term.  For those reasons I would at the very least 
> suggest some careful discussion;  I don't think we should assume too 
> quickly that this is a good idea just because it does have some 
> architectural advantages.
> I may be missing something.  If so, please don't hesitate to point it out. 
>  Thank you!
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
Received on Wednesday, 29 March 2006 07:03:51 UTC

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