On Thu, Mar 26, 2015 at 5:10 PM, Dave Cridland <dave@xxxxxxxxxxxx> wrote: > > > On 26 March 2015 at 18:42, Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote: >> >> >> Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> 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.