Revised proposal

Here is the re-work of the proposal I sent, as per yesterday's telecon. 
The main changes are:

    * I've added a non-normative overview, and non-normative set of
      rules for senders and receivers (non-normative in the sense that
      they're implied by the normative material, but if I screwed up
      somewhere the normative material takes precedence).
    * I've removed any reference to the the "anonymous response channel"
      feature.  Instead, this describes how to build any of the three
      MEPs on top of SOAP request-response.  There is one MUST to the
      effect that if request-response is available it MUST be used, but
      this could be softened by defining some sort of marker to indicate
      whether or not it is to be used.

I believe this addresses, attempts to clarify or obsoletes at least some
of the questions that have been raised in the last day or so.  So if
you've brought up a question recently that I haven't answered, don't
worry.  I haven't forgotten you, but it may make more sense to re-ask
any questions that still remain open after this go-round.

However ...

    * Umit/Anish: There will only ever be one response coming back in
      the request-response MEP.  It may be a reply, fault or
      acknowledgment, but it will always be exactly one of those.
    * Umit: The binding as a whole applies to the operation as a whole. 
      For example, if the binding has SOAP/HTTP as its @transport
      attribute and SOAP/Email as a response binding, and I give an
      email [reply endpoint] and [fault endpoint], everything is still
      covered.  We end up with
          o A SOAP/HTTP request for the /in/ message
          o A SOAP/HTTP acknowledgment.
          o An email as the /out /message.
    * what saves this from infinite regress is that the /out/ message is
      always one-way and doesn't require any binding other than the
      response binding.
    * Marc: Much if not of this proposal will work verbatim if
      "acknowledgment message" in what is now 2.1 is defined in a
      transport-specific way instead of as a SOAP message.  I'm still
      not sure this is a good idea, but at least most of the other work
      is reusable.