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

Rogers, Tony wrote:

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

Exactly.  That's why I wanted to make an explicit distinction:

   1. Define a term for "the response message", i.e., HTTP response for
      SOAP 1.1/HTTP, response message of SOAP 1.2 request-response
      message exchange.
   2. Define anonymous response endpoint (of request) and [destination]
      (of reply) as meaning this.
   3. The definition is also available for other use, if appropriate.

I definitely do /not/ want to say "anonymous in a request message means
the response message" as a blanket statement.  As I said before [1], the
MS example shows that we can't even generalize that far.

[1]
http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0146.html

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