[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 29: Opaqueness of URI identifiers not preserved by RM anon URI
Issue 29 From: Jonathan Marsh
[mailto:jonathan@wso2.com] The
current formulation forces an endpoint to identify itself using a specific
form, namely by coining a UUID and constructing a URI from the RM anon template
in conjunction with this UUID. Forcing the identifier to be a URI has a
number of advantages (see http://www.w3.org/TR/2004/REC-webarch-20041215/#uri-benefits),
but forcing the identifier to assume a particular rigid form has a number of
disadvantages: 1)
It
may be more expensive than other ways a client can name itself. UUIDs are
one of the more costly ways to create an identifier. Especially if the
client already has a unique identifier, when the entire cost of generating a
duplicate identifier is unnecessary. 2)
It
may result in URI aliases. If the client already has a URI which
identifies it, the forced generation of an alias in the form required by the RM
anonymous template violates the advice of the Web Architecture to avoid aliases
(see http://www.w3.org/TR/2004/REC-webarch-20041215/#uri-aliases.) 3)
It
results in a URI that is not opaque. The ability of a client to construct
a URI which it can construct according to its own rules, and the ability of it
to provide that URI to others who can use it opaquely as an identifier, is a
desirable characteristic (see http://www.w3.org/TR/2004/REC-webarch-20041215/#orthogonal-specs).
In general it increases the orthogonality of specifications (in this case, the
WS-A spec which leverages the URI spec, and the RM spec). Jonathan
Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]