Request-response and addressing

In a recent message [1] on the WSA list, I argued (against myself :-)
that the "anonymous" address may not always imply a request-response
MEP.  Since this was based in part on SOAP/XMPP, I wanted to carry that
point back over to this list, pose a few specific questions and follow
on with a few more points:

Do we have a definite consensus that the request-response MEP implies
more than just correlation of request and response messages?  In
particular, do we agree that a request-response MEP terminates with
either a response or a failure (implying some reasonable notion of a
timeout), while merely sending a message with a return address and
request id does not guarantee either a response or a failure?

In reference to SOAP/XMPP in particular, is the <message/> binding
really a proper binding of request-response?  It would appear to me that
the receiver could successfully receive the request message and then do
nothing further.  One could build a timeout mechanism on top of this,
but I don't believe one is (or should be) given in the binding supplied.

What I'm driving at here is that "guaranteed response or failure" and
"return address" are separate features of underlying protocols. 
Guaranteed response/failure implies a return address, but not vice
versa.  HTTP and <iq/> provide both.  Email and <message/> provide
return addressing but not guaranteed response/failure.  UDP and at least
some flavors of pub/sub provide neither.

To me, this implies that SOAP/HTTP and SOAP/<iq/> should define the
request-response MEP (as they do), but SOAP/<message/>, SOAP/Email,
SOAP/UDP etc. should not.  Note that this is different from the issue of
whether you can do F&F over HTTP, whether using the request-response MEP
or not.

It also may help sharpen the boundary between the roles of WSA and XMLP
in dealing with the various MEPs.  WSA seems more clearly concerned
with, well, addressing, while semantics such as guarantee of
response/failure (or lack thereof) are more to do with XMLP.

Finally, it's worth reiterating that addressing of responses and
correlation of responses with requests are separate things:

    * HTTP uses the bidirectional TCP connection for return addressing
      and in-order delivery of responses to correlate requests with
      responses.  In WSA-speak, it needs neither response endpoints nor
      [message id] to work (which is why we've gotten by without them :-)
    * BEEP (as I understand it, not yet having looked at SOAP/BEEP) uses
      the bidirectional TCP channel for return addressing, but must use
      an explicit [message id] for correlation, either at the BEEP level
      or via WSA.
    * It's at least logically possible to provide a usable message id at
      the protocol level but without return addressing.
    * Raw UDP provides neither.

[1]
http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0045.html