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.
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.