One question and one comment
(for now) inline below. – Marc g
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Thursday, June 08, 2006 5:14 AM
To: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] [i089] comments on joint proposal
"Durand, Jacques R." <JDurand@us.fujitsu.com>
wrote on 06/08/2006 04:01:48 AM:
> Some feedback – sorry for not sending this earlier.
> These should be interpreted as mere requests for clarification in
> case I missed something…;-)
>
> -Jacques
>
> 1- The CS can be carried on the back-channel of a wsrm:
> MakeConnection, and the CSR on a separate request (in same direction
> as wsrm:MakeConnection). So it is crucial that both are correlated
> independently from the underlying protocol. This correlation is
> needed because of the need to correlate an accept with an offer, and
> also because the RMS must be able to associate the new seq ID (in
> CSR) with the address intended by the CS (which is aligned with the
> address in wsrm:MakeConnection.)
> How is this correlation done? Is wsa:RelatesTo relied upon? In any
> case shouldn't this
> be specified in wsrm as how it is done is critical for
interoperability?
Yes the correlation would be done using wsa:RelatesTo. Not sure we
need to explicitly say this because this would actually be true of
any request/response exchange, not just the CS. Just seems like
general knowledge these days, no?
MG: How does an implementation know whom to direct the response
if the RelatesTo is for the MakeConnection and not the original (potentially
blocked) request? Or does this mechanism require that there can only be a
single request/response at a time in a sequence?
> 2- in an in-out exchange with (rel in / rel out), and anonymous
> ReplyTo for the request (in), and in case the in message fails and
> is resent by the RMS-client, then the sender of the out message (the
> RMS-server) must provide enough endpoint info to get the message
> delivered to the endpoint (behind RMD-client) as the back-channel is
> not enough (would stop at the RMD-client, at least in
> implementations I am aware of).
> Apparently the same anon URI template as used in MakeConnection need
> be used in the ReplyTo for the request. If that is the case, that
> would deserve to be mentioned.
> From an editorial viewpoint, it is better to extract the anon URI
> template description from section 3.7 so that it is clear its use is
> not restricted to MakeConnection.
Yes I agree that the URI template is meant to be used in more places
than just the MakeConnection element - otherwise no messages would be
targetted to it :-) but wsa:ReplyTo isn't the only place, its
just
probably the most common. I'd be ok with suggested modifications to
the text to make that clear but I thought it was by not specifically
limiting it to wsa:ReplyTo. As for its location - doesn't it seem
like
keeping it with the MakeConnection text is best since those two go
hand-in-hand?
MG: Yes.
> 3- Now with an in-out exchange with (rel in / non-rel out), the out
> message is not mediated by any RMD-client. How would this out
> message be delivered to its endpoint, in case the "in"
message was
> resent by RMS-client? It probably should contain explicit endpoint
> info (wsa:To?) but then how does the server know when to add this,
> while it would not have to if the in message originated from the
> sending endpoint vs. the RMS-client?
> Are we saying that the anon URI template should be understood
> outside RM components? (doesn't that fall under wsa scope, and
> beyond wsrm scope?)
Not sure I followed this but let me try...
In the rel-in/non-rel-out case, if the RMS-client resends the
rel-in message then I would suspect that all but one of those
attempts would get back a 202 since all but one are dups.
In the one non-202 case if the replyTo was anon then it would
carry the response.
> 4- If MakeConnection supports both a seq ID and an Address argts,
> then I assume both need be supported by any implementation, for
> interoperability. SO it looks like this is where the two previous
> proposals merged here.
> As much as I had sympathy for the ID-based proposal, it appears that
> the Address alone is sufficient here (even in case of offered
> sequence) so I am questioning the need for both here...
> that makes the implementation more complex than with any of the two
> previous proposals. In particular, what is the use case for using
> both seq ID and endpoint Addr under a MakeConnection call ?
Obviously, in general, I agree that the Address alone is sufficient
but since I'm not sure Paul will have a chance to answer this before
the call let me try to read his mind...
There are a couple of use-cases that the ID-based approach is designed
for: first, and possibly the most important, is the case where the
outgoing message can not be modified to use the URI template instead
of anonymous - perhaps wsa:ReplyTo is already signed. In these cases
the RMD-client only has the RM SeqID at its disposal for correlation.
This, however, does place certain restrictions on how RM can be used.
For example, it (usually) limits you to one endpoint per RM sequence
and if the Sequence is closed down prematurely, you're stuck - the
RMS-server will not be allowed to create a new one to continue.
The other cases I've heard for using the ID in the MakeConnection
(with and w/o the Address) is simply for a more focused retrieval.
Its possible that the RMD-client is only interested in messages
related to just one (out of possibly many) active sequences so this
provides a mechanism to allow that focused/specialized retrieval.
thanks
-Doug