Re: Signaling MEPs

As I said at the F2F, my view is that supporting multiple MEPs per binding 
should be allowed, but should be viewed as somewhat exceptional.  In the 
particular case of HTTP, I think there was value in the tradeoff we 
adopted primarily because:

* Separating Request/Response from Response-only has value because we can 
easily imagine other bindings that might want to support one without the 
other.  By separating the two, we make it possible to indicate that 
request/response applications may work quite compatibly over the two or 
more bindings, while GET applications might work over only HTTP (though, 
of course, there could be other bindings that would support GET too).

* There was a natural and appropriate signaling mechanism in HTTP.

So, I think we should allow other bindings to support multiple MEPs when 
it's a natural thing to do.  I don't think it should be encouraged as 
common practice, and in particular I don't think we should be trying to 
invent general mechanisms for signaling the MEP to use. 

Right now, I'm not aware of a need to support additional bindings in HTTP, 
since I believe that the one-way FAF MEP we are contemplating would not 
appropriately be supported on HTTP in any case.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Marc Hadley <Marc.Hadley@Sun.COM>
Sent by: xml-dist-app-request@w3.org
03/15/2006 02:57 PM
 
        To:     Mark Baker <distobj@acm.org>
        cc:     "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>, (bcc: Noah 
Mendelsohn/Cambridge/IBM)
        Subject:        Re: Signaling MEPs


On Mar 15, 2006, at 1:00 PM, Mark Baker wrote:
>
> I think either of those options are problematic because each would be
> ignored when encountered by existing agents.
>
True enough, whatever we did would only be advisory since there's no 
mU-type functionality in either of the mechanisms I suggested.

Doug Davis contacted me privately and suggested that we could also 
consider doing something inside the envelope which is an option I 
didn't mention. One thing that springs to mind is use of a 
wsa:ReplyTo with a "none" [address].

> In general, deploying MEPs which aren't compatible extensions of
> existing MEPs is problematic because of this extensibility problem.
> Had SOAP 1.2 used RFC 2774 as SOAP 1.1 did, this wouldn't be as big an
> issue.
>
Agreed, though for the case of one-way there is some evidence that 
implementations are already doing the right thing based on WSDL 
information and the WS-I basic profile so its possible that we'd be 
merely formalizing something that is already happening rather than 
adding a new capability.

> And regarding the oneway example, can I ask why it's necessary to
> indicate the oneway-ness of an interaction in the request message?
> Any other motivating examples for this practice?
>
That's not entirely clear to me either (I just took the action to 
start the conversation). One thing mentioned was to allow a receiver 
to distinguish between request-response, request-optional-response 
and one-way to enable it to follow the MEP contract accordingly.

Marc.

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.

Received on Wednesday, 15 March 2006 23:05:28 UTC