Subject: [urn] the UUID namespace

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 09 Sep 2011 11:09:19 -0600

I like UUIDs, for the reasons described in RFC 4122:

   One of the main reasons for using UUIDs is that no centralized
   authority is required to administer them.... As a result, generation
   on demand can be completely automated, and used for a variety of
   purposes.

However, RFC 4122 is a case of "one of these things is not like the
other". Every other formal namespace involves active management of the
URN assignment process, in accordance with RFC 3406. By contrast, URNs
in the urn:uuid: namespace are assigned without any management:

   The UUID generation algorithm described here supports very
   high allocation rates of up to 10 million per second per machine if
   necessary, so that they could even be used as transaction IDs....
   The unique ability to generate a new UUID without a registration
   process allows for UUIDs to be one of the URNs with the lowest
   minting cost.

Therefore it seems to me that, handy as UUIDs are, they don't deserve to
be URNs. Indeed, the existence of the urn:uuid: namespace causes
confusion because we periodically hear about people who want to register
formal namespaces for things like SHA hashes. I propose that it would be
proper and beneficial to publish an RFC that defines UUIDs without the
URN namespace (perhaps with a URI scheme instead) and that therefore
obsoletes RFC 4122 and declares it to be historic.

Thoughts?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ted Hardie <[email-masked]>
Date: Fri, 9 Sep 2011 10:27:48 -0700

> in the urn:uuid: namespace are assigned without any management:
So, I think you're mixing mechanism and desire effect.  The desired effect
is that URNs be unique across space and time.  The formal management
mechanisms are there to guarantee this property and to bind the resulting
identifier to a resource.  RFC 4122 says:

Identifier uniqueness considerations:
      This document specifies three algorithms to generate UUIDs: the
      first leverages the unique values of 802 MAC addresses to
      guarantee uniqueness, the second uses pseudo-random number
      generators, and the third uses cryptographic hashing and
      application-provided text strings.  As a result, the UUIDs
      generated according to the mechanisms here will be unique from all
      other UUIDs that have been or will be assigned.

If any of the algorithms mentioned can be shown not to guarantee uniqueness,
then I believe it should be removed by publication of a successor document.
If we are convinced that *no* algorithmic method can be used that generates
uniqueness, then perhaps a shift to a URI scheme (for which no such
guarantees are available) is appropriate.  But I'm not hearing that in your
argument.  Is there a credible risk that UUID URNs are not unique?

regards,

Ted

> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 09 Sep 2011 11:53:39 -0600

On 9/9/11 11:27 AM, Ted Hardie wrote:
> 
> On Fri, Sep 9, 2011 at 10:09 AM, Peter Saint-Andre <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> So, I think you're mixing mechanism and desire effect.  The desired
> effect is that URNs be unique across space and time.  The formal
> management mechanisms are there to guarantee this property and to bind
> the resulting identifier to a resource.  RFC 4122 says:
> 
> If any of the algorithms mentioned can be shown not to guarantee
> uniqueness, then I believe it should be removed by publication of a
> successor document.  If we are convinced that *no* algorithmic method
> can be used that generates uniqueness, then perhaps a shift to a URI
> scheme (for which no such guarantees are available) is appropriate.  But
> I'm not hearing that in your argument.  Is there a credible risk that
> UUID URNs are not unique?

Interesting. So the UUID algorithm itself effectively provides a managed
process for URN assignment. Correct?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ted Hardie <[email-masked]>
Date: Fri, 9 Sep 2011 11:31:07 -0700

> process for URN assignment. Correct?
Yes, that's the theory.   Each of the algorithms is intended to provide a
process which guarantees uniqueness.  For the statistical algorithms, the
presumption has been that, run correctly, there is a vanishingly small
chance of collision; it's true that it is non-zero, but the chance of
collision due to human error in a managed system is probably higher.

regards,

Ted

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 09 Sep 2011 12:37:05 -0600

On 9/9/11 12:31 PM, Ted Hardie wrote:
> On Fri, Sep 9, 2011 at 10:53 AM, Peter Saint-Andre <[email-masked]
> Yes, that's the theory.   Each of the algorithms is intended to provide
> a process which guarantees uniqueness.  For the statistical algorithms,
> the presumption has been that, run correctly, there is a vanishingly
> small chance of collision; it's true that it is non-zero, but the chance
> of collision due to human error in a managed system is probably higher.

Thanks. I'd never thought of it that way, but it makes sense. I hereby
retract the suggestion to obsolete RFC 4122. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 10 Sep 2011 10:56:15 +0900

On 2011/09/10 3:37, Peter Saint-Andre wrote:
>> On Fri, Sep 9, 2011 at 10:53 AM, Peter Saint-Andre<[email-masked]

Apart from the arguments already given, it'd be a very bad idea to just 
obsolete RFC 4122. Making preexisting urn:uuid: identifiers obsolete 
would be the worst in terms of persistency.

Regards,   Martin.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Sep 2011 12:09:23 -0600

> would be the worst in terms of persistency.

Obsoleting RFC 4122 would not obsolete existing URNs in that namespace.

But I don't plan to try obsoleting RFC 4122 anyway, so I see no point in
discussing it further.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Juha Hakala <[email-masked]>
Date: Tue, 13 Sep 2011 10:54:43 +0300

Hello,

Based on this discussion, it seems to me that we should add into 
RFC3406bis a chapter which discusses obsoleting URN namespaces. We may 
also need to refine the paragraphs which discuss management of (formal) 
namespaces.

I see no problem in obsoleting experimental namespaces. Since there is 
no IANA registration, such decisions can be made by organizations which 
utilize these namespaces (which are not supposed to be persistent).

In contrast, informal namespaces should be treated in the same manner as 
the formal ones.

IANA may / should consider allowing deprecation of an informal or formal 
namespace if a) it has never been used (and this can be proven); b) it 
is consistently and extensively abused (and this can be proven); or c) 
if the registrant sends a request asking for deprecation. The cases of 
the last kind can happen e.g. when a namespace registration is replaced 
by a new one, and the new identifier standard requires another namespace.

There will also be cases when the registrant / user of a namespace 
disappears and the resolution services the organization has maintained 
collapse as a result. Such cases will be very problematic to deal with; 
even finding out what is going on can be difficult. Ideally somebody 
else will pick up the torch, but if this does not happen, it may be 
necessary to obsolete the namespace.

Deprecation of a namespace means only that no new URNs in that namespace 
should be assigned. Existing URNs will still be valid and they should 
remain managed and actionable as well.

As regards the UUID namespace, each URN:UUID is unique, so there is some 
justification to say that assignment of URN:UUIDs is a managed process. 
   There are other URN namespaces where the level of control is much 
higher, such as ISBN. There is nothing wrong with this; most PIDs allow 
a lot of diversity. For instance, assignment of Handles or ARKs may be 
either tightly controlled or relaxed, depending on who is using them. An 
important difference between Handles and DOI is that the latter is more 
strictly controlled.

People managing e.g. the Handle system and ARK system have no way of 
checking who is using these persistent identifiers and how they are 
using them. URNs are different; namespace registration is a control 
mechanism, and I am glad we have such a mechanism in place. Up to now, 
central management of the URN system has been relaxed; namespace such as 
URN:UUID where almost anything can be identified by almost anybody is 
not exactly a strictly managed one. IANA can tighten the control if they 
deem it necessary, or we can make more requirements in RFC3406bis. I 
don't see much need for this; we should just admit the fact that there 
will be all kinds of URN namespaces. And some of them, alas, will not be 
persistent. But at least for the time being for instance this

http://verkottaja.tieke.fi/urn:uuid:0113C86C-F6F9-FF39-3917-7AD0D560A92B/

HTTP URI is working fine.

Best regards,

Juha

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email [email-masked], tel +358 50 382 7678

---

From: "Michael A Dolan" <[email-masked]>
Date: Fri, 9 Sep 2011 10:28:12 -0700

RFC4122 is in pretty widespread use.  So, any new RFC would still need to be
backwards compatible.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter
Saint-Andre
Sent: Friday, September 09, 2011 10:09 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [urn] the UUID namespace

However, RFC 4122 is a case of "one of these things is not like the other".
Every other formal namespace involves active management of the URN
assignment process, in accordance with RFC 3406. By contrast, URNs in the
urn:uuid: namespace are assigned without any management:

Therefore it seems to me that, handy as UUIDs are, they don't deserve to be
URNs. Indeed, the existence of the urn:uuid: namespace causes confusion
because we periodically hear about people who want to register formal
namespaces for things like SHA hashes. I propose that it would be proper and
beneficial to publish an RFC that defines UUIDs without the URN namespace
(perhaps with a URI scheme instead) and that therefore obsoletes RFC 4122
and declares it to be historic.

Thoughts?

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: "Michael A Dolan" <[email-masked]>
Date: Fri, 9 Sep 2011 10:33:42 -0700

I should add that UUID's are used widely to number media assets and are thus
a namespace and are thus appropriate for a URN encoding.

There are different forms for constructing UUIDs.  Some are guaranteed to be
unique as they are based on the IEEE MAC address namespace. Some are
"statistically unique".

                Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted
Hardie
Sent: Friday, September 09, 2011 10:28 AM
To: Peter Saint-Andre
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [urn] the UUID namespace

On Fri, Sep 9, 2011 at 10:09 AM, Peter Saint-Andre <[email-masked]>
wrote:

regards,

Ted

Thoughts?

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: Larry Masinter <[email-masked]>
Date: Fri, 16 Sep 2011 04:08:38 -0700

RFC 4122 says "Since UUIDs are unique and persistent ."  but in what way are UUIDs "persistent"? 

UUIDs might be persistently unique. UUIDs are not persistently resolvable, or even persistently confirmable, i.e., if someone claims to resolve a UUID to a resource, is can that resolution be confirmed in any way? 

Personally, what I don't like about urn:uuid is that the "naming authority"  (i.e., "uuid") doesn't in fact name an organization or authority or system for managing and persistently providing the discovery of urn -> resource mapping, or even merely confirming that a purported URN -> resource mapping might be correct. 

I see no point in obsoleting urn:uuid, since it is widely used in deployed software (as is uuid: without a urn: prefix, alas), but I'd like to encourage those proposing future URN namespaces to avoid systems without an active authority or method.  Of course, uniqueness of the URN strings is necessary for providing reliable discovery or validation.

Larry

From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael A Dolan
Sent: Friday, September 09, 2011 6:34 PM
To: [email-masked]
Subject: Re: [urn] the UUID namespace

I should add that UUID's are used widely to number media assets and are thus a namespace and are thus appropriate for a URN encoding.

There are different forms for constructing UUIDs.  Some are guaranteed to be unique as they are based on the IEEE MAC address namespace. Some are "statistically unique".

                Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Friday, September 09, 2011 10:28 AM
To: Peter Saint-Andre
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [urn] the UUID namespace

On Fri, Sep 9, 2011 at 10:09 AM, Peter Saint-Andre <[email-masked]> wrote:
I like UUIDs, for the reasons described in RFC 4122:

So, I think you're mixing mechanism and desire effect.  The desired effect is that URNs be unique across space and time.  The formal management mechanisms are there to guarantee this property and to bind the resulting identifier to a resource.  RFC 4122 says:
If any of the algorithms mentioned can be shown not to guarantee uniqueness, then I believe it should be removed by publication of a successor document.  If we are convinced that *no* algorithmic method can be used that generates uniqueness, then perhaps a shift to a URI scheme (for which no such guarantees are available) is appropriate.  But I'm not hearing that in your argument.  Is there a credible risk that UUID URNs are not unique?

regards,

Ted

Thoughts?

Peter

--
Peter Saint-Andre
https://stpeter.im/