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