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

Julian Reschke <> Wed, 09 January 2013 15:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93D7A21F8698 for <>; Wed, 9 Jan 2013 07:49:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.832
X-Spam-Status: No, score=-103.832 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tkVRJwtkHOK0 for <>; Wed, 9 Jan 2013 07:49:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 242AE21F84F3 for <>; Wed, 9 Jan 2013 07:49:01 -0800 (PST)
Received: from ([]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MfTAj-1TdtzT1LP1-00P9yG for <>; Wed, 09 Jan 2013 16:49:00 +0100
Received: (qmail invoked by alias); 09 Jan 2013 15:49:00 -0000
Received: from (EHLO []) [] by (mp034) with SMTP; 09 Jan 2013 16:49:00 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+Df+RPO0mDVy3xRg7+GEbNkYNsxj9vlg0m7Cg0B3 5QklwqFOOYV6zk
Message-ID: <>
Date: Wed, 09 Jan 2013 16:48:56 +0100
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Keith Moore <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
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: Wed, 09 Jan 2013 15:49:02 -0000

On 2013-01-09 05:27, Keith Moore wrote:
> On 01/07/2013 01:35 PM, Peter Saint-Andre wrote:
>> Hash: SHA1
>> Old thread alert!
>> On 8/17/12 1: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.
> Whether something works well in practice, and whether something conforms
> to the intent of a standard, are of course two separate questions.
> Again, URNs were designed to identify resources.   If people use them
> for other things, that's not a problem so long as such use doesn't
> degrade the intended utility of URNs.   It's not like the protocol
> police are going to chase down the users of UUID URNs and put them in
> jail if those UUIDs weren't chosen to refer to resources.  And of course
> you can't tell by looking what is named by a URN  - and that is a
> feature, not a bug.
> But just because people find uses for URNs that weren't intended,
> doesn't mean that the URN standard should be changed to encompass those
> uses.  This _would_ degrade the utility of URNs.
> To be clear, there's nothing in principle wrong with a UUID URN. What's
> wrong is using a UUID URN just because what you need is a unique
> identifier that doesn't refer to a resource, and you want that unique ID
> to be some sort of URI.   Yes, it probably does little harm most of the
> time, but it's still not a good idea to promote the practice.
> ...

"This specification does not limit the scope of what might be a 
resource; rather, the term "resource" is used in a general sense for 
whatever might be identified by a URI." -- 

Case closed.

Best regards, Julian (ducks)