Reply-to and in-reply-to are orthogonal

We currently make various statements in the core like "If this property 
is present, the [message id] property is required."  I assume this is 
based on the notion that an explicit reply channel logically implies 
explicit message correlation.  In fact, the two concepts are logically 
independent.


      Neither is needed if:


The underlying transport is HTTP or something similarly oriented toward 
request reply.  The return address is provided by the back-channel.  
Correlation is provided by the synchronous nature of HTTP.


      In-reply-to is needed but reply-to is not if:

The underlying transport is something like BEEP that supports 
bidirectional point-to-point communication.  The return address is 
provided by the back-channel, but correlation is still needed since the 
protocol is asynchronous.


      Reply-to is needed but in-reply-to is not if:

The underlying transport is inherently one-way, but there will only ever 
be one message to the reply address.  This would happen if the reply 
address is generated anew for each request, and the request address is 
not a multicast (as would be the case for normal request/reply).


      Both are needed if:

The underlying transport is inherently one-way, and the reply address 
may be re-used.