ietf
[Top] [All Lists]

Re: We should drop the useless urn: prefix

2015-03-28 09:20:41
On 03/27/2015 11:54 AM, Larry Masinter wrote:
I think this discussion is missing the original requirements
that led to “urn:”  https://tools.ietf.org/html/rfc1737
“Functional Requirements for Uniform Resource Names”.




That conversation predates the mistake of introducing the false
distinction between URLs and URNs.
The distinction between URLs and URNs is not merely that
one is a “location” and the other is a “name” in some
abstract sense.

I think the practical distinction between “urn:<nsid>:<blah>”
and “<nsid>:<blah>” is that the “urn:” form provides some
useful information in the cases where <nsid> identifies
an externally, non-algorithmic organization that maintains
the authority of deciding when two expressions are “the same”
(see paragraph 2 of section 5 of RFC 1737).
[...]
So while I agree that in many cases, the initial four
characters “urn:” are unnecessary, at least in some
situations, the prefix is useful in pointing out that no
resolution service that ultimately doesn’t consult
the identified naming authority for dispute resolution
can be authoritative.

Indeed, advertising the urn: prefix does expose valuable information about the identifier to both human and machine readers of those identifiers.

There's another difference that was at least intended and is still feasible. With the browsers available as of the time that URNs were designed, there was no extension mechanism that would permit handlers for new URI types to be added to a browser without changing the browser source code. We knew that there would be a variety of URN namespaces and didn't want to burden browser vendors/authors with having to explicitly support each of them in order for all of those URN namespaces to be resolvable. By having a common syntax for all URNs and at least one means by which browsers could discover resolvers for each of those URN types, we hoped that we could lower the burden for browser vendors/authors to support URNs.

These days, I gather that there are ways that browsers can be extended to support new URI types without having to modify the browser source code. But it's still easier to install one plugin than N plugins, one for each URN namespace that has a resolver.

(Note that one (perhaps subtle) requirement that results from the intention that URNs be usable for the very long term is that you don't want to inherently tie URN resolution (either in general or for URNs of any namespace) to any particular protocol, since some protocols will likely need to evolve over time, and others may simply fall out of favor. Indeed, we've seen both of these happen. So a URN architecture that assumes that resolution protocols aren't static makes good sense.)

Keith

<Prev in Thread] Current Thread [Next in Thread>