Re: date in URN

   Is the idea that if the URN can't be resolved via the NA since
the  NA  went away, then as a fallback, it could then be resolved
via the date?  Perhaps the only really persistent identifiers are
timestamps.   And  perhaps a namespace based only on time is what
is needed. But it shouldn't be a flat namespace.

Larry Masinter wrote:
|
|> Also, would you elaborate on the difficulties with potential reuse of
|> identifiers and how this solves them. If URNs will have a date in them,
|> then the RFC should say something about why they are needed.
|
|The prototypical cases of 'reuse of identifiers' is that over the
|lifetime of URNs, it is highly likely that _some_ DNS names will be
|reassigned to organizations that have no relationship to the original
|DNS owner. Interesting examples include 'mtv.com' and 'kaplan.com',
|where after a trademark dispute, the name was reassigned.
|
|In such cases, relying on the new "publisher" not to reuse or to
|maintain the URN authority of original documents assigned by the
|original publisher with the same name is unrealistic.
|
|Originally, it was pointed out that 'a URL + a timestamp is a URN', in
|that it is a permanent identifier that is globally unique, if it is
|used to identify 'the resource that was available at that location
|at that time.' (there's some ambiguity about whether you mean 'the
|lastest version of' vs. 'that exact version'). The new observation is
|that the granularity of the timestamp needn't be to the second, and
|that the timestamp is as much associated with the naming authority as
|it is the document.
|
|


-- 
Michael Shapiro                   mshapiro@ncsa.uiuc.edu
NCSA                              (217) 244-6642
605 E Springfield Ave. RM 152CAB  fax: (217) 333-5973
Champaign, IL 61820

Received on Friday, 23 June 1995 11:52:01 UTC