Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
John C Klensin <john-ietf@jck.com> Tue, 15 April 2014 18:21 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0751A069A; Tue, 15 Apr 2014 11:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.283
X-Spam-Level: **
X-Spam-Status: No, score=2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pK0fjsPAjua4; Tue, 15 Apr 2014 11:20:57 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 938DB1A069C; Tue, 15 Apr 2014 11:20:57 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1Wa7S6-0007Dt-Hf; Tue, 15 Apr 2014 13:47:22 -0400
Date: Tue, 15 Apr 2014 13:47:22 -0400
From: John C Klensin <john-ietf@jck.com>
To: Larry Masinter <masinter@adobe.com>, Graham Klyne <GK@ninebynine.org>
Message-ID: <952E89C207E59D25CD5953D6@JCK-EEE10>
In-Reply-To: <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com>
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Q47JfQBfEeemOgHEOPf8GP_ZNLA
Cc: julian.reschke@gmx.de, urn@ietf.org, apps-discuss@ietf.org
Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 15 Apr 2014 18:21:02 -0000
Hi. Just wanted to tell folks that I'm on a very poor connection (if on at all) for the next couple of days and probably won't be able to give careful answers until Thursday and probably should not try. But one very quick observation in response to part of Larry's note... --On Tuesday, 15 April, 2014 16:25 +0000 Larry Masinter <masinter@adobe.com> wrote: > The only thing that makes something a name 'persistsent' is > the existence of a name resolution service or method which > persists. The syntax or namespace is irrelevant. 'persistent' > isn't binary, it's just "how long". Everything has a life-time. > > http://masinter.blogspot.com/2010/03/ozymandias-uri.html I think the above largely misses the point and that, in a sense, your blog posting illustrates the point although not in the way you probably intend. "Persistent identifier" entered the IETF vocabulary a long time ago but may not be very look terminology. Some objects -- like stone statues if one doesn't care whether they remain intact and standing-- have very long life expectancies. Others, like people, have shorter ones. But URIs (with or within including URNs) aren't objects, they are object reference that, like most good references, involve some degree of abstraction. Now, "Ozymandias" is a very long-persistent reference. It isn't the object. It is a somewhat ambiguous reference because it can refer to the statue, the poem, your blog posting, and probably several other things, but has a long duration, perhaps one that is long enough to survive the objects it references (just like titles of long-lost books). But, as a reference, it is that persistent because it is not bound to a retrieval mechanism that has its own persistence properties. Whatever its other properties, http://masinter.blogspot.com/2010/03/ozymandias-uri.html is lousy as a persistent identifier. It depends on the availability of "http" (or something called that) as a retrieval mechanism. It depends on there being a DNS, on there being a TLD named "com" an SLD named "blogspot", and both of them having certain properties of which HTTP can take advantage. "Ozymandias", and even the potential URN urn:poems:Shelley/Ozymandias are more persistent because they represent a higher level of abstraction and are not tied to either a location or a retrieval/access method. Use of a hypothetical ISPN (International Standard Poem Identifier) in the form urn:ispn:NNNN-NNNNNN-NNNNNNNNNNNNNNNNNNNN might or might not be more persistent: it would be an exact identifier of something and makes equivalence comparison more feasible and less ambiguous, but it is probably tied to a database to actually identify an object and such databases may be more or less available and persistent than access methods and/or the DNS (which is, after all, just another database). Regardless of what one calls them, I suggest that access-method-dependent identifiers (http:..., NineTrackTape:??42.3744°?N,?71.1169°?W?123456 (where "?" represents one or more carefully-chosen delimiters that may not have RFC 3986 semantics), ...) are different kinds of creatures than either the objects to which they refer or names of those objects that are not, in the sense of the above, method or location-model dependent. More soon. john
- [urn] URNs are not URIs (another look at RFC 3986) John C Klensin
- Re: [urn] URNs are not URIs (another look at RFC … Julian Reschke
- Re: [urn] URNs are not URIs (another look at RFC … John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Martin J. Dürst
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Graham Klyne
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Graham Klyne
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Larry Masinter
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Julian Reschke
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Nico Williams
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Julian Reschke
- Re: [urn] URNs are not URIs (another look at RFC … Dale R. Worley
- Re: [urn] URNs are not URIs (another look at RFC … Dale R. Worley
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Nico Williams
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Mark Nottingham
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Graham Klyne
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Scott Brim
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Mark Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] URNs are not URIs (another look at RFC … John C Klensin
- Re: [urn] URNs are not URIs (another look at RFC … Barry Leiba
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Scott Brim
- Re: [urn] URNs are not URIs (another look at RFC … John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Nico Williams
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Nico Williams
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Barry Leiba
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Mark Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Martin J. Dürst
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Martin J. Dürst
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Larry Masinter
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Tony Finch
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Maurizio Lunghi
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- [urn] R: [apps-discuss] URNs are not URIs (anothe… Maurizio Lunghi
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Larry Masinter
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Edward Summers
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Dale R. Worley
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Dale R. Worley
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… jehakala
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Juha Hakala
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Svensson, Lars
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… SM
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… jehakala
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… SM
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Dale R. Worley
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Henry S. Thompson
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Henry S. Thompson