----- Original Message -----
From: "Phillip Hallam-Baker" <phill(_at_)hallambaker(_dot_)com>
To: "Dave Cridland" <dave(_at_)cridland(_dot_)net>
Cc: "Michael Richardson" <mcr+ietf(_at_)sandelman(_dot_)ca>; "IETF Discussion
Mailing List" <ietf(_at_)ietf(_dot_)org>
Sent: Friday, March 27, 2015 3:42 AM
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.
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.