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

Peter Saint-Andre <> Thu, 21 February 2013 03:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4B9121F8899 for <>; Wed, 20 Feb 2013 19:51:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.593
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lttv4AtFfM4F for <>; Wed, 20 Feb 2013 19:51:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B6DFB21F8BE0 for <>; Wed, 20 Feb 2013 19:51:11 -0800 (PST)
Received: from [] (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id CA395403CD; Wed, 20 Feb 2013 20:58:40 -0700 (MST)
Message-ID: <>
Date: Wed, 20 Feb 2013 20:51:07 -0700
From: Peter Saint-Andre <>
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 <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [urn] call for comments: an alternative 2141bis document
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: Thu, 21 Feb 2013 03:51:13 -0000

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 Saint-Andre

Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird -