Generic req/rep over one-way binding

Has anyone mentioned this yet?  Usually when I get a bright-looking 
idea, it's because I've actually remembered someone else's.  More 
likely, this is what everyone has been talking about concerning 
correlated one-ways, and I'm just now catching on.  Below please read 
"reply-to: and/or fault-to: as the case may be" for "reply-to:"

If I want to do synchronous request/reply, and I have a synchronous 
request/reply transport, I'm happy.  All I have to do is stay out of the 
way by not including a conflicting reply-to.

If I want to do asynchronous request/reply, and I have an asynchronous 
one-way transport, I'm reasonably happy.  I stick in an EPR for my 
callback as reply-to:, generate a message ID, send the request, and 
expect a reply in-reply-to my message on the callback EPR.

If I want to do asynchronous request/reply, and I have a synchronous 
request/reply transport, I'm somewhat happy.  I do the same as the 
above, but I also have to synthesize one-way messages as dummied 
request/replies.  More accurately, I have to synthesize a one-way 
request out of the request/reply I have.  The respondent may very well 
have asynchronous one-way handy (and vice versa for the previous case -- 
depending on my reply-to: EPR, the respondent may have to synthesize a 
one-way reply from request/reply).

If I want to do synchronous request/reply over an asyncrhonous one-way 
transport, the situation looks a bit dodgy.  Everyone knows exactly what 
to do:

    * Establish a possibly ephemeral reply endpoint, or use one we've
      already established for such purposes.
    * Generate a message ID (unless the reply endpoint exists only for
      this MEP).
    * Send the request.
    * Block, awaiting a correlated reply on the reply-endpoint (if the
      reply endpoint only exists for this MEP, then this is trivial,
      otherwise use the MID)
    * Return the reply as the result of the synchronous request/reply

This can be done regardless of the exact nature of the underlying 
transport, so we'd like to do this once and for all.  Just as it would 
be nice to be able to make a small change in a binding to enable asynch 
request/reply, it would be nice to be able to make only a small change 
to offer a request/reply service over an async transport.

The other way to do this would be to define request/reply bindings for 
each async transport separately (e.g., SOAP/SMTP request/reply), and 
there may be value in this.  Perhaps the transport-specific binding can 
be more efficient.  Nonetheless it seems useful to explicitly define the 
pattern above generically as a fallback.  E.g., if I find or invent a 
new one-way transport, I define one-way messaging for it and I'm done if 
I want to be.  I then know that anyone can use the generic req/rep over 
one-way to use my transport for req/rep.  The correlation and reply 
endpoint are handled generically by WSA and SOAP.