Action Item - Part I: WSRX and MEP signaling on the wire

This is a bit more free-form than I'd originally intended, but bear with
me.  I think we get somewhere.

First, a motivating use case involving reliability.  I believe there are
WSRX members on this list or at least lurking nearby.  If so, please let
me know if I've missed something fundamental.

The reliability standards I've seen distinguish between submit/deliver
and transmit/receive.  Transmitting and receiving are transport-level
concepts and carry no particular guarantee of reliability.  An
acknowledgment message acknowledges not that a message was /received/ at
the transport level, but that it was /delivered/ to its ultimate
recipient.  Just exactly what this means is left out of scope. 
Essentially a message is considered received if the sending side learns
of an acknowledgment for it according to whatever acknowledgment scheme
is in effect.

The upshot here is that, even if I use a TCP-based transport, and even
if that transport allows for status codes or some other indication of a
successful exchange, successful /transmission/ of a message does not
imply successful /delivery/.  Delivery might depend on some further
application-level processing, forwarding to another destination, or
whatever.

To be concrete, suppose I am using WSN or similar to manage sending
notifications to a given node.  I have provided an HTTP endpoint
reference for the consumer of the subscriptions, and I have specified
(using WSN's not-yet-specified policy assertions :-) that these
notifications should be delivered reliably.

Notifications are inherently one-way.  Given HTTP as a transport, we
would want to use the request-optional-response MEP to send
notifications.  I'm not sure if WSRX does (or doesn't) support what I'm
about to describe, but I would expect that the producer (or something
acting on its behalf, but that's a separate issue) send notifications to
the consumer by POSTing SOAP messages to the HTTP address given in the
subscription request.

What comes back?

In the absence of other information, I would expect that each
notification POST should get as its response either a 202 or a SOAP
message containing acknowledgment information for some set of previous
messages.  The 202 would happen if there were no /reliability-level/
acknowledgments available.  Alternatively, the server could send always
back an acknowledgment message.  If there were nothing new to
acknowledge, it would be identical to the previous one.  I don't have a
strong opinion as to which of these is better; my intuition is to allow
for either.

An interesting variant occurs when the producer is sending multiple
streams of notifications to the consumer, in which case a notification
in one stream might elicit an acknowledgment for a notification from a
different stream.  Why not?  The HTTP response channel is available and
might not be available again for arbitrarily long.

Notable points:

    * The transport-level MEP is /always/ request response.
    * The SOAP MEP is /always/ request-optional-response
    * The application-level MEP is /always/ one-way

The potentially complex part here is in the reliability layer.  It sees
two streams of messages: notifications coming out and acknowledgments
coming back.  From this point of view

    * The flow of acknowledgments is independent of the transport-level
      flow (a given HTTP response acknowledges zero or more notifications)
    * The flow of acknowledgments is independent of the
      application-level flow (for the same reason)
    * The flow of notifications ought to be independent of the transport
      level flow.  If nothing else, WSN allows for boxcarring of
      notifications: a given "notify" SOAP message may contain several
      notifications (but does the reliability layer know this?).
    * Further, since the reliability layer may retransmit, so a given
      application-level notification may trigger more than one
      transport-level message.

The recurring theme I'm seeing here is that each level has its own view
of message flow.  Often, those views will converge, but they can diverge
for any number of perfectly ordinary reasons, even leaving aside cases
involving cell phones and tunnels:

    * A request-response operation may be realized as more than one
      transport-level exchange (the WSA "async request-response" case)
    * A one-way operation may be realized as a request-response, either
      as a push operation or through polling.
    * Retransmission means that one application-level operation may
      manifest as several transport-level operations, even where the
      application-level operation would otherwise match the transport level.
    * Boxcarring, where applicable, means that several application-level
      operations may manifest as a single transport-level operation. 
      Reliability-level acknowledgments boxcar by design.

This may seem complex, but there is a bright side.  The various concerns
/have to be/ separated, so we might as well gain from this separation. 
In particular, SOAP can focus narrowly on abstracting the
characteristics of the transport and not worry about anything else.  I'm
more and more convinced that we're about done /as far as HTTP is concerned/:

    * The SOAP request-(optional-)response MEP describes a SOAP message
      going out and something SOAPy optionally coming back.
    * The SOAP response MEP describes a non-SOAP request and something
      SOAPy coming back.
    * Um, how do we describe a SOAP request and something non-SOAPy
      coming back?
    * We shouldn't have to worry about non-SOAP out and non-SOAP back,
      right?