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

Keith Moore <> Tue, 12 February 2013 15:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79F5B21F8EE1 for <>; Tue, 12 Feb 2013 07:41:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.073
X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ANnlNwM5ojIi for <>; Tue, 12 Feb 2013 07:41:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 67AEF21F8EDB for <>; Tue, 12 Feb 2013 07:41:26 -0800 (PST)
Received: from compute3.internal (compute3.nyi.mail.srv.osa []) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 710BF2070F; Tue, 12 Feb 2013 10:41:25 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([]) by compute3.internal (MEProxy); Tue, 12 Feb 2013 10:41:25 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=uK4zd6hRilpTjWtQzw1NNC 0agSA=; b=ncLtkd66PaK2bLeDe2MIHwJHVPYNAKZX1u/H/pnQVZ1cifne1hTBo1 JQB/F1NX7yDNN/zAvncDW//vN6GyJnapuBYs3AZDGXVlyErz9gaboYQgyjq6NRVL v2UjZ023+QrerccpS/or0ZkWBEhpE5w+Q+UUbSzIRaKvZ9t6OEGws=
X-Sasl-enc: zg057a88XGApma/X3lv3UMgiZM9UM+0uxQTpB53Ul/s2 1360683684
Received: from [] (unknown []) by (Postfix) with ESMTPA id 704714827D7; Tue, 12 Feb 2013 10:41:24 -0500 (EST)
Message-ID: <>
Date: Tue, 12 Feb 2013 10:41:19 -0500
From: Keith Moore <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Larry Masinter <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>
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: Tue, 12 Feb 2013 15:41:27 -0000

On 02/12/2013 10:34 AM, Larry Masinter wrote:
>> On 01/19/2013 11:27 AM, Larry Masinter wrote:
>>> For my part, the only way I can make peace with URNs is to take the
>> perspective that "persistence" is wishful thinking, that "resource" is a myth,
>> and that the primary use for URNs is a way of importing into the space of URIs
>> those identifiers that are maintained by other organizations (namely, the
>> "naming authority").
>> Which of course has nothing to do with the purpose of URNs.
> documents the purpose of URNs.
> The fifth bullet of section 2 "support of existing legacy naming systems".
> So "nothing to do with" is false. My point was that such uses are the
> primary use for URNs, and that URN namespaces that are not imports
> of other naming systems aren't as useful.

The purpose of URNs is and always was to provide location-independent, 
persistent names for network-accessible resources.  Where legacy naming 
systems provided similar facilities, the URN namespace was designed to 
accommodate them.   But this was not a "purpose" for URNs, it was merely 
a desirable trait.

And there's no reason to believe that "URN namespaces that are not 
imports of other naming systems aren't as useful".

>>> Of course, you should only use naming authorities who can offer a credible
>> promise of persistence of the association of the name to the thing named, but
>> each service makes its own guarantees. IETF offers that "STD 66" names
>> something, even if the document changes, and that "RFC 3986" names
>> something which is currently the same document. But that also what it names
>> is somewhat independent of the format it's set in, or the location.
>>> This description of URNs doesn't require anyone to believe in Resources or
>> that URNs Name them, or that they do so Uniformly.  It explains _most_ of the
>> URN namespaces.
>> No it doesn't.  it's just a mostly-coincidental characteristic of some URNs.
> which URN namespaces (besides uuid) does it not explain?
URNs are not defined by the characteristics you observe about them. URNs 
are defined by the relevant RFCs.
>>> The only problem is the darn urn:uuid: namespace, where "uuid" is not an
>> authority at all, and there's nowhere to turn to figure out who might have
>> known at any point in time what was meant by it. I don't know what to do with
>> urn:uuid except to declare it a mistake.
>> That might not be a bad idea, but not for the reason you cite.
>> To attempt to define what URNs are in terms of what you observe about
>> URNs is to attempt to destroy their utility.
> URNs are already defined, I'm not attempting to redefine them.
Yes, you are.
> I'm pointing out that the URN syntax and semantics is useful in some circumstances
> and not in others. If you're not importing someone else's naming system, don't bother
> with the extra four characters "urn:", just make a new URL scheme.
That's complete and utter BS.