To: email@example.com Cc: firstname.lastname@example.org In-Reply-To: email@example.com's message of Thu, 22 Jun 1995 12:23:03 -0700 <95Jun22.firstname.lastname@example.org> Subject: Re: date in URN From: Larry Masinter <email@example.com> Message-Id: <95Jun22.firstname.lastname@example.org> Date: Thu, 22 Jun 1995 23:35:13 PDT > Is the idea to require a syntax that has a date? > dns-urn:netloc/date/doc-id yes > or would it just be part of the OS > dns-urn:netloc/OS (where OS = date/doc-id) I think for this to be useful, the date would have to appear in a well-known place. > 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.