New issue: Opaqueness of URI identifiers not preserved by RM anon URI

["Jonathan Marsh" <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