ietf
[Top] [All Lists]

Re: We should drop the useless urn: prefix

2015-03-26 22:43:02
On Thu, Mar 26, 2015 at 5:10 PM, Dave Cridland <dave(_at_)cridland(_dot_)net> 
wrote:


On 26 March 2015 at 18:42, Michael Richardson 
<mcr+ietf(_at_)sandelman(_dot_)ca> wrote:


Phillip Hallam-Baker <phill(_at_)hallambaker(_dot_)com> wrote:
    > Since urns are not a distinct syntactic category, the justification
    > for the urn: prefix disappears. It is not only useless, it is
    > unnecessary. There is no circumstance in which a urn subscheme and a
    > uri scheme should be allowed to have divergent meanings.

    > Why make people write urn:ietf:rfc:2648 when ietf:rfc:2648 is
sufficient?

I must agree.
This distinction has always confused me.


It's extremely useful in the XMPP world. We have both urn:xmpp (for protocol
namespaces and other abstract names) and xmpp: (for addressable entities)
and even xmpp:// (for client connection instructions).

There's no confusion.

Well obviously if you have an X-header and someone declares the same
header then there is an issue. Most cases there isn't.


Of course, if we made the urn: scheme identifier optional (more or less what
PH-B appears to suggest) it'd be most interestingly confusing.

I think urn: serves the same function of x-headers which is to say a
useless syntactic distinction that leads to unnecessary confusion.

We should define URI schemes for DOI, UPC and ISSN and make them all top level.


In some cases, I've seen people use URLs to RFCs as protocol identifiers,
too; I recall XACML does this for LDAP attributes, which is tremendously
weird.

Very weird since OASIS has their own urn namespace which they use in
xacml v3 and before that was defined, SAML used the document URNs (at
least in the specs I wrote).

Of course, if there was a prior use of a URL for that purpose it might
have been imported. The only advantage of URNs for that application is
to avoid unnecessary lookups when idiot software goes and slams a
server.