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

Keith Moore <> Wed, 20 February 2013 05:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13C7D21F86FC for <>; Tue, 19 Feb 2013 21:43:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.402
X-Spam-Status: No, score=-3.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UAbS02IBHaek for <>; Tue, 19 Feb 2013 21:43:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 78B8F21F86FB for <>; Tue, 19 Feb 2013 21:43:24 -0800 (PST)
Received: from compute1.internal (compute1.nyi.mail.srv.osa []) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C63E720E83; Wed, 20 Feb 2013 00:43:23 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([]) by compute1.internal (MEProxy); Wed, 20 Feb 2013 00:43:23 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=UYNrwIhPOiSJQi0jCa18Ir 8yXvA=; b=aZPhGZjxFTEL25b00LhsNIUvVXkIyDriCpsNvAbr1Xnkv1HKR8h3kr Z71dnDHZVQwszChjNPNpOjsjcb0HU3ulssE3UsqnClYUeNLES7CM2glwtTKQdL5h IDGYFlcGOEVF6SilDweHZspzxzm0yWAyij2qb3yjXvwHns9lbva4c=
X-Sasl-enc: S6JrbEN9eJUkM9atcJYRTZuuSKWYB7mFaxecGoscMArB 1361339003
Received: from [] (unknown []) by (Postfix) with ESMTPA id AFC0A482635; Wed, 20 Feb 2013 00:43:22 -0500 (EST)
Message-ID: <>
Date: Wed, 20 Feb 2013 00:43:19 -0500
From: Keith Moore <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Peter Saint-Andre <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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: Wed, 20 Feb 2013 05:43:26 -0000

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