W3C home > Mailing lists > Public > uri@w3.org > March 1997

Re: [URN] draft-ietf-urn-nid-req-01.txt

From: Karen R. Sollins <sollins@lcs.mit.edu>
Date: Fri, 28 Mar 1997 13:14:57 -0500
Message-Id: <199703281814.NAA05954@lysithea.lcs.mit.edu>
To: connolly@w3.org
Cc: uri@bunyip.com, ietf-url@imc.org, urn-ietf@bunyip.com

Let's step back a little, say to the URN requirements doc (and I
believe the IRL requirements doc).  There is a need to identify where
something is (and perhaps also how to get there, but that's another
story).  Where something is can be used to identify it as long as it
won't move and nothing else will be put in its place for the period
over which one wants to identify it.  As soon as one of those things
changes we need to be able to do one of two things, either notify
anyone who might want to access it in the future of the new identity
reflected in the new location or separate identity from location.
Since the identities may often be embedded in a potentially very large
number of immutable objects, separating the two concepts seems like
the best reasonable alternative.  Hence there is a certain burden of
proof on the proposer of an identification (URN) namespace that does
not hold true for a location (URL) namespace.  The URN namespace must
demonstrate adequately that the names will be persistent and
non-reassignable over a long enough period to serve the function of
being an identifier as we've defined it.  Hence, the process documents
for URN namespaces and URL namespaces should be somewhat different
from each other.  They also will be rather similar in many ways - no
problem.  It is the differences that justify the two separate
documents.  If there aren't differences, the documents need to be
fixed.  Due to a day job that has kept my nose to the grindstone day
and night weekdays and weekends for the last several weeks, I haven't
yet had a chance to read the flood of new documents, so I can't
comment on the specific documents, except to say that they SHOULD be
different and if they aren't, they need to be fixed.

Received on Friday, 28 March 1997 13:15:09 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:34 UTC