Re: [urn] call for comments: an alternative 2141bis document

Peter Saint-Andre <stpeter@stpeter.im> Thu, 21 February 2013 03:51 UTC

Return-Path: <stpeter@stpeter.im>
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 B4B9121F8899 for <urn@ietfa.amsl.com>; Wed, 20 Feb 2013 19:51:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.593
X-Spam-Level:
X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 lttv4AtFfM4F for <urn@ietfa.amsl.com>; Wed, 20 Feb 2013 19:51:12 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B6DFB21F8BE0 for <urn@ietf.org>; Wed, 20 Feb 2013 19:51:11 -0800 (PST)
Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CA395403CD; Wed, 20 Feb 2013 20:58:40 -0700 (MST)
Message-ID: <512599AB.3040303@stpeter.im>
Date: Wed, 20 Feb 2013 20:51:07 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Keith Moore <moore@network-heretics.com>
References: <CAAQiQRe+wCBmKfm7up8XY-4RxLnktZiz+nuanprygGcHAYdqAw@mail.gmail.com> <C68CB012D9182D408CED7B884F441D4D1E36EF2DC4@nambxv01a.corp.adobe.com> <F97E15A0-480C-414B-A4E4-A8F5C2037153@semanticidentity.com> <C68CB012D9182D408CED7B884F441D4D1E3702754D@nambxv01a.corp.adobe.com> <CA+9kkMDnKYU9oJN_xMQ8RA5A_0fAz5W=U_J6N0J5Wan4RwXVuw@mail.gmail.com> <C68CB012D9182D408CED7B884F441D4D1E37027BC9@nambxv01a.corp.adobe.com> <CA+9kkMAhRF0K1+APV=XH3TbxBLGw8sGX6uhgbYRShbS-OabBnw@mail.gmail.com> <51244D4D.3030302@stpeter.im> <51246277.1010604@network-heretics.com>
In-Reply-To: <51246277.1010604@network-heretics.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] call for comments: an alternative 2141bis document
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: Thu, 21 Feb 2013 03:51:13 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/19/13 10:43 PM, Keith Moore wrote:
> On 02/19/2013 11:13 PM, Peter Saint-Andre wrote:
>> 
>> Agreed.
>> 
>> And to Larry's original point, RFC 2141 says only that URNs) are 
>> *intended* to serve as persistent, location-independent resource 
>> identifiers. It doesn't guarantee that those intentions will be 
>> achieved in reality.
>> 
>> Here's my interpretation (which doesn't necessarily take into
>> account the history of discussion on this topic because I wasn't
>> involved back then and I lack the full context that Larry, Ted,
>> Leslie, et al. possess):
>> 
>> 1. Persistent doesn't mean permanent (since nothing is
>> permanent), it only means long-lived (or longer-lived than a
>> location-dependent identifier).
> Actually the binding between a URN and the resource, once assigned,
> was indeed intended to be permanent.  That doesn't mean that the
> resource is permanently accessible (or ever accessible).   And it
> was always understood that the resource could change (in the sense
> of being replaced with a later version of the same thing).   But
> the URN should never be reassigned to a resource that is
> inconsistent with the original binding.
> 
>> 2. Location-independent means the resource is not tied to a
>> particular path at a particular DNS domain name via a particular
>> access method.
> 
> It means all of that and more.   For example, it also means that
> the meaning of the URN is the same from every location in the
> network.
>> IMHO, persistence and location-independence are closely
>> intertwined.
> 
> Yes, location-independence is a necessary condition for
> persistence.
>> I also think that it's good to have identifiers that are closer
>> to being persistent and location-independent (or farther from
>> being ephemeral and location-dependent), and I think that URNs as
>> defined in the existing specs fit the bill. All we're trying to
>> do here is modernize the definitions a bit to bring them in line
>> with RFC 3986, RFC 5226, etc.
> 
> Of course I realize that no protocol specification can force any 
> particular URN to be either persistent or location-independent 
> forever.   But that's not a justification to revise the URN 
> specifications to dilute the intent of URNs.

Agreed on all points.

I'm not yet sure how best to capture some of this in the spec, but
I'll give it some thought and try to return with some proposed text.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRJZmrAAoJEOoGpJErxa2paE4P/RrX8uvlFOLGThbM/zZCIFD2
zEi9nNlozFY0+YLEFnqhcQUTxszVDxpyOuDcfjk6zmfZXvGGx4BVdNnG30nCy74e
JXCKPiHaoq4ibn0KyS+SPPSxqgqF4iqGX2kPfYY0yxXCW4VEUP9utnDCNaedYPzh
8pn5NRnM1sGoBzbHQBTqHoyEAzMMf9U8FpP3JRPVbtf6a3PBoJwmF99sDStuaYAD
MMJLEc3kPINBu8wOgE5aLDFiwOfYbeulJqeD/JUwHeT5CN3JoLysUn2dX+CjS3st
6NAZpGbiJ/onMUeSbN+CDFU+d2jsEKbsTGA8C1M1tXfKWHiwBOVKntyt3DWcNu2e
H2JfnDhMpA0panmqDoe02nR3kGdm6+h+7jYaJ5mbBUY+CGxJ4kc4gqlHCbYU7Hh0
pLGlzib//Q/iWFjW3pA8i9FmqxAswFjNZphXdnIAmKnJfa6lmEETbW+GyPI4+9yi
yovtMsNWf0g/FlxSzNr7YPfYX2a2fOF+uWx4QaHcrFRfPsBZMU55oORvguK7Q2Ux
YenSkV0DKIwcRqX15Mbo34ECGKp/JSNcaFq8aHFZQIXGw9x/NXviwcn26KEbaT3Q
qbMptMrP+TJ6/eWxb3rkXkLcqruxga2LiNdE2b0MNr90V41Si9VSQFzZzt+TiHUu
V66anAq2jLB6oefeUg/o
=mfiT
-----END PGP SIGNATURE-----