Forgot to cc the ML.
-Anish
--
Forwarded message 1
Noah,
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).
-Anish
--
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
> --------------------------------------
>
>
>
>
>