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

On the last WS-Addressing call we were discussing the option of making
the WSA anon a prefix, and allowing extension of the URI. A URI would be
considered "anonymous" if it began with the WSA anon, no matter what
followed. 
 
Would it be acceptable to replace the RM anon with the WSA anon + a
piece that made it clear we were talking RM + the uuid?
 
    "WSA anon string" /
docs.oasis-open.org/ws-rx/wsrm/200608/anonymous?id=uuid
 
or maybe something a little more abbreviated :-)
 
That would address the issues with wsaw:anonymous, and it would allow
the use you described below. It would even address your concern about
allowing other anon-like URIs. Apart from the extra length, would there
be problems with this approach? 
 
Tony Rogers
tony.rogers@ca.com <blocked::mailto:tony.rogers@ca.com> 
 

________________________________

From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Doug Davis
Sent: Wednesday, 11 October 2006 9:30
To: public-ws-addressing@w3.org
Subject: 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.ht
ml