[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] [i089] comments on joint proposal (resending)
Resending this as it did not seem to make
it to the reflector over last hour… -J From: Doug: From: Doug Davis
[mailto:dug@us.ibm.com]
> How is this correlation done? Is wsa:RelatesTo relied upon? In any
Well… I think it is worth saying,
because that’s not the only way to do this correlation: e.g. the CSR
could just contain (ReplyTo) the same uuid-based anon URI as the MakeConnection
that fetched the CS. SO either that, or RelatesTo would need be set by
the sender of CSR. But using RelatesTo assumes that the CS was sent with a
wsa:MessageId in the first place. So it looks like a bit of coordination
is needed to achieve this correlation one way or the other. … > From an editorial viewpoint, it is better to extract the anon URI How about renaming 3.7 “ Managing
[or coping with] non-addressable endpoints” ?
OK, let me rephrase where I see a
potential issue with this use case: - “in” message was a
resend, i.e. over an HTTP request initiated by the RMS client. - “out” message (not using RM)
is sent over back-channel. - but this back-channel cannot be expected
to help transfer this “out” all the way back beyond the RMS client
to the endpoint that originated the “in”, as it would in
normal cases. - And the RM component on client side
cannot help doing the forwarding as the out is not using RM. - so the sender of the
“out” message must add enough endpoint destination info, which it
must get from somewhere. It can’t get it from a wsa:ReplyTo which is anon
in the “in”. Unless this ReplyTo is a uuid-based anon URI like in
MakeConnection? If yes that needs be understood outside RM… Regards, Jacques |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]