Async without (new) SOAP MEPS: Specifics

This is an attempt to pull together a couple of previous posts and
concisely describe how async patterns might be supported using features
instead of MEPs.  I don't think anything here flies in the face of SOAP
as we know it, but I could very well be wrong on that.
------------------------------------------------------------------------

    * Every binding MUST specify how to deliver a SOAP message to an
      endpoint supporting that binding.
    * Bindings MAY support the "back-channel" feature, which allows the
      receiving endpoint to send a message back to the sender.
          o A binding supporting the "back-channel" feature MAY support
            the "correlation" feature, which allows messages on the
            back-channel to be correlated with the message that produced
            them.

Examples:

    * A pure one-way binding supports only message delivery.
    * The existing HTTP binding supports message delivery, back-channel,
      and correlation
    * One flavor of SMTP binding would support only message delivery
    * Another flavor would support back-channel (requiring
      from/reply-to) and correlation (requiring message-id and in-reply-to)
    * A BEEP binding would (as I recall) support back-channel but not
      correlation.  On the other hand, the first E stands for
      "extensible" so one could always define a BEEP extension.

In the context of WSA:

    * If the binding supports back-channel, you can use anonymous endpoints
    * If the binding supports correlation, you don't need [message id]
      as long as both [reply endpoint] and [fault endpoint] are
      anonymous (though you could use it for other reasons)

This is assuming that "ack" messages can be SOAP messages, as described
previously.  Otherwise we would need an "ack" feature in order to
support full asynchronicity.  If it's not supported, you can still do
async, but [reply endpoint] and [fault endpoint] must either both be
explicit or both be anonymous.

The current HTTP binding would /not/ support "ack", but an HTTP endpoint
could advertise support for "ack" via an extension.