W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2002

RE: One-way messaging in SOAP 1.2

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 1 Feb 2002 17:38:04 -0500
To: skw@hplb.hpl.hp.com
Cc: xml-dist-app@w3.org
Message-ID: <OF0CA208AD.A712D0FA-ON85256B53.007D3FF4@lotus.com>
I think that's OK.  Thanks!

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







"Williams, Stuart" <skw@hplb.hpl.hp.com>
02/01/2002 11:28 AM

 
        To:     Noah Mendelsohn/Cambridge/IBM@Lotus
        cc:     xml-dist-app@w3.org
        Subject:        RE: One-way messaging in SOAP 1.2


Hi Noah,

I think I see more clearly where you are coming from. For me you alternate
wording :

> * In the binding framework, state that:  "Binding specifications that
> support more than one MEP MUST specify the means by which the send and
> receiver of a message can agree on the MEP being used.

has some ambiguity in that it is open to an interpretation that bindings 
may
agree use a different MEP from that requested/required by the SOAP node 
that
initiates the message exchange. Given what you've said I don't think that
this is how you intended to be interpreted. The way I see it is that the
initiator of a message exchange request the use of an MEP that a binding 
has
already claimed that it supports.

I agree with the sentiment below:

> Since bindings are allowed to engage in that
> bi-directional "chatter" for a variety of purposes, why not to establish
> the MEP?

The crutial point is that all participant in the exchange become aware of
what MEP is in use. I think it is the 'agree' word that triggered my
response. How about:

* In the binding framework, state that:  "Binding specifications that
support more than one MEP MUST specify the means by which all binding
instances participating in a message exchange become aware of the
MEP being used.

Regards

Stuart

> -----Original Message-----
> From: Noah Mendelsohn [mailto:noah_mendelsohn@us.ibm.com]
> Sent: 01 February 2002 03:37
> To: Williams, Stuart
> Cc: xml-dist-app@w3.org
> Subject: RE: One-way messaging in SOAP 1.2
>
>
> Stuart Williams says:
>
> >> What I dislike about the suggested revision is that it hints at the
choice
> >> of MEP being the subject of a run-time negotiation amongst the
participants
> >> in a message exchange.
>
> I'm not encouraging such runtime negotiation of MEP's, and I would 
expect
> it to be rare, I don't see why it shouldn't be allowed.  I think our
> design already provides for it, and disallowing it would be
> artificial.
>
> I think it's absolutely crucial to realize that, while the envelopes 
will
> flow "downstream" from hop to hop, that the bindings will be sending
> traffic bi-directionally, possibly in fragmented forms etc.  The most
> obvious examples of such traffic are low level acknowledgements, flow
> control window updates, etc.  Since bindings are allowed to engage in 
that

> bi-directional "chatter" for a variety of purposes, why not to establish
> the MEP?   Unusual, but perfectly reasonable if that's how the binding
> happens to be spec'd.
>
> In short, I think that putting an assymetric responsibility on the
> receiver is artificial.  The design is already set to give the 
appropriate

> flexibility in establishing MEPs, and if a binding specification wants 
to
> call for low level "negotiation" at run time, I see no reason to 
prohibit
> that.
>
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>
>
> 
Received on Friday, 1 February 2002 17:51:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:06 GMT