Re: [urn] I-D Action: draft-saintandre-urn-example-00

Keith Moore <> Fri, 17 August 2012 11:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B8F721F857D for <>; Fri, 17 Aug 2012 04:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.166
X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nDUOcOeYkVdS for <>; Fri, 17 Aug 2012 04:57:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 69E0821F8575 for <>; Fri, 17 Aug 2012 04:57:43 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.mail.srv.osa []) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BA2E320731; Fri, 17 Aug 2012 07:57:42 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([]) by compute1.internal (MEProxy); Fri, 17 Aug 2012 07:57:42 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=ksAa2vn8lXBVicCdfz8WvH kSyiA=; b=AU4X/gS5YgGfD/wrFFeYDY03MvI93PYdP93NzqFX4kV0nekM1rYGU9 eTit4XFcPPNhShE0qT7DuVC/9BeDG/droVAbDQsNHUD8kk7oUAHRzynf481zZUJf TY75uP3eCuTsUfwend+U6DbtkLjDnRYjBbEnT8U4Q7pJEkZA6JzbE=
X-Sasl-enc: XmogI6h2IZrl+NEUB/pHHLcMINuOos901dzfVMT85FP/ 1345204661
Received: from [] (unknown []) by (Postfix) with ESMTPA id 09CD48E0111; Fri, 17 Aug 2012 07:57:40 -0400 (EDT)
Message-ID: <>
Date: Fri, 17 Aug 2012 07:57:36 -0400
From: Keith Moore <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Julian Reschke <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Aug 2012 11:57:44 -0000

On 08/17/2012 03:27 AM, Julian Reschke wrote:
> On 2012-08-16 23:01, Alfred � wrote:
>> (no hat)
>> On 08/16/2012, Keith Moore wrote:
>>> On 08/14/2012 09:59 AM, Andy Newton wrote:
>>>> Given that URNs are suppose to have permanence or persistence or
>>>> whatever we are calling it today and a resolution mechanism, this
>>>> desire to shoehorn identifiers that need to qualify as a URI into the
>>>> URN system might be wrong. An identifier that must be a URI does not
>>>> necessarily need or have all the properties to be a URN. Just an
>>>> observation.
>>> +1
>>> URNs were intended to be _resource names_, i.e. names of resources
>>> rather than merely unique identifiers.  The expectation was that such
>>> resources would generally be at least potentially accessible over the
>>> network, and that it would be possible to resolve such names to 
>>> resource
>>> locations.   Everyone agreed that it should be possible to assign URNs
>>> to resources that were not resolvable, or at least not resolvable for
>>> the time being.  But the idea that URNs are appropriate for use 
>>> whenever
>>> someone needed a unique non-resolvable identifier that qualifies as a
>>> URI, always has struck me as bizarre and contrary to the intended
>>> purpose of URNs.
>>> Keith
>> +1 (for both statements)
> For the record: -1-
> urn:uuid: is used a lot in practice, and I simply don't see a 
> practical problem with it.
> Are you saying these shouldn't be URIs in the first place, or that a 
> separate URI scheme would have been ok (in which case those would be 
> URNs as well, just not using the "URN" URI scheme, no?).

I don't actually have a problem with UUID URNs in principle, so long as 
the mechanisms used to generate UUIDs actually ensure that they're 
unique. (If memory serves, they do, but it's been awhile since I've read 
the spec).   As long as people use UUID URNs to refer to resources, such 
usage is perfectly consistent with the intended purpose of URNs.  And I 
certainly am not suggesting that UUID URNs be deprecated, or any thing 
similarly disruptive.

The problem I have is with the idea that has emerged that if you need an 
ID that happens to be a URI, a URN is the right thing to use.   I've 
seen a lot of things labeled "urn:" that didn't refer to resources, or 
worse, weren't unique at all, apparently because of this idea.