Charter question

We are chartered to define, among other things, "The use of these
abstract message properties in the context of all WSDL 1.1 or WSDL 2.0
Message Exchange Patterns, including the asynchronous use of these MEPs.
In particular, the relationship between message properties and WSDL 1.1
and WSDL 2.0 service descriptions will be provided if applicable."

In particular, this presumably includes the meaning of the response
endpoints ([reply endpoint] and [fault endpoint]) in the context of
in-out and robust in-only, including cases where the [address] of the
endpoint used is not anonymous.  Thus the lengthy discussion in the
async TF, now XMLP and elsewhere.

What I want to probe at here is, how much are we /obligated/ to say
about this case?  Even when HTTP is the only game in town, many things
can reasonably happen in response to an inbound message (not all of
which are presently blessed by standards):

    * The server sends back an application-level SOAP response as the
      HTTP response (if the response endpoint is anonymous)
    * The server sends back an application-level non-SOAP HTTP response
      (e.g., a binary object).  Presumably the response endpoint would
      have to be anonymous.
    * The server sends back a SOAP mustUnderstand fault as the HTTP response
    * The server sends back an empty acknowledgment and initiates a
      separate HTTP connection to deliver the response (if there is one).
    * The server sends back a non-empty SOAP acknowledgment (perhaps
      containing WS-RX acks for entirely different messages).
    * The server sends back a 3xx and expects the client to poll further
      (I believe this would happen with an anonymous response endpoint. 
      The SOAP 1.2 HTTP binding allows for a 3xx response, but I'm not
      sure whether it's the same thing I've seen proposed in our
      discussions).
    * The server sends back an application-level request message (e.g.,
      the WSDL MEP was in-only, the client is a cell phone and we're
      reversing the connection -- assuming this is to be considered
      "tunneling" and not "abuse of HTTP").
    * The server holds on to the request and waits for the client to
      poll for it in some manner.
    * Various combinations of the above are also possible.  E.g., send
      back some acks in a SOAP envelope and hold the response for polling.

It's pretty clear to me that this cannot be an exhaustive list and that
much of it is well beyond our scope.

I believe that what we /can/ say is that anonymous is intended to mean
"use a single connection for the inbound and outbound messages,"  a
"connection" here being a single SOAP 1.1/HTTP connection or a single
instance of the SOAP 1.2 request-response MEP, depending on which
version of SOAP we're using.  I will venture to say, but not quite as
confidently, that a non-anonymous response address is intended to mean
"if an outbound message is to be sent, it must (should?) not be sent as
part of the same connection as the inbound message," with "connection"
defined as before.

This doesn't preclude /other/ SOAP-y stuff coming back on the original
connection, just the outbound message.  Nor does it preclude a non-SOAP
reply in the anonymous case; the outbound message might not be SOAP.

We also have to account for faults that occur before the WSA headers are
understood (i.e. mustUnderstand faults and whatever else).  Clearly,
those have to use the original connection.  We can say it that way, or
say that they must use the anonymous address.  Given that they can occur
before we're in WSA-land at all, it's probably best to talk about
connections as opposed to the anonymous address.

I don't think we can or should say much more than this, but if we do, we
should do it my favorite way :-).