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

Julian Reschke <julian.reschke@gmx.de> Wed, 09 January 2013 16:01 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 2B08F21F87E3 for <urn@ietfa.amsl.com>; Wed, 9 Jan 2013 08:01:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.524
X-Spam-Level:
X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=-0.925, 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 CjWrpZE7K0C8 for <urn@ietfa.amsl.com>; Wed, 9 Jan 2013 08:00:59 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9783A21F87E0 for <urn@ietf.org>; Wed, 9 Jan 2013 08:00:51 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MT5po-1TS7Yi3QL0-00S4K2 for <urn@ietf.org>; Wed, 09 Jan 2013 17:00:50 +0100
Received: (qmail invoked by alias); 09 Jan 2013 16:00:50 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.104]) [217.91.35.233] by mail.gmx.net (mp028) with SMTP; 09 Jan 2013 17:00:50 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX188XLAPOac8tL42MJL1b0D2C55B+gYCkeZ4qvrbmZ V0RDJjTPk9UE9P
Message-ID: <50ED9430.4040606@gmx.de>
Date: Wed, 09 Jan 2013 17:00:48 +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> <50ED9168.6050000@gmx.de> <50ED93E2.9040002@network-heretics.com>
In-Reply-To: <50ED93E2.9040002@network-heretics.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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 16:01:00 -0000

On 2013-01-09 16:59, Keith Moore wrote:
> On 01/09/2013 10:48 AM, Julian Reschke wrote:
>>>>>
>>>>> 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.
> yes, but it didn't anticipate that URNs would be widely used to not name
> resources at all.
>
> again, most such uses do little harm.  but that's not an argument for
> perverting URNs to be just
> random numbers instead of resource identifiers.
> ...

My point being: they *are* resource identifiers.

Best regards, Julian