[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] [i089] comments on joint proposal
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]