Re: [urn] I-D Action: draft-saintandre-urn-example-00

[Larry Masinter <[e-mail]>]

> On 01/19/2013 11:27 AM, Larry Masinter wrote:
> > For my part, the only way I can make peace with URNs is to take the
> perspective that "persistence" is wishful thinking, that "resource" is a myth,
> and that the primary use for URNs is a way of importing into the space of URIs
> those identifiers that are maintained by other organizations (namely, the
> "naming authority").
> 
> Which of course has nothing to do with the purpose of URNs.

http://www.ietf.org/rfc/rfc1737.txt documents the purpose of URNs.
The fifth bullet of section 2 "support of existing legacy naming systems".
So "nothing to do with" is false. My point was that such uses are the
primary use for URNs, and that URN namespaces that are not imports
of other naming systems aren't as useful.



> > Of course, you should only use naming authorities who can offer a credible
> promise of persistence of the association of the name to the thing named, but
> each service makes its own guarantees. IETF offers that "STD 66" names
> something, even if the document changes, and that "RFC 3986" names
> something which is currently the same document. But that also what it names
> is somewhat independent of the format it's set in, or the location.
> >
> > This description of URNs doesn't require anyone to believe in Resources or
> that URNs Name them, or that they do so Uniformly.  It explains _most_ of the
> URN namespaces.

> No it doesn't.  it's just a mostly-coincidental characteristic of some URNs.

which URN namespaces (besides uuid) does it not explain?

> > The only problem is the darn urn:uuid: namespace, where "uuid" is not an
> authority at all, and there's nowhere to turn to figure out who might have
> known at any point in time what was meant by it. I don't know what to do with
> urn:uuid except to declare it a mistake.
> That might not be a bad idea, but not for the reason you cite.
> 
> To attempt to define what URNs are in terms of what you observe about
> URNs is to attempt to destroy their utility.

URNs are already defined, I'm not attempting to redefine them.
I'm pointing out that the URN syntax and semantics is useful in some circumstances
and not in others. If you're not importing someone else's naming system, don't bother
with the extra four characters "urn:", just make a new URL scheme.