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

Keith Moore <moore@network-heretics.com> Mon, 21 January 2013 04:19 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 32D8C21F8629 for <urn@ietfa.amsl.com>; Sun, 20 Jan 2013 20:19:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[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 Hwu3ktAAVFv6 for <urn@ietfa.amsl.com>; Sun, 20 Jan 2013 20:19:46 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 2E59B21F8457 for <urn@ietf.org>; Sun, 20 Jan 2013 20:19:43 -0800 (PST)
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 667092089F for <urn@ietf.org>; Sun, 20 Jan 2013 23:19:42 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 20 Jan 2013 23:19:42 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=mxyk0Ck39PP3Qbpx/ovR+Q QY/F0=; b=c8C17+2i624GZBUGykPpww8KZcm+NCKYtiog06JKJYV3y23o5P9UCY QCdkc1Yp6l6xaA/Cn2wATALrRRfXwsdX8I/MwWaOqpX2mU+2QMrEasPGDEYA3H3V RYkzqe17E5+r8eSPImG/LHhRsKhqyUG8WKUVB9cqZwjer6H1jNGbQ=
X-Sasl-enc: Zcmd11+K3GEDYAsx1UEe+72bicUqmd4axSYGiBAxG1SA 1358741981
Received: from [172.19.131.95] (unknown [12.130.123.132]) by mail.messagingengine.com (Postfix) with ESMTPA id 5DF1D48279B; Sun, 20 Jan 2013 23:19:41 -0500 (EST)
Message-ID: <50FCC1E1.3040803@network-heretics.com>
Date: Sun, 20 Jan 2013 23:19:45 -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: urn@ietf.org
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>
In-Reply-To: <C68CB012D9182D408CED7B884F441D4D1E3FF999D6@nambxv01a.corp.adobe.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Mon, 21 Jan 2013 04:19:47 -0000

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

Keith