"Proposal DH2"

Here is my latest draft of a proposal to re-analyze the existing SOAP
and WSDL MEPs to put WSDL MEPs primary, while maintaining compatibility
with the existing SOAP MEPs.  The division of labor would be:

    * WSDL defines MEPs in terms of one-way exchanges (as we say in
      section 3 of the WSA core)
    * Someone (probably XMLP) defines a dead simple distributed state
      machine for one-way exchanges, with three states and two possible
      transitions on each end (basically Initial, Success and Fail). 
      This appears to be all the information we need.  Slice it finer
      and you get into definitional problems for no real payoff.
    * WSDL MEPs are modeled (ideally in some WSDL spec) as some
      collection of one-way exchanges running concurrently.  E.g.,
      in-out is the "in" running in parallel with exactly one of "out"
      and "fault".  The explicit parallelism captures what
      "sending+receiving" is trying to capture, while the fact that the
      server can't send the reply until it sees the request keeps the
      parallelism reined in.
    * SOAP bindings say how to do a one-way message exchange using a
      specific mechanism.  In particular, there will be separate "SOAP
      over HTTP POST", "SOAP over HTTP GET" and "SOAP over HTTP
      response" bindings.  The first is basically the first half of the
      request-response binding.  The second would consolidate efforts to
      map requests into specially constructed URLs.  The last is
      basically the existing SOAP response binding.
    * Consequently, the SOAP request-response binding is no longer
      strictly needed, though it can be kept as is, since the two ways
      of looking at SOAP request-response are equivalent (details are in
      the attached document).
    * Acks are handled at the binding level.  To successfully receive a
      SOAP over HTTP request message, you have to ensure that something
      is going back in response, whether a SOAP message with code 200,
      whatever we do with faults, or a 202.  We can, and probably
      should, allow for a 202 with a full SOAP message, in case we want
      to attach headers to acks, but an empty 202 will also work fine,
      and need not be interpreted as a SOAP message if we don't want to.

In the attached document, I believe I show that this yields equivalent
results for the existing synchronous cases while also covering the async
cases, including the more exotic ones with cell phones using requests as
replies.  The more I think this all over, the more I believe this
clearly and effectively models what's really going on anyway.  Nor do I
think it does great violence to the existing SOAP structure. 
Essentially, it reinterprets the adjuncts in such a way that SOAP
request-response is no longer primitive, but a composite of simpler
pieces.  It does not (modulo errors on my part) change the wire-level
semantics at all.