our favorite - anon replyTo

[Doug Davis <dug@us.ibm.com>]

The anonymous replyTo scenario in the
interop doc says this:
As a consequence, a request must be
resent to allow for the retransmission of its reply even if the request
has already been acknowledged (by another reply received on a different
HTTP connection, for example). 
In one of Stefan's previous notes he
said this (I bolded the key part):
4. Can there be two sockets connected
to the RMD at the same time and both sending the same message?  What's
the response to in each case? 
The number of sockets a client opens
seems irrelevant to the abstract correctness of the protocol. Maybe a better
question is: What if two instances of the same request arrive at the same
time? The rule that MUST be followed is: Neither of the replies should
carry an ack for the request until the RMD/AD decide what the reply should
be. For instance, say request A and request B arrive at the same time,
they both carry a Sequence header with MessageNumber == N. Say A is processed
by the RMD first and delivered to the AD. The AD takes some time to prepare
a reply. Now B is processed. According the rule above the RMD can do one
of three things: a) Send a 202. b) Send an ack that does not include N.
c) Hold the request carrying B until the AD sends the reply, then reply
to both requests (A and B) with that reply and an ack carrying N. This
would seem to be the best approach. 

Unless I'm misreading these, the text
from the interop doc implies that a request can be ACKed even though the
reply hasn't been sent.  The text from Stefan's note implies that
an ACK for a request is never sent until the reply is sent.

What I'm wondering is whether or not
the solution MSFT is proposing allows for a reply to be ACKed w/o the response
having been delivered?  This is an important issue to me because the
text in the interop doc implies that the RMS would need to resend an ACKed
request in order for the response to be delivered.  The notion of
resending an already ACKed message is a bit of a new concept (at least
to me).  The text in Stefan's note seems to imply that that may not
be necessary - it could be interpreted as the RMS will never receive an
ACK for a request w/o the corresponding reply, so it would not need to
resend an ACKed request.  If we did try to support this it would involve
some kind of change to either the RMS or RMD (or both) in how they deal
with ACKs and I'm trying to get an understanding of what kinds of changes
we're talking about.

Did any of that make sense? :-)

thanks
-Doug