On 27 Mar 2015 21:43, "Phillip Hallam-Baker" <phill(_at_)hallambaker(_dot_)com>
wrote:
On Fri, Mar 27, 2015 at 8:37 AM, Dave Cridland <dave(_at_)cridland(_dot_)net>
wrote:
On 27 March 2015 at 03:42, Phillip Hallam-Baker
<phill(_at_)hallambaker(_dot_)com>
I have no idea what you're on about here.
Then why not take a deep breath and read what was written before
making another response?
Oh, I read it. It just seemed irrelevant. These are not cases where a
private identifier has leaked into common use and become embedded, this is
a case where the scheme and namespace were registered, and documented on
the standards track.
If you don't understand the issue and you don't care, then why respond?
You're taking my statements out of context, probably quite deliberately,
but in any case, let's review.
Your original note had the subject line preserved in this one. It clearly
proposes to remove the urn: "prefix" (as you insist on calling the scheme).
You then gave an example of the IETF's namespace, a pre-existing identifier.
I said that there were good reasons to have such a scheme, but most
importantly stripping the scheme as you had clearly proposed was a very
poor idea.
Obviously there are good reasons not to change names already assigned.
And you agree with that latter point, apparently, despite your original
statements.
The urn: prefix is very much like the x-header in this respect.
No, that's about a retro fit namespace for unregistered, ad hoc, often
temporary identifiers becoming embedded into de facto standards.
urn, as a scheme, has almost the opposite problem, in that you cannot
register a namespace within it without jumping through some extensive
hoops, and there is no expectation that organisations which have registered
a urn namespace would graduate to a URI scheme.
Those
http: URLs have obviously stuck in the XACML spec because there was no
value in changing an existing registration.
It's certainly a reasonable assumption, if your symptoms on the origin is
correct. There's lots not to like about it, though, and my point here was
that if we used the IETF urn space better, and more visibly, we'd probably
avoid it.
But we don't need to keep demanding the same mistake be made over. The
urn: scheme is clearly causing confusion. Lets clear the confusion by
registering the scheme the IETF already uses (ISSN) and is about to
use (DOI) as top level schemes.
I'm not clear on the confusion.
I agree that urn registration is a pain, and it lacks any domain based ad
hoc usage. Both those are bad; Google, for example, use both an
unregistered scheme of google, and a urn namespace urn:google. The former
they could in principle register; but the latter they couldn't due to the
draconian rules.
Otherwise, I really don't see what it so confusing about four characters.
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.
So why respond in such a ridiculous fashion?
My apologies, I didn't realise you had the sole right.
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).
Perhaps you could explain how little you care in some more detail?
Certainly. If a particular identifier is relatively uncommon or niche, then
I think it's helpful to have a clear syntactic indicator if it is not
directly resolvable, which the urn scheme provides. I appreciate that
whether an identifier is resolvable is to an extent a matter of opinion,
though, and hence individual cases are not something I want to get drawn
into.
Secondly, the IETF urn tree in particular seems very verbose and over
engineered to my eyes. I would be entirely unsurprised if this alone puts
people off. For new urn namespaces, this is of course irrelevant, one would
hope, but it may be a contributing factor. Again, I wouldn't want to get
drawn into whether this affects a specific case.
Does that help clarify?
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.
Did I write an Internet Draft suggesting that?
No, it was an email. It's at the beginning of this thread if that helps you
locate it.
Dave.