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

Julian Reschke <julian.reschke@gmx.de> Wed, 09 January 2013 15:49 UTC

Return-Path: <julian.reschke@gmx.de>
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 93D7A21F8698 for <urn@ietfa.amsl.com>; Wed, 9 Jan 2013 07:49:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.832
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkVRJwtkHOK0 for <urn@ietfa.amsl.com>; Wed, 9 Jan 2013 07:49:01 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 242AE21F84F3 for <urn@ietf.org>; Wed, 9 Jan 2013 07:49:01 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MfTAj-1TdtzT1LP1-00P9yG for <urn@ietf.org>; Wed, 09 Jan 2013 16:49:00 +0100
Received: (qmail invoked by alias); 09 Jan 2013 15:49:00 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.104]) [217.91.35.233] by mail.gmx.net (mp034) with SMTP; 09 Jan 2013 16:49:00 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+Df+RPO0mDVy3xRg7+GEbNkYNsxj9vlg0m7Cg0B3 5QklwqFOOYV6zk
Message-ID: <50ED9168.6050000@gmx.de>
Date: Wed, 09 Jan 2013 16:48:56 +0100
From: Julian Reschke <julian.reschke@gmx.de>
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 <moore@network-heretics.com>
References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> <50ECF1CC.6030208@network-heretics.com>
In-Reply-To: <50ECF1CC.6030208@network-heretics.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: urn@ietf.org
Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <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: 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:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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." -- 
<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.1.1>

Case closed.

Best regards, Julian (ducks)