Asynchronous bidirectional transports

Suppose I'm using some as-yet-hypothetical bidirectional asynchronous
transport (e.g., SOAP over BEEP, or something else sitting on a raw TCP
connection).  In this situation, unlike HTTP, I'll need to correlate
responses with the messages that produced them.

For example, suppose I send two "ambivalent" requests (i.e., requests
with, say, [reply endpoint] directed elsewhere and [fault endpoint]
anonymous) and the first thing that comes back is an "MEP complete" ack
response.  Which request is that for?  I don't know until the next
response comes back, even if I'm using [message id] for correlation
otherwise.  Note that there are still cases where, for various reasons,
we don't care which message produced the ack.  The problem is that, if
we do care, we have no way of knowing, even if we can tell for non-ack
responses.

The upshot is that, in general, the "MEP complete" response has to be
correlated with the message that produced it.  This isn't an issue with
HTTP since HTTP sends responses in order.  Ideally, the "MEP complete"
response would look something like:

<s:Envelope>
    <s:Header>
       <wsa:Ack/>
       <wsa:Relationship>id of request</wsa:Relationship> <!-- in cases
where [message id] is needed -->
    </s:Header>
    <s:Body/>
</s:Envelope>

Would this break anything?  If not, we can use this format for /all/ ack
messages.  This in turn would mean that the existing HTTP binding would
support async unchanged or, if you prefer, in-optional out will sit
comfortably on top of it.