Async MEP semantics

This is an attempt to re-analyze questions 5-8 that we had on the board,
concerning how we define the semantics of MEPs which may be realized
asynchronously.  For concreteness, I will use the following running
example, as I believe it's the hardest case; if we can successfully
account for it, we can also account for the more usual cases, but not
necessarily vice versa.

    * The abstract operation is in-out.
    * The request is sent via SOAP/HTTP
    * The [reply endpoint] is an email address (or an address for some
      other one-way transport).
    * The [fault endpoint] is anonymous.

We know how to describe this MEP in the WSDL: its an in-out.  We also
know what's going to happen at the wire level:

    * The client will POST a SOAP request.
    * If there is a fault, the server will send it back as the HTTP
      response.
    * If there is no fault, the server will send back a 202
      acknowledgment and will also send the reply via email.
    * The client can tell what happened by what comes back.

The sticky question has been how to model this at the SOAP MEP level. 
As far as I can tell from the discussion, there are several choices. 
None of these is new.  All but 1.2 (and maybe 1.1, and probably 5) have
received serious discussion at some point.  As usual, any blunders in
describing other peoples' proposals are mine:

   1. We don't model this at the SOAP level.
         1. We don't say anything at all about it.  We talk about the
            WSDL binding, we mention the 202 rule in the context of
            SOAP/HTTP, and that's it.
         2. We mention the issue, and mention that there are several
            possible approaches (see below), possibly include an
            editorial note asking for more input in LC, but don't commit
            to a particular approach.
         3. (DO, as I understand it).  We model the HTTP exchange as an
            instance of a /transport-level/ in-optional-out MEP, and the
            email (if it happens) as a transport-level one-way.
   2. (DH1) We say that each physical /exchange /constitutes a complete
      SOAP MEP.
          * If there is a fault, then the HTTP exchange is an ordinary
            SOAP request-response, with the fault as the response
          * If there is no fault, then the HTTP exchange is still an
            ordinary SOAP request-response, with the 202 modeled as an
            optimized representation of a SOAP message with an [action]
            marking it as an acknowledgment.  The email message is a
            SOAP one-way.
   3. (DH2) We say that each physical /message/ is a one-way SOAP
      message exchange, distinguishing "SOAP/HTTP request" and
      "SOAP/HTTP response" as separate bindings of a SOAP one-way
      message exchange.
          * If there is a fault, then there was a "SOAP/HTTP request"
            message and "SOAP/HTTP response" message.
          * If there was no fault, then there was a "SOAP/HTTP request"
            message and a "SOAP/email" message.  The 202 follows from a
            general rule of "send back 202 if you don't have anything
            else to send back."
   4. (UKA, if I understand it) We say that, in the context of async
      WSA, SOAP/HTTP can mean either what it already means, or it can
      mean send back a 202 and send the actual response some other way. 
      We specifically define what this means if the response is sent
      through a separate SOAP/HTTP interaction, but not for other
      transports (i.e., we don't explicitly describe an email response).
   5. Something else I missed.