Another possible decision for the tree

>From recent pondering, there appear (to me) to be three different ways
to handle fire-and-forget one-way:

   1. Define a "SOAP request" MEP, analogous to "SOAP reply", with the
      semantic that such a MEP is just the first part of the "SOAP
      request-response" MEP, with behavior after delivery of the
      "request" unspecified.  This reflects the idea that the sender
      doesn't care what happens after it sends the message, and allows
      the receiver to do whatever it likes, even close the connection. 
      The term "request" would be a bit of a misnomer, given that a
      response will not always be expected.
   2. Define a SOAP one-way MEP with the semantic that, if there is a
      back-channel, the receiver MUST send some sort of empty "marker"
      message
   3. Try to define SOAP one-way in terms of SOAP request-response. 
      This would work for HTTP with a marker message, but I don't see
      how it would work with a pure one-way binding.  Perhaps define
      such a binding as always producing some sort of synthetic marker
      response, but this seems backwards.

Right now, I'm split between (1) and (2).  Option 1 has a certain
symmetry to it, but I'm not sure whether the lack of constraint is a bug
or a feature.  If it's a bug, then option 2 is good.