Re: We should drop the useless urn: prefix

[Keith Moore <[e-mail]>]

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