Re: [urn] the UUID namespace

Peter Saint-Andre <stpeter@stpeter.im> Fri, 09 September 2011 17:51 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3191C21F849D for <urn@ietfa.amsl.com>; Fri, 9 Sep 2011 10:51:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.543
X-Spam-Level:
X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7PZgCRTzG3S for <urn@ietfa.amsl.com>; Fri, 9 Sep 2011 10:51:46 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CA72221F8562 for <urn@ietf.org>; Fri, 9 Sep 2011 10:51:45 -0700 (PDT)
Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6ACFD4195A; Fri, 9 Sep 2011 11:56:43 -0600 (MDT)
Message-ID: <4E6A52A3.1020405@stpeter.im>
Date: Fri, 09 Sep 2011 11:53:39 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Ted Hardie <ted.ietf@gmail.com>
References: <4E6A483F.6010001@stpeter.im> <CA+9kkMANG22L0qfWJPqqS1jZBGpX-udVFkMGJSDsT_C_c6RV3Q@mail.gmail.com>
In-Reply-To: <CA+9kkMANG22L0qfWJPqqS1jZBGpX-udVFkMGJSDsT_C_c6RV3Q@mail.gmail.com>
X-Enigmail-Version: 1.3.1
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: rsalz@datapower.com, paulle@microsoft.com, "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] the UUID namespace
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Sep 2011 17:51:49 -0000

On 9/9/11 11:27 AM, Ted Hardie wrote:
> 
> On Fri, Sep 9, 2011 at 10:09 AM, Peter Saint-Andre <stpeter@stpeter.im
> <mailto:stpeter@stpeter.im>> wrote:
> 
>     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:
> 
> 
> 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?

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

Peter

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