Supporting WSA with SOAP features and properties

My understanding of SOAP features and properties is that they exist to
abstract, um, features and properties of underlying protocols so that
other functionality can be built on them in a protocol-independent
manner.  In the ongoing efforts to map messaging behavior onto
underlying protocols, we have had basically 1 (one) feature to build on:
the request-response MEP.  (I'm not counting [action] because it's
basically orthogonal to the problem at hand.)

Put that way, it seems as though it could be useful to expand the
toolbox a bit.  Here is a sketch, followed by a note on how to connect
this to WSA and messaging.  In the running NOTEs, I sketch how these
properties might be defined for email, XMPP, HTTP and BEEP.  Each
protocol has its own unique considerations, but each property is
meaningful for at least two protocols.  This suggests (to me at least)
that these are useful abstractions.

    * OPTIONAL Feature: Addressing-related facilities.  This feature
      defines several useful properties of SOAP messages.
          o OPTIONAL Property: [destination address].  This is defined
            when there is a dereferenceable URI available designating
            the destination of the message.   /NOTE:  "Dereferenceable"
            here means basically that one could send another message to
            the same destination without additional context.  For
            example, the to: header of an email, the <to/> element of an
            XMPP message, the URI of an HTTP request.  By contrast, an
            HTTP response message or BEEP message would not have a
            well-defined [destination address].  In those cases the HTTP
            and BEEP connections respectively provide the extra context./
          o OPTIONAL property: [return address]. This is defined when
            there is a dereferenceable URI available by which a message
            can be sent in reply to the message.  /NOTE: For example,
            the reply-to: of an email, or from: if none is present, or
            the from attribute of an XMPP message.  This property is
            undefined for an HTTP request or response, or for a BEEP
            message.  NOTE: The [return address] may or may not be the
            sender of the message being replied to.
            /
          o OPTIONAL property: [message id]. This is defined when there
            is a string available uniquely identifying the message
            within some context defined by the binding./  NOTE: For
            example, the message-id: header of an email or id attribute
            of an XMPP <message/> or an <iq/> with type=get or set. 
            This property would not be defined for an XMPP <iq/> of
            type=result, or an HTTP message, but can be defined for a
            BEEP message.  In the last case, the binding would (IIUC)
            stipulate that [message id] is unique to a given connection./
          o OPTIONAL property: [in reply to].  This is defined when
            there is a string available uniquely identifying a message
            that the message in question is in reply to.  /NOTE:  This
            property will typically be set by application logic on the
            sending (i.e., server) side.  For example, the in-reply-to:
            header in email, the id attribute of an <iq> with
            type=result.  With XMPP <message/>, it appears you would
            need further information to figure out whether id is
            [message id] or [in reply to] (e.g., look for a special
            [action], or look up the id in the set of requests you've
            sent.  In the normal case, you have to do that anyway, but
            in the error case you usually wouldn't).  The property would
            be undefined for HTTP but can be defined for BEEP./
    * OPTIONAL feature: Correlation of response messages.  This feature
      is available if the binding supplies a means by which the receiver
      of a message may determine that it is in response to a particular
      previous message and if so, identify that previous message.  It is
      automatically available via the request-response MEP when the
      binding provides that MEP.  It is also automatically available
      when [return address] and [message id] are available for the
      request and [in reply to] is available for the response.  It may
      also be made available through other binding-specific means. 
      /NOTE e.g., BEEP effectively makes [return address] implicit, but
      supports explicit [message id] and [in reply to]./
    * OPTIONAL feature (maybe): Guarantee of response:  This feature is
      available if a request message is guaranteed to produce,
      unambiguously, an acknowledgment of receipt, a response (whether
      reply or fault) or a failure.  This feature is provided
      automatically by the request-response MEP.  /NOTE: It's not clear
      whether this would ever be available where the request-response
      MEP is not available.  Even if it isn't, it might be worth calling
      out the feature separately.  Or not.  The point here is that not
      every protocol provides this.  HTTP and XMPP <iq/> do, XMPP
      <message/> email and BEEP (IIUC) don't without further machinery./

I believe a formulation like the above considerably clarifies the
semantics of WSA MAPs as bound to SOAP.  In particular:

    * A sender may sensibly use an anonymous response endpoint ([reply
      endpoint] or [fault endpoint]) if the [return address] property is
      available or the request-response MEP is available.
    * An anonymous [destination] makes sense if the binding provides the
      [destination address] property.
    * The [message id] MAP is superfluous (but still REQUIRED) in
      various cases when the SOAP [message id] property is available. 
      (It's also superfluous in other cases, but that's a different
      discussion).

Interestingly, this view of the anonymous address is very close to the
original "the binding will know what to do" definition.  The main
difference is that we have sharpened just /what/ the binding is expected
to provide in what situation (i.e., response or destination).

Knowing whether the features and properties above (and request-response)
are available allows a sender to know what options are meaningfully
available.  For example, if the request-response MEP is available, I can
be sure that a request will produce either a response, a failure or an
acknowledgment.  In other cases, I may not know this, but if correlation
of responses is available, I know that I can at least correlate any
responses that do arrive.  If none of this is available end-to-end, I
know that I will need to build what I want using WSA and some sort of
failure detection.