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.
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.
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. I'd be much happier if those specs had used a urn@ietf:rfc:...
identifier instead (or even asked the IETF to mint a urn:ietf:ldap,
perhaps). In fairness, the situation with the urn:ietf:rfc: namespace *is*
slightly odd, but removing "urn:" is not going to magically solve the fact
there's both abstract and directly-addressable names for the same thing.
Yet there were demand to resolve urn:ietf:rfc:2648, the resolution is
trivial, and the fact nobody has done it probably says something.
Of course, it's *also* tremendously useful to be able to drop URLs into
slots intended for abstract names, too - the fact I can mint an XML
namespace within our corporate http://www.surevine.com/ URI space is
undeniably useful.
So I strongly disagree that:
a) There is a problem worth solving here.
b) The proposed solution is at all sensible.
Dave.