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

Peter Saint-Andre <> Mon, 07 January 2013 18:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2387C21F8994 for <>; Mon, 7 Jan 2013 10:35:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AwGPuXgcZqVi for <>; Mon, 7 Jan 2013 10:35:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4AEC621F882E for <>; Mon, 7 Jan 2013 10:35:06 -0800 (PST)
Received: from [] (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id CBAF8404EB for <>; Mon, 7 Jan 2013 11:40:10 -0700 (MST)
Message-ID: <>
Date: Mon, 07 Jan 2013 11:35:12 -0700
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="UTF-8"
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: Mon, 07 Jan 2013 18:35:08 -0000

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.
> 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).

Exactly. Just as we have reserved domain names for specifications (RFC
2606), I think it might be useful to have a reserved URN namespace ID
for specifications. I'd be happy to more carefully scope the
Internet-Draft to reflect that narrow focus.


- -- 
Peter Saint-Andre

Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with undefined -