What 3.1.3 is trying to capture

Here's a brief outline of what I think we're trying to capture in
3.1.3.  This is mainly for background; I'll also be making specific
changes in the text.  I'm deliberately saying "look like" instead of
"MUST conform to".  We'll need to formalize this a bit, but I don't see
how we can say MUST until we know what the MUST applies to.

    * If the anonymous endpoint is used, the whole operation is going to
      look like the existing SOAP request-response MEP.  It may look
      like this because we model it as such (per the current proposed
      text), or because we model it as an instance of in-optional-out,
      which in turn looks like request-response when there's an "out",
      or for some other reason.

    * If the anonymous endpoint is not used, the inbound message of the
      operation looks like one MEP instance, whether some sort of
      one-way or as an in-optional-out without an out, or for some other
      reason.  The outbound message, if any, will look like a separate
      MEP instance, whether because we model it as some sort of one-way,
      or as an in-optional-out that we know in advance will have no out,
      or something else.

In short: anonymous means "inbound and outbound together belong to one
MEP that acts like the existing request-response", no anonymous means
"inbound and outbound (if any) belong to separate MEPs that act like
one-way".

There are other cases, like mU fault and WS-RX-ish acks, that need to
fit in here, whether as "using anonymous" or as something else.

Personally, using an in-optional-out in cases where we know in advance
there will be no "out" seems like calling a slice of cheese "a cheese
sandwich with no bread", but maybe that's just me.