How many MEPs?

For a while I've been arguing for a three-MEP model, partly from these
assumptions:

   1. The receiver of a message needs some way to know whether the
      sender definitely does, definitely does not, or may or may not
      expect a reply
   2. This indication should be done independently of WSA headers, e.g.,
      by supplying a "which SOAP MEP is this" property explicitly.

I'm starting to think, however, that these assumptions are not valid. 
Even if they are, defining a new MEP is only one way to indicate what
the server wants.  Adding a parameter to the existing request-response
MEP is also an option, and a separate "reply expectation" feature might
also work.  Right now, though, I'd like to try to articulate why I'm no
longer sure that such an indication is necessary.  In terms of our
decision tree, the conclusion is that at most one new MEP(pure one-way)
is required, /and /that we don't need a parameter indicating what the
client expects.  I believe this is distinct from the existing choices. 
We would, however, need to tweak the notion of a response message to
include a contentless marker indicating that the MEP is complete with no
response payload.  Note that such a marker is needed, at some level, in
any case.

The three main cases we've been looking at are:

   1. A simple fire-and-forget one-way, realizing a WSDL in-only MEP,
      some other WSDL MEP with no anonymous endpoints, or some other
      pattern not described by standard WSDL.
   2. The existing synchronous realization of WSDL in-out, in which the
      reply and fault endpoints are both anonymous, or other cases in
      which all relevant endpoints are anonymous (e.g., robust in-only
      with anonymous [fault endpoint] or some non-WSDL interaction).
   3. The ambivalent case in which one of reply/fault is anonymous and
      the other isn't, or in general the anonymous address may or may
      not carry a message payload.

These essentially break down to the much-discussed three-way switch of

   1. Anonymous channel definitely will not be needed for an application
      level payload.
   2. Anonymous channel definitely will be needed for an application
      level payload.
   3. Anonymous channel might or might not be needed for an application
      level payload.

which clearly covers all the possibilities.

Case 1 maps cleanly to the as-yet-undefined one-way MEP.  It could also
be considered as the first half of a request/response or, equivalently,
as a special case of case 2.

Case 2 maps to the existing request-response, by definition.

What about case 3?  At first blush, it's hard to tell what it maps
into.  For the sake of concreteness, let's say the [reply endpoint] is
some third party and the [fault endpoint] is anonymous.  If I send a
request, and the response is a normal reply, then this looks like two
separate one-way MEPs.  On the other hand, if a fault comes back, it
looks like one request-response MEP.  It's not so troubling that the
reply in the first scenario causes a second MEP to take place.  That
sort of thing might happen for any number of reasons.  The troubling bit
is that we don't seem to know what MEP the /first/ message was part of,
until we either get back a fault or some sort of marker that says the
reply went elsewhere.

But note that /something/ always has to come back.  Unlike the pure
fire-and-forget case, where we don't care, the client /must/ look at
what came back from the server in order to know what happened (and in
particular, whether to continue to wait for a reply).

This suggests that the client in case 3 is participating in a
request-response MEP /in both scenarios.  /The difference is not the
MEP, but the response that comes back, which may be either a fault or a
"no fault occurred but we're done now" marker.  In effect, the three-way
switch above collapses to a simple binary choice:

   1. The anonymous channel definitely will not be needed for a response
      (whether application-level or marker).
   2. The anonymous channel definitely will be needed for a response
      (whether application-level or marker).

>From this point of view, the sender never has any strong need to
indicate whether it expects a reply.

   1. In fire-and-forget, the sender won't be listening for a reply
      anyway (that's the "forget" part).  For its part, the receiver
      knows it's not going to send a reply (either because it advertised
      in-only, or because it looked at the message headers, or both). 
      It may well be useful for the sender to indicate more explicitly
      that it won't listen to whatever comes back, but it's not essential.
   2. In the existing request-response, the receiver is always going to
      send back a response no matter what.  It doesn't matter what the
      client expects.
   3. In the ambivalent case, the receiver is always going to send back
      a response as well.  The only wrinkles are that it might /also/
      send on a separate reply (or fault, as the case may be), and that
      the response that comes back might be a marker.

At most, the sender needs to indicate that it will definitely ignore any
response.  This might allow the receiver to close the channel more
quickly.  In no case does the client indicate that it might or might not
need a response.

Unfortunately, while the existing request-response SOAP MEP is fairly
loosely defined, it does stipulate that the response message is a SOAP
message, and it's not completely clear whether the "we're done now"
marker could be meaningfully cast as a SOAP message.  In other words,
it's not clear whether this approach can be defined merely by "squinting
at" the existing SOAP MEPs.  Again, the marker is needed no matter what
approach we take, but if we're defining whole new MEPs, we have more
latitude in how we handle it.