SOAP MEPs without in-optional out

I'm very much interested in exploring in-optional out, but I don't want 
to lose track of the other approach, namely using one-way messaging as a 
primitive.

Leaving aside any confusion over 202 messages and ACKs, it appears that 
the main driver behind in-optional out is to keep the SOAP description 
in line with what's going on at the next layer down.  At that level, a 
POST/response operation is a single operation, regardless of whether a 
reply comes back or even whether a reply is expected to come back.  We 
capture this POST/possible response as an abstract in-possible out 
operation.

Another possibility is to divorce the SOAP layer from the transport 
layer.  There's already something of a precedent for this in the SOAP 
response MEP, which talks about a SOAP response without regard to where 
the request came from or whether the response is going out on a back 
channel or as a separate one-way message.

In line with this, define a one-way SOAP MEP as a the transmission of a 
single message from a sender to a receiver, independent of any response 
from the receiver.  That is, we do not specify (here) whether the 
receiver sends back a 202, sends back a response message, closes the 
connection, or something else entirely.

Let's look at the basic cases:

    * A fire-and-forget one-way is a SOAP one-way MEP.  Since it's
      fire-and-forget, we don't care what the receiver does next.
    * A classic synchronous request/reply is a SOAP request/reply, but
      we could also view it as two one-way MEPs (or possibly even as a
      one-way MEP and a response MEP).
    * An asynchronous request/reply with both reply and fault pointed
      elsewhere is a SOAP one-way MEP.
    * An asynchronous request/reply with one endpoint pointed away and
      one pointed at the back-channel is a SOAP one-way MEP possibly
      followed by a one-way MEP the other way.  We would have to make it
      clear that a single HTTP operation may carry more than one MEP.

My suspicion is that an approach like this would generalize better to 
carry scenarios like sequences of notification messages, MEPs which may 
produce more than one reply message and so forth.  Allowing one 
transport-level operation to carry more than one MEP might also better 
allow for transport-level connections to persist across multiple MEPs.