Two transport issues

These two issues came up while I was pondering the "life without SOAP
MEPs" approach a bit more deeply.  Other than that, they're only loosely
connected.


      1. Asynchronous batching

I can think of a couple of plausible cases where one physical message
might carry several SOAP messages.  For example, a cell-phone "server"
might poll its "client" and get back a batch of several requests.  It
might also piggyback any number of responses onto a poll.  In short,
each polling operation transfers zero or more messages from "server" to
"client", then zero or more messages from "client" to "server". 
Similarly, email-based transports may batch several messages into one email.

Note that in either case, the batched messages need not be for the same
logical endpoint.  If the cell phone supports several operations, for
example, there's no reason that the response to the poll wouldn't
contain requests for several different operations.  For that matter, the
messages need not all be requests.  Some could be, e.g., responses to
actual request messages the cell phone sent out.

Given that the reversed scenario is valid, this sort of batching seems
too useful to ignore, and argues strongly for describing MEPs in terms
of single message exchanges, as opposed to trying to map them tightly to
transport-level operations.


      2. Reliable messaging acks

>From an application-level point of view, it would be good to be able to
see a reliable messaging sequence as just another transport, albeit one
with certain QoS guarantees.  In particular, it would be nice to be able
to piggyback a response and acknowledgments used by the reliability layer.

This seems fairly closely analogous to the issue of sending an ack for a
SOAP/HTTP request.  For example, if one response endpoint is anonymous
and the other is a third party, then it should at least be possible to
have any of the following happen:

    * Client sends request, server sends back reply along with ack for
      request.
    * Client sends request, server sends back ack and reply separately
      (not an option in the analogous SOAP/HTTP case).
    * Client sends request, server sends back ack, server sends fault to
      third party.

This makes me think that maybe the way to look at SOAP/HTTP is in terms
of piggybacking a response onto an ack that's always there, rather than
treating the ack as a special kind of response that's only there in some
cases.