RE: Why anonymous may be different (for AcksTo and elsewhere)

> This is why I'm unhappy with DaveH's words (misquoted/paraphrased): 
> "anonymous in a request message means the response message" - that's
> only true of the anonymous wsa:replyTo / wsa:faultTo in this context.

Actually, this is a really important point. I think that it addresses my 
argument that the
semantic applies to the MAP and not to the URI itself. IMO, the semantic 
of the URI
itself means "the connection for this context" where the context is 
defined by the semantic
of the MAP as it relates to the binding and/or MEP.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

public-ws-addressing-request@w3.org wrote on 02/21/2006 02:34:43 AM:

> While we're talking about anonymous, I'd like to re-iterate one 
> thing that was brought to my mind by Jonathan's example of a 
> putative TCP/IP binding. 
> 
> In this not-exactly-hypothetical binding, a request message can 
> legitimately be given an anonymous wsa:to, AND an anonymous wsa:
> replyTo. This is kinda interesting. It could be argued that both 
> anonymous values mean the same thing: "send the message to the other
> end of the established TCP/IP connection", but the recipients are 
> different. If A is sending a request to B, then the anon wsa:to 
> means B, but the anon wsa:replyTo means A.
> 
> This is why I'm unhappy with DaveH's words (misquoted/paraphrased): 
> "anonymous in a request message means the response message" - that's
> only true of the anonymous wsa:replyTo / wsa:faultTo in this context.
> 
> We really must insist that the meaning of the anonymous URI depends 
> upon the binding.
> 
> Tony Rogers
> 
> From: public-ws-addressing-request@w3.org on behalf of David Hull
> Sent: Tue 21-Feb-06 18:15
> To: public-ws-addressing@w3.org
> Subject: Why anonymous may be different (for AcksTo and elsewhere)

> The more I ponder the problem of anonymous AcksTo, the more I think 
> that anonymous can't quite be treated as just another EPR address. 
> I'm posting this here because I think the situation is not unique to
> AcksTo or WS-RX.  Rather, WS-RX happens to have presented the use 
> case that flushes the issue out.  Also, while I may have got the WS-
> RX use case wrong here, I believe the overall point is still of 
> interest to WSA.  Finally, there are clearly enough WS-RX folks in 
> the audience here that if this is in fact relevant to WS-RX, I'm 
> sure the news will find its way there.
> 
> Here's the scenario:
> 
> Suppose that A and B both want to use a reliable sequence to send 
> messages to C.  Each uses its own sequence.  As I understand it, 
> this is the normal case (as opposed to, say, A and B sharing the 
> same sequence).  Now further suppose that A and B both use anonymous
> for AcksTo.  Given that acks for a given message could come back 
> with a later message, the following could happen:
> A sends C message A1 
> C sends back a response with no acks
> B sends C message B1 
> C sends back a response with an ack to message A1 
> For that matter, if C isn't careful, it could send acks to some 
> completely unrelated process that happened to be sending to it 
> without even using WS-RX.
> 
> So, in order for this to work, C has to be careful only to use 
> anonymous AcksTo for replies to request messages that are part of 
> the same sequence (by the way, how does C ack the last message of 
> such a sequence if it doesn't know it's the last?).
> 
> By contrast, it doesn't seem C would have to be so careful in the 
> case where the AcksTo EPRs are not anonymous.  Normally (and again 
> I'm not a WS-RXpert) I would expect that A and B would use separate 
> AcksTo addresses, and C would just send acks to the addresses it was
> told to use.  Even if A and B used the same AcksTo address and used 
> the sequence number on the acks to sort out whose acks they were, 
> they could do so without any help from C because the acks would at 
> least always end up at the same destination.
> 
> Another way to look at this is that using the same AcksTo for two 
> different sequences ties the two sequences together and whoever's 
> getting the acks has to know about both sequences.  This would apply
> equally to anonymous and non-anonymous.  I believe this handles most
> of the problem, but not all.  First, this would require every sender
> that wants to use anonymous AcksTo with a given destination to know 
> about every other one.  Second, by itself it doesn't deal with 
> senders that aren't even using WS-RX.  I'm not sure the second 
> problem is serious, but the first one seems like it might be.
> 
> It also seems worth considering the case where A uses anonymous and 
> B doesn't.  If B is expecting acks at non-anonymous D, then it 
> wouldn't normally be checking for acks in its responses, and neither
> could it be expected to know what to do with A's acks if it did 
> notice them.  C can send B's acks freely to D, but it has to be 
> careful to send A's acks back only on responses to messages from A.
> 
> Even if there turn out to be no serious issues here for WS-RX, it 
> seems worth noting that trying to extend anonymous beyond the 
> context of a single request-response message exchange effectively 
> ties together all senders to a given destination into one virtual 
> receiver for messages to anonymous.  That is, a message sent to 
> anonymous in such a scenario could arrive back at any sender.