one-way over request-response over one-way over ...

It has been pointed out from time to time that one can layer a
request-response MEP over one-way and vice versa.  However, this does
not mean that either one suffices by itself.

At some point, something will have to look at the SOAP envelope with its
MAPs and decide what to do on the wire.  That something will do
different things depending on the features and properties supported by
the underlying protocol in use.

    * If a request message has an anonymous response endpoint:
          o If the protocol supports request-response a la HTTP, the
            server should use the response message.
          o If the protocol supports an explicit return address, a la
            email and XMPP, the server should send to the return
            address.  The client will have to wait for that response and
            distinguish the response from other traffic that may arrive
            at that address.
          o If the protocol supports neither, and there is no outside
            agreement defining anonymous, a la plain UDP, the client
            should refuse to send the request at all.
    * If no direct response is expected because no response endpoints
      are anonymous (including the case where there are no response
      endpoints at all)
          o If the protocol supports request-response, the sender may
            ignore any protocol-level response (beyond noting that the
            protocol-level request arrived safely), or may use it for
            some other purpose.
          o If the protocol doesn't support request-response, we're
            done, noting that ...
          o In both cases the appropriate party -- which may or may not
            be the sender -- will have to listen for any responses and
            distinguish them from other traffic that may arrive at the
            same address.
    * The "split" case of some response endpoints anonymous and some not
      can only occur where anonymous is defined.  If the underlying
      protocol is request-response, then the client may have to
      distinguish an application-level response from another non-empty
      protocol-level response.

Further, there are different guarantees depending on the underlying
protocol:

    * If the underlying protocol supports request-response
          o If a response comes back, I know that a request-response
            operation has completed successfully
          o If a failure occurs, I know that it occurred (though I may
            not know exactly what my counterpart thinks of the situation).
          o If a non-response comes back, I at least know that the
            message I sent arrived.
    * If the underlying protocol supports guaranteed one-way delivery, I
      either know that the request arrived or that a failure occurred
      (and again, the receiver may or may not think the request arrived).
    * If the underlying protocol supports neither, I know nothing more
      than that I tried to send a message and /possibly/ that a failure
      occurred (i.e., I may learn of some failures but I am not
      guaranteed to learn of all).

Notice that these are properties of /protocols/.  The job of /bindings/,
as far as I can tell, is to present those properties in such a way that
the participants in an exchange know what they need to know -- and only
that -- about a protocol.

The existing request-response MEP handles the case of request-response
with anonymous response endpoints over HTTP and the like.  The proposed
request-optionally-SOAPy-response variant extends this to handle the
cases where there may not be an anonymous response.

As I understand it, the proposed
request-optionally-SOAPy-/optional/-response (I may get something back
and it may be SOAP) is intended to cover /all/ of the above cases, but I
don't see how the players will know what to do.  If all I know about a
binding is that this MEP is supported, then how do I know whether or not
anonymous is supported, or whether I can be sure a sent message has
arrived, or whether to listen for responses on the sending address?

It may seem intuitive that binding request-optional-response over a
one-way protocol just means never responding, but given the above that's
clearly not the whole story.  Put another way, I haven't seen any
convincing argument that request-optional-response is appropriate to
one-way protocols.  If it's to be the universal solution, then that case
has to be made.  If it's not, then what, exactly, do we plan to do about
one-way protocols?