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

Christopher B Ferris wrote:

>
> > 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.

Just because this sort of thing seems to bear repeating:  Those are not
my words.  I have also argued against this interpretation.  At least
twice now.

Tony: No offense taken, by the way, particularly since you disclaimed it.

That is all :-)

>
> 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.