Subject: We should drop the useless urn: prefix

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Mar 2015 11:32:56 -0500

Following the discussion at the plenary where I didn't get the chance
to put the record straight, I have been looking at the existing IETF
URN scheme for RFCs and IDs. I plan to add support for this to the
output of my rfctool.

The rfc on IETF URNs is farily old and dates from the 'wasted years'.
https://tools.ietf.org/html/rfc2648
urn:ietf:rfc:2648

So some history on URLs and URL like things. Back in 1993 I discussed
URNs with Tim Berners Lee including the fact that to buy and sell
'stuff' online we would want URLs for cans of baked beans etc. So
there should be a UPC: 'URL'.

That conversation predates the mistake of introducing the false
distinction between URLs and URNs. From a semiotic point of view, ALL
URIs are names except for the 'data' URI and the digest based URIs. A
DNS name is a name. That is why is is called the Domain NAME System.

Whether a URI is a name or a locator depends entirely on how it is
used. Order baked beans from Amazon via the UPC code and it is a
locator. You choose your 'baked beans resolution service' as Amazon,
Peapod, Tesco, etc.

Names and locators are distinct use categories but not distinct
syntactic categories. The distinction comes from whether the name is
sufficiently complete to resolve the identifier to the identified or
not.

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 think it comes down to ring-kissing: Lets make everyone acknowledge
the fact that they are participating in our information universe which
we control.

The insistence on the urn prefix is leading to divergence where it
comes to DOIs. The DOI folk understand naming at least as well as we
do and they have no interest at all in sticking a 'URN' prefix at the
start.

http://www.doi.org/factsheets/DOIIdentifierSpecs.html

DOI: is a perfectly valid and well defined scheme. We should recognize
it as such and assign a top level URI identifier.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Mar 2015 14:42:17 -0400

> Why make people write urn:ietf:rfc:2648 when ietf:rfc:2648 is sufficient?

I must agree.
This distinction has always confused me.

This is also a situation where we (the IETF) have failed to put our money
where our mouth is.... where is the ietf:rfc URN resolution service? Where is
the reference code?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 26 Mar 2015 13:41:21 -0600

On 3/26/15 10:32 AM, Phillip Hallam-Baker wrote:
> URN scheme for RFCs and IDs.

There is no such thing as a URN scheme. There is a 'urn' URI scheme, and 
there is a 'urn:ietf' URN namespace (and many other URN namespaces).

> I plan to add support for this to the
> output of my rfctool.

Great!

> https://tools.ietf.org/html/rfc2648

I'm not sure what your reference to the "wasted years" is meant to 
imply. Should we throw out all work done in those years? And what are 
the dates so that we can understand which RFCs to ignore?

> there should be a UPC: 'URL'.

Do feel free to write an Internet-Draft that defines and registers the 
'upc' URI scheme.

> syntactic categories.

Well, draft-ietf-urnbis-rfc2141bis-urn aligns URNs with URI syntax, 
which should make you happy. :-)

> The distinction comes from whether the name is
> for the urn: prefix disappears.

As far as I can see, your conclusion does not follow from your premise. 
Perhaps you mean that, from a semiotic point of view, we ought to have 
only three schemes (names, data, and digests)?

> It is not only useless, it is

I agree that having both 'urn:ietf:rfc:2648' and 'ietf:rfc:2648' would 
be confusing. So let's not do that.

> Why make people write urn:ietf:rfc:2648 when ietf:rfc:2648 is sufficient?

Do feel free to write an Internet-Draft that defines and registers the 
'ietf' URI scheme. Although if you do, you'll violate your rule about 
divergent meanings.

> the fact that they are participating in our information universe which

There are multiple information universes, as the existence of Handles 
and DOIs indicates. As far as I know, no one is insisting that everyone 
needs to participate in the URN universe.

However, as far as I can see, you are insisting that we destroy the URN 
universe (since it is based on a mistake). What do we tell everyone who 
has built things in that universe? Please note that the URN universe 
includes some very significant groups such as the publishing and 
information sciences community (ISBN, ISSN, NBN) and a number of our 
colleagues in other SDOs (3GPP, GSMA, ISO, MPEG, OASIS, SWIFT, etc.).

> comes to DOIs.

No it isn't, because the DOI folk have studiously (and, per your 
reasoning, correctly) ignored the URN universe and have built their own 
universe.

> The DOI folk understand naming at least as well as we

Naturally, that is their prerogative. There are no protocol police and 
the existing of URNs doesn't force anyone to use them.

> it as such and assign a top level URI identifier.

As you are no doubt aware, we don't just "assign a top level URI 
identifier" (i.e., URI scheme) out of the blue; instead, we follow the 
process defined in RFC 4395. However, once again, do feel free to write 
an Internet-Draft that defines and registers the 'doi' URI scheme.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Dave Cridland <[email-masked]>
Date: Thu, 26 Mar 2015 22:10:05 +0000

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Mar 2015 22:42:38 -0500

On Thu, Mar 26, 2015 at 5:10 PM, Dave Cridland <[email-masked]> wrote:
> 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.

We should define URI schemes for DOI, UPC and ISSN and make them all top level.

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

---

From: t.p. <[email-masked]>
Date: Fri, 27 Mar 2015 11:30:27 +0000

----- Original Message -----
From: "Phillip Hallam-Baker" <[email-masked]>
To: "Dave Cridland" <[email-masked]>
Cc: "Michael Richardson" <[email-masked]>; "IETF Discussion
Mailing List" <[email-masked]>
Sent: Friday, March 27, 2015 3:42 AM
> > It's extremely useful in the XMPP world. We have both urn:xmpp (for
protocol
> 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

---

From: Dave Cridland <[email-masked]>
Date: Fri, 27 Mar 2015 12:37:21 +0000

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

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

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

> to avoid unnecessary lookups when idiot software goes and slams a

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.

---

From: Larry Masinter <[email-masked]>
Date: Fri, 27 Mar 2015 15:54:10 +0000

I think this discussion is missing the original requirements
that led to “urn:”  https://tools.ietf.org/html/rfc1737
“Functional Requirements for Uniform Resource Names”.

>distinction between URLs and URNs. 

The distinction between URLs and URNs is not merely that
one is a “location” and the other is a “name” in some
abstract sense.

I think the practical distinction between “urn:<nsid>:<blah>”
and “<nsid>:<blah>” is that the “urn:” form provides some
useful information in the cases where <nsid> identifies
an externally, non-algorithmic organization that maintains
the authority of deciding when two expressions are “the same”
(see paragraph 2 of section 5 of RFC 1737).

Whether two streams of data, concepts, protocol parameters,
 get the same ISSN, ISBN, UPC code, RFC number, MIME type,
etc. and thus are considered “the same” depend on an
identified “naming authority”; the nsid identifies the
naming authority.

With this perspective, urn:uuid: was a mistake, since
there is no uuid naming authority to resolve the question.

So while I agree that in many cases, the initial four
characters “urn:” are unnecessary, at least in some
situations, the prefix is useful in pointing out that no
resolution service that ultimately doesn’t consult
the identified naming authority for dispute resolution
can be authoritative.

Larry
—
http://larry.masinter.net

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Mar 2015 17:43:31 -0400

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

My concern was very simple. In the plenary it was announced that DOIs
would be added to RFCs. There was then a protest made that 'DOIs are
not URNs' and an assertion that the people proposing them didn't
understand (what was not understood was less clear).

I find this to be a problem for the following reasons:

1) DOIs are very clearly a widely used naming scheme that has
demonstrated considerable utility.

2) It is clear that all sensible requirements for making a DOI: urn
scheme have been met.

3) It seems that the IETF still has not overcome it's principal
obstacle in addressing URI related matters which is the attitude of
many of the self appointed experts.  'Repect mah authoritah' does not
make for a persuasive argument.

Yes, I am one of those people who will on occasion say 'that is
wrong'. But I always say why I think something is wrong. What I find
rather grating and insulting about the topic of naming is that so many
people feel free to say that something is wrong for reasons that they
won't bother to explain. Or the closely related 'this is a very
difficult issue that only a few people understand and I am not one of
them'.

If you don't understand the issue and you don't care, then why respond?

Looking at the DOI people's Web Site I find their reasons for not
applying for a URN scheme is that they don't see the value in
prefixing DOIs with urn:doi: when doi: is clearly sufficient.

My point is simply that that is a perfectly good argument and we
should look for ways that we can bring systems into the URI
infrastructure.

Obviously there are good reasons not to change names already assigned.
The urn: prefix is very much like the x-header in this respect. Those
http: URLs have obviously stuck in the XACML spec because there was no
value in changing an existing registration.

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.

> That is an entirely different matter, and one that I struggle to care about.

So why respond in such a ridiculous fashion?

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

> 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? If so I have forgotten
having done so. Quite possible of course. I do write quite a few of
them. And I can write a draft pretty quickly now that I have rfctool
that lets me compose them in Word.

Ah no, I did not. I see what happened now. You read my post and got
worried that as so frequently happens in the IETF, a post submitted to
the ietf discuss list based on conversations in the bar the night
before is likely to become an RFC before the week is out if nobody
gets on the case immediately.

> http://www.ietf.org/... rfcXXX.txt#attributeName. I'm in no way trying to

Take a look at the identifiers for int32 etc.

---

From: <[email-masked]>
Date: Sat, 28 Mar 2015 01:26:25 +0000

> And I can write a draft pretty quickly now that I have rfctool

This is the IETF design equivalent of script kiddies.

(CCSDS protocol design documents are done in Word; says much.)

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf <[email-masked]> on behalf of Phillip Hallam-Baker <[email-masked]>
Sent: Saturday, 28 March 2015 8:43 AM
To: Dave Cridland
Cc: Michael Richardson; IETF Discussion Mailing List
Subject: Re: We should drop the useless urn: prefix

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 28 Mar 2015 00:14:08 -0400

> (CCSDS protocol design documents are done in Word; says much.)

Some of us want to make the IETF more inclusive and break down
makework barriers to participation.

I see no reason to denigrate people for wanting to use the right tool
for the job or casting aspersions on the work done in other bodies.

Getting ten government agencies to co-ordinate work on a technical
specification that people's lives are going to depend on is quite a
feat. If we want other folk to respect our judgement we should treat
them with equal respect.

---

From: Dave Cridland <[email-masked]>
Date: Sat, 28 Mar 2015 08:42:49 +0000

> Then why not take a deep breath and read what was written before

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

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.

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

My apologies, I didn't realise you had the sole right.

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

> > everywhere without any further thought is, I think, very short-sighted;
more
> 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.

---

From: Keith Moore <[email-masked]>
Date: Sat, 28 Mar 2015 10:20:19 -0400

> (see paragraph 2 of section 5 of RFC 1737).
[...]
> the identified naming authority for dispute resolution

Indeed, advertising the urn: prefix does expose valuable information 
about the identifier to both human and machine readers of those identifiers.

There's another difference that was at least intended and is still 
feasible.   With the browsers available as of the time that URNs were 
designed, there was no extension mechanism that would permit handlers 
for new URI types to be added to a browser without changing the browser 
source code.  We knew that there would be a variety of URN namespaces 
and didn't want to burden browser vendors/authors with having to 
explicitly support each of them in order for all of those URN namespaces 
to be resolvable.   By having a common syntax for all URNs and at least 
one means by which browsers could discover resolvers for each of those 
URN types, we hoped that we could lower the burden for browser 
vendors/authors to support URNs.

These days, I gather that there are ways that browsers can be extended 
to support new URI types without having to modify the browser source 
code.   But it's still easier to install one plugin than N plugins, one 
for each URN namespace that has a resolver.

(Note that one (perhaps subtle) requirement that results from the 
intention that URNs be usable for the very long term is that you don't 
want to inherently tie URN resolution (either in general or for URNs of 
any namespace) to any particular protocol, since some protocols will 
likely need to evolve over time, and others may simply fall out of 
favor.   Indeed, we've seen both of these happen.   So a URN 
architecture that assumes that resolution protocols aren't static makes 
good sense.)

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 28 Mar 2015 11:33:13 -0400

On 03/28/2015 04:42 AM, Dave Cridland wrote:
> 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.

One of the many things that motivated creation of URNs was to avoid the 
mess that resulted when DNS names were taken away from their owners, or 
when resources had to be rehosted elsewhere (say when an organization 
split or some of its activity moved to another organization), thus 
invalidating the URLs that had been assigned to those resources.   URNs 
are supposed to be long-term stable names in ways that it's difficult to 
assure for DNS-based URLs.

At one time people did kick around the notion of combining a DNS name 
with a date, to avoid that problem.  That would allow URNs with that 
name to continue to be valid, but depending on that the DNS name for 
resolution would still be problematic.   But that still has the 
potential for thorny trademark-related issues.   And there have at 
various times also been attempts to threaten the uniqueness of DNS 
names, e.g. by creating alternate DNS roots, so making URNs that relied 
on DNS names seemed dubious for that reason also.   Bottom line: 
embedding DNS names in URNs seems like a bad idea.

(One thing that handles and DOIs got right, and I wish we had done with 
URNs, was making their equivalent of "name space identifier" completely 
devoid of any company name or trademark.)

Keith