RE: URNs, Namespaces and Registries

Comments on section 2.1 (Persistence) of URNs, Namespaces and Registries
[1].

Not all identifiers are intended to persist indefinitely. Some
identifiers (e.g., DDNS IP addresses) actually are intended to be
re-issued as needed. Some namespaces might be size constrained and
require re-use of identifiers so as not to exhaust the namespace. 

It think that one-time pseudonymns (like those used in assertions to
avoid profiling and protect privacy) are also somehow relevant to the
topic of persistence. When the subject of an assertion is identified by
a different identifier each time s/he connects to my site, I won't see a
persistent identifier for which I can assign access privileges, or
collect user preference/profile data. The next time that user connects
to my site, s/he'll have a different identifier that wouldn't match up
with the privileges/preference/profile data that I took the trouble to
associate with that user's prior identifier. When an identifier is
presented to my site, I'd like some syntactic indicator letting me know
whether or not I should even take the effort to set up access privileges
for that identifier. 

I'm not that concerned with avoiding "404 not found" errors. To me it's
much more important to know that for "persistent" identifiers, the
subject of the identifier never changes. Attributes such as roles,
citizenships, certifications, and others get associated with an
identifier so as to manage authorizations, and access to resources. If
the subject of an identifier changes (i.e., an identifier is re-issued
to a different subject), there is a high likelihood that the new subject
will mistakenly inherit the capabilities of the prior subject,
especially in delegated administration and federated scenarios where the
relying party has little visibility into the user management occurring
within another organization. A syntactic claim by the identity provider
that the relationship between an identifier and its subject persists,
and that the identifier will not be re-assigned, would be very valuable.

I agree that persistent identifiers is a management issue and not a
technology issue, and that it's up to the identifier minters to enforce
the degree of persistence they choose. However, there is value to a
consistent syntactic method for the minters to manifest their intentions
with respect to persistence and convey those intentions to another
party. A company such as mine has literally thousands of customer,
supplier, and partner companies -- it would pretty difficult for me to
keep track of the variety of approaches each partner might use to
indicate persistence.

Your example of using upper case to indicate persistence, and lower case
for non-persistence, doesn't sound right to me. I think the path segment
of a URI is case sensitive by definition, so you don't have the freedom
to vary case to meet such a convention. If the resource is a UNIX file
and you change the case in the URI, it no longer points to the intended
file, and may in fact point to a different file.

[1] http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.xml 


Marty.Schleiff

Received on Monday, 7 August 2006 20:42:07 UTC