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

Michael Mealling <michael@refactored-networks.com> Wed, 09 January 2013 16:19 UTC

Return-Path: <michael@refactored-networks.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 A423721F87E7 for <urn@ietfa.amsl.com>; Wed, 9 Jan 2013 08:19:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 1n9IayDZ-t4H for <urn@ietfa.amsl.com>; Wed, 9 Jan 2013 08:19:37 -0800 (PST)
Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id D928521F87E3 for <urn@ietf.org>; Wed, 9 Jan 2013 08:19:36 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 50B29390095; Wed, 9 Jan 2013 10:19:36 -0600 (CST)
X-Virus-Scanned: amavisd-new at smtp-out-2.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwbGunHBlngz; Wed, 9 Jan 2013 10:19:36 -0600 (CST)
Received: from smtp.01.com (localhost.localdomain [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 1DAF73900BD; Wed, 9 Jan 2013 10:19:36 -0600 (CST)
Received: from [10.136.79.33] (unknown [65.50.0.4]) by smtp-out-2.01.com (Postfix) with ESMTPSA id E19003900B7; Wed, 9 Jan 2013 10:19:35 -0600 (CST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Michael Mealling <michael@refactored-networks.com>
In-Reply-To: <50ED952C.8080704@network-heretics.com>
Date: Wed, 9 Jan 2013 11:19:32 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <F21A7F7F-4221-43D7-B672-5315F183E55E@refactored-networks.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>
To: Keith Moore <moore@network-heretics.com>
X-Mailer: Apple Mail (2.1499)
Cc: Julian Reschke <julian.reschke@gmx.de>, 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: Wed, 09 Jan 2013 16:19:37 -0000

Is it really 1999 all over again? Maybe I should by come CMGI stock.

With a couple of noted exceptions this is one area where the W3C and the IETF's URN group agreed: That the definition of 'resource'  is the thing identified by a URI. That minting any URI immediately causes its resource to come into being in the abstract. Some URI scheme specifications can restrict that it limits resource to be sequences of bits on a network but that is a limitation of that particular URI. We never set that limit for URNs. In other words, the rough consensus from back then was Julian is right, that ALL URIs identify 'resources' by definition. Merely being identified by a URI _makes_ it a resource.

wow… that made me feel ten years younger! ;-)

-MM





On Jan 9, 2013, at 11:05 AM, Keith Moore <moore@network-heretics.com> wrote:

> On 01/09/2013 11:00 AM, Julian Reschke wrote:
>>>> "This specification does not limit the scope of what might be a
>>>> resource; rather, the term "resource" is used in a general sense for
>>>> whatever might be identified by a URI." --
>>>> <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.1.1>
>>>> 
>>>> Case closed.
>>> yes, but it didn't anticipate that URNs would be widely used to not name
>>> resources at all.
>>> 
>>> again, most such uses do little harm.  but that's not an argument for
>>> perverting URNs to be just
>>> random numbers instead of resource identifiers.
>>> ...
>> 
>> My point being: they *are* resource identifiers.
> Only if they actually identify resources.
> 
> Keith
> 
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn