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

Ted Hardie <ted.ietf@gmail.com> Mon, 26 November 2012 15:47 UTC

Return-Path: <ted.ietf@gmail.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 551E021F85C2 for <urn@ietfa.amsl.com>; Mon, 26 Nov 2012 07:47:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.544
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX4sP8teUiex for <urn@ietfa.amsl.com>; Mon, 26 Nov 2012 07:47:24 -0800 (PST)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2EF21F85A6 for <urn@ietf.org>; Mon, 26 Nov 2012 07:47:24 -0800 (PST)
Received: by mail-qc0-f172.google.com with SMTP id b25so8743515qca.31 for <urn@ietf.org>; Mon, 26 Nov 2012 07:47:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.49.71.163 with SMTP id w3mr4230534qeu.22.1353944844017; Mon, 26 Nov 2012 07:47:24 -0800 (PST)
Received: by 10.49.121.100 with HTTP; Mon, 26 Nov 2012 07:47:23 -0800 (PST)
In-Reply-To: <C68CB012D9182D408CED7B884F441D4D1E37027BC9@nambxv01a.corp.adobe.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>
Date: Mon, 26 Nov 2012 07:47:23 -0800
Message-ID: <CA+9kkMAhRF0K1+APV=XH3TbxBLGw8sGX6uhgbYRShbS-OabBnw@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Larry Masinter <masinter@adobe.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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: Mon, 26 Nov 2012 15:47:25 -0000

On Sun, Nov 25, 2012 at 4:47 AM, Larry Masinter <masinter@adobe.com> 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.

regards,

Ted

> 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 [mailto:ted.ietf@gmail.com]
>> Sent: Monday, November 19, 2012 8:39 AM
>> To: Larry Masinter
>> Cc: Renato Iannella; urn@ietf.org
>> Subject: Re: [urn] call for comments: an alternative 2141bis document
>>
>> On Mon, Nov 19, 2012 at 1:58 AM, Larry Masinter <masinter@adobe.com>
>> wrote:
>> >> Hi Larry....as 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