Identity w.r.t. RM's anon URI

There's a point I'd like to bring up w.r.t. RM's anon URI that I think 
hasn't been mentioned before and I think it might be causing some 
confusion.  The RM anon URI template is defined as:

    http://docs.oasis-open.org/ws-rx/wsrm/200608/anonymous?id={uuid}

A lot of people look at the "uuid" portion as the queueID - and while I 
understand this perception it is actually not correct.  As has been stated 
before, this URI indicates that the appropriate backchannel is meant to be 
used and it allows for each backchannel to be uniquely identified. Clearly 
the "uuid" portion is meant to be the distinguishing portion.  However, it 
is also important to point out that the client of messages targeted to 
this URI _does not_ need to actually examine this uuid, in isolation, at 
all.  And I think this is part of the misunderstanding.

  The first part of the URI "http" thru "?id=" is simply there to provide 
a constant string that allows for people to know we're dealing with a new 
special URI.  The "uuid" actually has no meaning at all except to provide 
uniqueness.  W.r.t. comparing the wsrm:Address element passed in the 
MakeConnection with the wsa:To value and any pending message, the RM spec 
says:

    This Address property and a message?s WS-Addressing destination 
property are 
    considered identical when they are exactly the same 
character-for-character.

This means that the client endpoint sending messages to this URI does not 
actually need to extract the uuid at all, it can treat the entire URI as 
one string.  This is one of the reasons we've repeatedly said that this 
URI is really no different from other URIs - it just identifies the 
endpoint not a queue.  Ignoring the fact that the RManonURI says it should 
be a uuid, we could have just as easily allowed URIs to look like:
    http://docs.oasis-open.open/ws-rx/wsrm/200608/anonymous/dugsThinkspad
I sometimes wonder if we picked a form like this if it would have removed 
some confusion.

In my mind these forms are semantically equivalent though - the client 
will not actually try to open a new connection to the wsa:Address, and the 
URI uniquely identify the target endpoint.  And this is similar to what 
WSA does today with its special URIs - except the semantic meaning 
associated with them is different.  I think WSA did a really good job in 
this respect.  By allowing for special EPRs (e.g. anon and none) to be 
treated just like any other EPR by virtually all layers of our soap 
endpoints it provides a nice separation and keeps the semantics of how to 
actually interpret the wsa:Address portion of the EPR away from everyone 
except the one piece that actually must know how to deal with it - the 
transport layer.  This of course is related to my previous note today [1].

On a related topic - there are times when the sending machine may use the 
wsa:To URI for some additional purposes aside from simply being the 
endpoint to which it opens connections.  For example, it may be used for 
some type of grouping mechanism.  E.g., it may choose to place all 
messages destined for one URI into the same RM Sequence.  A simple 
strcmp() is all that is needed - and this works whether we're dealing with 
real (async) EPRs or the RManonURI in an EPR.  If we were used a fixed URI 
(like WSA's anon) we would have to have a different grouping algorithm 
depending on whether we were in an sync model or async model.  For 
example, the async model would still look at just the wsa:To but the sync 
model would need to look at something else - like perhaps a ref-p (and 
then we also have the whole issue of ref-p's being opaque).  This means 
that any logic currently based on the wsa:To value would need to be aware 
of this special case - which is not a good idea - and one of the many 
reasons we tried very hard to make this sync MEP look (and smell) as much 
like the async MEP as possible.  Again, we felt it was very important that 
the code sitting above the actual transport layer would be allowed to 
remain untouched and continue to treat an RManon EPR just like any other 
EPR.

Hope this helps - or at least doesn't make things worse  :-)

thank
-Doug

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