W3C home > Mailing lists > Public > public-ws-addressing@w3.org > December 2005

What 3.1.3 is trying to capture

From: David Hull <dmh@tibco.com>
Date: Tue, 13 Dec 2005 12:07:08 -0500
To: "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
Message-id: <439EFFBC.6060809@tibco.com>
Here's a brief outline of what I think we're trying to capture in
3.1.3.  This is mainly for background; I'll also be making specific
changes in the text.  I'm deliberately saying "look like" instead of
"MUST conform to".  We'll need to formalize this a bit, but I don't see
how we can say MUST until we know what the MUST applies to.

    * If the anonymous endpoint is used, the whole operation is going to
      look like the existing SOAP request-response MEP.  It may look
      like this because we model it as such (per the current proposed
      text), or because we model it as an instance of in-optional-out,
      which in turn looks like request-response when there's an "out",
      or for some other reason.

    * If the anonymous endpoint is not used, the inbound message of the
      operation looks like one MEP instance, whether some sort of
      one-way or as an in-optional-out without an out, or for some other
      reason.  The outbound message, if any, will look like a separate
      MEP instance, whether because we model it as some sort of one-way,
      or as an in-optional-out that we know in advance will have no out,
      or something else.

In short: anonymous means "inbound and outbound together belong to one
MEP that acts like the existing request-response", no anonymous means
"inbound and outbound (if any) belong to separate MEPs that act like

There are other cases, like mU fault and WS-RX-ish acks, that need to
fit in here, whether as "using anonymous" or as something else.

Personally, using an in-optional-out in cases where we know in advance
there will be no "out" seems like calling a slice of cheese "a cheese
sandwich with no bread", but maybe that's just me.
Received on Tuesday, 13 December 2005 17:07:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:12 UTC