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