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/
- [urn] the UUID namespace Peter Saint-Andre
- Re: [urn] the UUID namespace Ted Hardie
- Re: [urn] the UUID namespace Peter Saint-Andre
- Re: [urn] the UUID namespace Ted Hardie
- Re: [urn] the UUID namespace Peter Saint-Andre
- Re: [urn] the UUID namespace Martin J. Dürst
- Re: [urn] the UUID namespace Peter Saint-Andre
- Re: [urn] the UUID namespace Juha Hakala
- Re: [urn] the UUID namespace Michael A Dolan
- Re: [urn] the UUID namespace Michael A Dolan
- Re: [urn] the UUID namespace Larry Masinter