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

Keith Moore <moore@network-heretics.com> Tue, 12 February 2013 15:41 UTC

Return-Path: <moore@network-heretics.com>
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 79F5B21F8EE1 for <urn@ietfa.amsl.com>; Tue, 12 Feb 2013 07:41:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.073
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANnlNwM5ojIi for <urn@ietfa.amsl.com>; Tue, 12 Feb 2013 07:41:26 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 67AEF21F8EDB for <urn@ietf.org>; Tue, 12 Feb 2013 07:41:26 -0800 (PST)
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) 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 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 12 Feb 2013 10:41:25 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; 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 [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 704714827D7; Tue, 12 Feb 2013 10:41:24 -0500 (EST)
Message-ID: <511A629F.1080600@network-heretics.com>
Date: Tue, 12 Feb 2013 10:41:19 -0500
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Larry Masinter <masinter@adobe.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> <50ED9430.4040606@gmx.de> <50ED952C.8080704@network-heretics.com> <F21A7F7F-4221-43D7-B672-5315F183E55E@refactored-networks.com> <50ED9B48.7020604@network-heretics.com> <50ED9DD9.5030303@gmx.de> <50EDA00C.6080401@network-heretics.com> <C68CB012D9182D408CED7B884F441D4D1E3FF999D6@nambxv01a.corp.adobe.com> <50FCC1E1.3040803@network-heretics.com> <C68CB012D9182D408CED7B884F441D4D1E40319275@nambxv01a.corp.adobe.com>
In-Reply-To: <C68CB012D9182D408CED7B884F441D4D1E40319275@nambxv01a.corp.adobe.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "urn@ietf.org" <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: 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.
> http://www.ietf.org/rfc/rfc1737.txt 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.

Keith