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

Julian Reschke <julian.reschke@gmx.de> Fri, 17 August 2012 07:27 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 3FE9721F852B for <urn@ietfa.amsl.com>; Fri, 17 Aug 2012 00:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.74
X-Spam-Level:
X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[AWL=-2.441, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 QZGA1sWwsQvx for <urn@ietfa.amsl.com>; Fri, 17 Aug 2012 00:27:45 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 53B7A21F851C for <urn@ietf.org>; Fri, 17 Aug 2012 00:27:45 -0700 (PDT)
Received: (qmail invoked by alias); 17 Aug 2012 07:27:43 -0000
Received: from p54BB2EC5.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.46.197] by mail.gmx.net (mp024) with SMTP; 17 Aug 2012 09:27:43 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+9JYtEWhS99XG8cdQ9DVm0rlXhGFsIkRIVBsX2vk 6iYF1/VSFPee1d
Message-ID: <502DF26E.3050406@gmx.de>
Date: Fri, 17 Aug 2012 09:27:42 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= <ah@TR-Sys.de>
References: <201208162101.XAA08756@TR-Sys.de>
In-Reply-To: <201208162101.XAA08756@TR-Sys.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: urn@ietf.org, moore@network-heretics.com
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: Fri, 17 Aug 2012 07:27:46 -0000

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 already have responded similarly to the seminal email wrt this topic
> (by Julian) that has motivated the creation this I-D (by PSA).
>
> The above notes seem to be properly backed the following excerpts
> from RFC 1737, "Requirements for Uniform Resource Names",
> Section 2, "Requirements for functional capabilities":
>
> |      ...
> |      It is intended that the lifetime of a URN be permanent.
> |      ...
> |
> |      URNs can be assigned to any resource that might conceivably
> |      be available on the network, for hundreds of years.
> |      ...
>
> IMO, the concepts of "example URNs" and "testing URNs" seem to be
> fundamentally incompatible with these requirements.  For the latter,
> rapid software development for testing of namespace management and
> resolution systems can be furthered by "early reservation/assignment"
> of URN Namespace IDs by IANA (as soon as urn-nid mailing list and
> expert review "thumbs up" is obtained for a new URN Namespace proposal.

The use case for reserved example URNs are specifications. It's much 
better if people use one reserved for this purpose than making up 
invalid ones (and that's what started this discussion).

Best regards, Julian