More on identity

(Been having trouble organizing my thoughts on this note, so forgive me if 
its even more disjoint than normal :-), but I wanted to get the ideas out 
there)

Following on to my previous note [1] on how the RManonURI is for identity, 
just like addressable URIs, I wanted to bring up a couple of additional 
scenarios/issues that I hope will help people's understanding of where 
we're coming from on this.

First, and this relates to Marc's suggested use of the wsa:RelatesTo 
header.  Implicit in his proposal is the notion that all messages being 
sent to the RManonURI are related to some previous message.  This would be 
akin to requiring all messages to http://www.cnn.com to be related to some 
previous message - which obviously isn't always true.  Let's look at a 
specific example:  take the case of a pub/sub system, where I wish to 
receive notifications on Baseball, so I subscribe specifying the 
appropriate info to get Baseball scores, and I pass in an RManonURI in the 
notification EPR.  Under Marc's proposal, I think, all notifications would 
have a wsa:RelatesTo that pointed back to the subscribe request message. 
Now, there are several problems with this... what if I ("I" being the 
person sending the MakeConnection), wasn't actually the one who sent the 
Subscribe() ?  What if someone else subscribed on my behalf? This is a 
common usage pattern.  I don't have, nor should I have, the messageID of 
the Subscribe. The only thing I know is "my" identity.  This is similar to 
the case I've mentioned before where the messages being sent are new 
one-ways - where the EPR used by the client was obtained through some 
non-request/response MEP.  I like to think of this as the case of someone 
handing the client a piece of paper with an EPR on it and says "send 
message here".  This works perfectly well in the async case and we're 
trying to make sure it works in the sync case too (with the difference 
being at the transport layer).

Another variant, a little related to the grouping thought I mentioned in 
[1], is that the endpoint sending the MakeConnection isn't asking for a 
particular message, or messages related to some previous message, its 
asking for messages destined to a particular endpoint.  This is 
conceptually similar to an endpoint having a port available for anyone to 
try to connect to it.  Clearly, once the endpoint started to processing 
the bytes from the wire it would need to filter-out and route the messages 
appropriately, but in general  having a port on the internet means anyone 
can attempt to talk to it.  MakeConnection attempts to simulate this 
behavior by asking for _any_ message targeted to RManonURI of interest - 
this means that the receiver of the MakeConnection is free to attempt to 
send any message it believes is appropriate for that endpoint.  Which is 
exactly what it would be free to do in the async case.  In both cases it 
can attempt to send any message it wants - whether the other side accepts 
it is a totally different issue - but it can be dealt with the same way. 

Let's look at what this means by expanding the pub/sub scenario.  Let's 
say one day I decided that I'm not only interested in Baseball but also 
interested in Football - so I subscribe again specifying Football.  I now 
have two subscriptions with this pub/sub engine.  However, what if I used 
the same RManonURI in both subscribes?  No reason not to - I'm the same 
endpoint.  When the MakeConnection is sent to the pub/sub engine its 
asking for _any_ message targeted to the RManon EPR - this means that its 
possible for the pub/sub engine to return a notification message from 
either subscription.  Clearly an optimization but its shows how we're 
trying to simulate the async world and, hopefully, reinforcing the idea 
that the RManonURI should really be treated just like any other URI w.r.t. 
things like identity, grouping or any other logic that may exist based on 
the wsa:To value.

thanks
-Doug
[1] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0067.html