Action item - Part 2: SOAP request-response, response, request-optional-response ...

The following occurred to me as I was replying to Chris.  It seemed
worth a separate message, particularly as it may relate to signaling
MEPs on the wire.

We seem to be converging on the idea that there are transports which are
inherently request-response in nature.  You can fire, but you can't
forget, or put another way, there will always be a request and there
will always be either a response or a failure. However, one may choose
to put a SOAP envelope on either, neither or both of the request and
response.

The request-response nature of the transport is a static property of the
transport (in this view, XMPP <iq/> and XMPP <message/> are different
transports).  The SOAPiness of the request and response will vary
depending on circumstances.  There are some cases where the SOAPiness
can be known ahead of time:

    * Existing request-response operations, where request and response
      will both always be SOAPy (here and always, insert "barring failure")
    * At least some one-way operations, where we know that the request
      will always be SOAPy but the response will never be SOAPy.
    * GET operations, where the request will never be SOAPy but the
      response always will.

However, as was pointed out early in the process, there are also cases
where we know that the /request/ will be SOAPy, but we don't know
whether the response will be.  This includes at least WSA-aware in-out
and robust in-only MEPs where an anonymous address (which indicates use
of the transport-level response) is supplied but may or may not be
used.  It probably also includes at least some reliability cases like
the one I described, where the application-level flow is one-way and
acks may flow asynchronously over the back-channel.

Currently we call "always SOAPy both ways" "request-response", and
"always only SOAP in the response" "response".  We're more tentatively
calling "always SOAP in the request, maybe SOAP in the response"
"request-optional-response".  While it would appear there are nine
possibilities here, the most we would have to distinguish on the wire is
the SOAPiness of the response.  We can tell by inspection whether there
is SOAP in the request.

The client will either expect SOAP in the response, expect no SOAP, or
not know what to expect.  Should the client be able to signal this
expectation to the server?  This seems only to make sense if the signal
constrains the server's behavior in some way.  If the client doesn't
know what to expect, then the server can do whichever it likes, so
there's no constraint.

If the client /does/ know what to expect, /how/ does it know?  In the
cases I've seen, it knows out-of-band somehow, typically because the
server has advertised something in WSDL or by equivalent means.  E.g.,
if a server advertises a WSA-aware in-out operation, the client either
used all anonymous endpoints and knows there will be a SOAP response, or
didn't and knows that there may or may not be a SOAP response. 
Depending on how the client's SOAP stack is layered, the WSA-aware part
of the client's stack may have to signal a raw SOAP layer, but nothing
has to go out on the wire.

If we can find a case where the client has to dynamically tell the
server "I MUST get a SOAP response" or "I MUST NOT get a SOAP response"
then we will need a wire-level MEP signal.  So far I don't know of any
such case, but I'm not ready to rule it out entirely.

One potential wild card here, though, is SOAP intermediaries.  I'm not
sure quite how to analyze that, partly because I'm not really up on how
intermediaries are used in the real world.  Given that the SOAP
processing model is one-way, I'd think an intermediary /shouldn't/ be
aware that a given SOAP message is a request or a response, but it's
highly possible I've missed something.