On 27 March 2015 at 03:42, Phillip Hallam-Baker
<phill(_at_)hallambaker(_dot_)com>
wrote:
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.
I have no idea what you're on about here.
All three examples given above are fully registered and described in
standards-track documents.
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.
It's a moot point. Removing it now would not solve that confusion, and
would introduce more confusion.
We should define URI schemes for DOI, UPC and ISSN and make them all top
level.
That is an entirely different matter, and one that I struggle to care about.
That is, I don't care whether new registrations use a urn: prefix or not;
"urn:" might make clear that these are non-resolvable, I certainly dislike
the endless urn:ietf:dragons:xml-params:beware:of:the:leopard style of URN
the IETF seems to prefer to mint, but really there's more important things
in life, like whether I should put that pasty in the microwave about now.
(I think I probably should).
On the other hand, bombastically declaring that "urn:" should be stripped
everywhere without any further thought is, I think, very short-sighted;
more so in the face of obvious examples of problems.
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).
Yes; these are references to LDAP attributes, and are of the form
http://www.ietf.org/... rfcXXX.txt#attributeName. I'm in no way trying to
claim this is sensible.
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.
I think including a directly addressable entity's name as a protocol
identifier is generally confusing to people, not software; at best you're
describing people as idiots, at worst you're anthropomorphising.
Of course, this rather argues against your point either way.
Dave.