(possible) WS-RX use cases

In the case of WS-RX acks coming back in the HTTP response with any
application-level response going elsewhere, just which cases are we
considering?  I can think of at least two:

   1. WS-RX ack of the HTTP request

        * I send you a message.
        * You send me back a WS-RX ack of that message with a 202.  You
          might also send some other message somewhere, but I don't
          think that's relevant here.

   2. General WS-RX ack, for example

        * I send you a message.
        * You don't ack it immediately, but instead just send an empty 202.
        * I send you another message
        * You send me WS-RX acks for both messages.

Case 1 seems almost pointless.  If all I need to know is that you got
the message, any HTTP response will do.

Case 2 seems much more useful.  In this case the HTTP response (whatever
it is) means you got the message, while the WS-RX ack means something
else, e.g., you were able to forward it on and it reached its final
destination.

>From a SOAP MEP point of view I don't see much difference between 1 and
2 (except that 1 always expects a non-empty 202).  Case 2 can be viewed
as abuse of HTTP, particularly since 202 seems to be aimed at conveying
status of the particular HTTP response.  On the other hand, one can
argue that the sender is legitimately POSTing messages to be delivered
and the receiver is legitimately responding with status information.  It
really depends on how you view the flow, which is why I tend to fall
back to whether the wire-level behavior works.

Actually, there's an interesting third option, a variant of the second. 
Here's one possible example:

    * I send you a message
    * You send back an empty 202.
    * I send you a request message
    * You send back a response, with a 200.  That message also happens
      to contain a WS-RX header with an ack for my first message.

My personal feeling (at the moment) is that case 2 is not quite right,
because of the semantics defined for 202, but /would/ be alright (and in
line with case 3) if the acks had a 200 status.  This takes the view
that the acks are a SOAP-level response just like any other.  Whatever's
receiving and dispatching the response has to take this into account: It
might get back a 200 response that doesn't filter up to the
application.  Put another way, the various WS* headers may not all be
visible to the application, and given this, it's possible that there's
nothing left after they've been filtered out.

The key question here in any case is, does the receiver of a message
know enough to handle it appropriately?  I'm particularly concerned
about non-empty 202 messages in this respect, and I'd like to see a bit
more detail about how they would be dispatched.