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


From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 1 Feb 2002 18:07:50 -0500
To: skw@hplb.hpl.hp.com
Cc: "'Marc Hadley'" <marc.hadley@sun.com>, XML Protocol Discussion <xml-dist-app@w3.org>
Message-ID: <OF153C2D5D.0308FD46-ON85256B53.007F9D4E@lotus.com>
I don't think it's quite as simple as this thread would indicate.  I think 
that MEP specifications will often be end-to-end.  For example, I want 
request/response to work through SOAP intermediaries!  I expect such a 
specification to call out hop-to-hop responsibilities as appropriate.  For 
example, it could discuss "originator-to-intermediary", 
"intermediary-to-intermediary", etc.  Things like fault delivery, 
responsibility for duplicate detection and suppression in case of retries, 
etc.  must be discussed in this broader context, I think.

I would expect binding specifications to conform to one or more of such 
MEP responsibilities.  Such conformance may or may not reflect the natural 
patterns of the transport, which is why I don't much like the term 
"transport MEP".  For example, I should be able to do a UDP binding that 
participates as, for example, the first hop of a multi-hop SOAP 
request/response.  Request/response is certainly not a "transport" MEP for 
UDP, which is inherently one-way.

Does this make sense?  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>
Sent by: xml-dist-app-request@w3.org
01/30/2002 07:22 AM

        To:     "'Marc Hadley'" <marc.hadley@sun.com>
        cc:     XML Protocol Discussion <xml-dist-app@w3.org>
        Subject:        RE: TBTF: SOAP MEP vs TMEP

Hi Marc,

> I think that maybe we just agreed all along :-)
> Marc.

yep... probably loud agreement ;-)

Received on Friday, 1 February 2002 18:21:38 UTC

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