Re: Signaling MEPs

Just for clarification, is it your position that each underlying  
protocol should only have one binding (which might support multiple  
MEPs but that would be an exception) ?

I ask because if there are multiple bindings per underlying protocol  
then rather than signal the MEP in use one might instead need to to  
signal the binding in use. I suspect the mechanism for signaling  
either would be similar.

Marc.

On Mar 15, 2006, at 6:05 PM, noah_mendelsohn@us.ibm.com wrote:

>
> 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.
>
>
>
>
>

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