[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New issue: Opaqueness of URI identifiers not preserved by RM anon URI
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). |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]