[i089] comments on joint proposal

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

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?

 

 

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.

 

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?)

 

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 ?