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

Ted Hardie <> Mon, 26 November 2012 15:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 551E021F85C2 for <>; Mon, 26 Nov 2012 07:47:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.544
X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, GB_I_LETTER=-2, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IX4sP8teUiex for <>; Mon, 26 Nov 2012 07:47:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7E2EF21F85A6 for <>; Mon, 26 Nov 2012 07:47:24 -0800 (PST)
Received: by with SMTP id b25so8743515qca.31 for <>; Mon, 26 Nov 2012 07:47:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hrOC9OXYLfTMG+gL6Q5UehYojI9DEZ6PpnJpV8yenC0=; b=oPQacsQvIoI1gVZQAf258hDstPTB1gNMtWUMsDljYrZ9IUD9gIlgii9aaxVFkBrarE hH0QKR3YNag425N+8RdW0osuSg+QV7pvWpOOkgSIomhNANr+VvnljE0GTqPbouHjCOQ8 ChFIMNBv5tK13Y62WfJxH1OkDJmw6AAIxJwalakWdpmdGPI5C4TSj4GxB3CkT2RRQWix 9fHcrlQa0Ie0ZXz+XiWmEbbhDl59acGq72oXZ5K8BhrwWliXKsO73Q2kiw690KZ1F4N1 UI97FL/7eUQZbJ2umLKHaykWgTFq2whoUp9ZIezMFMVb7EnHk1OuIEMDpM7rHgsiDh2b 0r1w==
MIME-Version: 1.0
Received: by with SMTP id w3mr4230534qeu.22.1353944844017; Mon, 26 Nov 2012 07:47:24 -0800 (PST)
Received: by with HTTP; Mon, 26 Nov 2012 07:47:23 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Mon, 26 Nov 2012 07:47:23 -0800
Message-ID: <>
From: Ted Hardie <>
To: Larry Masinter <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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: Mon, 26 Nov 2012 15:47:25 -0000

On Sun, Nov 25, 2012 at 4:47 AM, Larry Masinter <> wrote:
> I'm not sure how useful it is to "capture the answer to the question:  will this identifier ever by reassigned in the  normal course of business?"
> I think the question was "why bother with the extra four 'urn:' letters, rather than just invent a new scheme?" and it's as useful to say that about  blah:stuff as it is about  urn:blah:stuff, and if you are handed a URL of the form "urn:blah:stuff" where you know nothing about "blah", you have no more information than you would have given "blah:stuff".

If you mean, could the group have made "This is guaranteed not to
change, for some value of guaranteed" part of the meta-data in the
registration, rather than something signaled in the URI string, sure.
But as I'm sure you remember, there were visions at the time of using
a different resolution service to find instances of the
thing-that-a-urn-represents; had that turned out to be a common
resolution mechanism, then having a common signal to use it makes
sense.  That's not quite the language in RFC 2276, but I think the
presumption of an RDS was a driver for using a unique string.

Is it worth changing now, and converting existing URNs?  Certainly
not, as that would violate the principle they were built under.  Could
you now build a URI that had the same characteristics as a URN, but
did not use the string?  Yep.  The IESG historically would have asked
you "why isn't this a URN?", but since we're making registration
highly permissive, I'm not sure that they would really need an answer.

> (blah = uuid & stuff cryptographically securely randomly generated or not).
> I think you will have trouble defining "reassigned" and "normal course of business"...
> During the normal course of business http://host/path  always means
>    >>> talk to the host named "host", using whatever protocol is currently meant by "http", asking for "/path" <<<<
> You probably mean something else by "reassigned", but there's a devil in the details of what it means in operational terms that make sense.

I mean "the registration authority, the laws of physics, or some
mathematical principle state that if I have associated *this* URN with
*that* resource, it will never be associated with a different resource
during the likely lifetime of our civilization".  DNS names are
re-assigned far more frequently than that.



> The theory I'm working on links persistence to meaning, in that, within a communication from Alice, through a repository R, to Bob,
> that includes a URL/URI/URN/IRI
> A --- U ---> R
> R --- U -->  B
> Where the two transactions are time-offset, that the intention of meaning by A for U is tied directly to the expected persistent behavior of B when interpreting U.
>> -----Original Message-----
>> From: Ted Hardie []
>> Sent: Monday, November 19, 2012 8:39 AM
>> To: Larry Masinter
>> Cc: Renato Iannella;
>> Subject: Re: [urn] call for comments: an alternative 2141bis document
>> On Mon, Nov 19, 2012 at 1:58 AM, Larry Masinter <>
>> wrote:
>> >> Hi we all know, it is impossible to say that _anything_ will be
>> >> persistent (even beyond our lifetimes) in this industry.
>> While I agree that there is no way to say that anything aiming to be
>> persistent will succeed, I do think it is useful to capture the answer
>> to the question:  will this identifier ever by reassigned in the
>> normal course of business?  There are lots of reasons why you can be
>> wrong in the answer you give, but the answer is useful.
>> This is also, oddly enough, why I think UUID URNs are just fine, even
>> though they do not have an organizational guarantee--the cryptographic
>> guarantee they provide is at least as good as the typical
>> human-managed system.  So I can look at one in a system and understand
>> that it is meant to be unique.
>> Just my personal view, of course,
>> Ted