----- Original Message ----- From: "Phillip Hallam-Baker" <phill@xxxxxxxxxxxxxxx> To: "Dave Cridland" <dave@xxxxxxxxxxxx> Cc: "Michael Richardson" <mcr+ietf@xxxxxxxxxxxx>; "IETF Discussion Mailing List" <ietf@xxxxxxxx> Sent: Friday, March 27, 2015 3:42 AM > 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. Phillip I wonder if you are familiar with NETCONF and YANG, the latter currently undergoing an explosive growth the like of which I have not seen in the IETF before. Both make extensive use of urn: and while the output of a IETF WG is likely to be urn:ietf: the probability is that many other organisations, as with SNMP, will create their own modules. Since these are (XML) namespaces, I wonder what you would suggest as an alternative. Tom Petch > 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. >