Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)

Maurizio Lunghi <Lunghi@rinascimento-digitale.it> Wed, 23 April 2014 10:05 UTC

Return-Path: <Lunghi@rinascimento-digitale.it>
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 860CB1A0191; Wed, 23 Apr 2014 03:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.615
X-Spam-Level: **
X-Spam-Status: No, score=2.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RDNS_DYNAMIC=0.982] 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 0Pv2wVcERpFg; Wed, 23 Apr 2014 03:05:14 -0700 (PDT)
Received: from remote.rinascimento-digitale.it (93-63-166-139.ip28.fastwebnet.it [93.63.166.139]) by ietfa.amsl.com (Postfix) with ESMTP id 33B911A019B; Wed, 23 Apr 2014 03:05:13 -0700 (PDT)
Received: from FRD01.frd.local ([fe80::30bc:ca96:e16f:8923]) by FRD01.frd.local ([fe80::30bc:ca96:e16f:8923%10]) with mapi id 14.03.0174.001; Wed, 23 Apr 2014 12:04:56 +0200
From: Maurizio Lunghi <Lunghi@rinascimento-digitale.it>
To: Phillip Hallam-Baker <hallam@gmail.com>
Thread-Topic: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
Thread-Index: AQHPXjWvNZcweYtOikiEcFO5n/xexZse+omz
Date: Wed, 23 Apr 2014 10:04:55 +0000
Message-ID: <80E9D81C-B469-4499-A7F2-983FBDE228A7@rinascimento-digitale.it>
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> <952E89C207E59D25CD5953D6@JCK-EEE10> <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net> <E0E032D69C38D6405A505541@JcK-HP8200.jck.com>, <CAMm+LwgowVh=+Sr8DST6=NeizkO9RsgePegrEFNsv2sXQaz=0g@mail.gmail.com>
In-Reply-To: <CAMm+LwgowVh=+Sr8DST6=NeizkO9RsgePegrEFNsv2sXQaz=0g@mail.gmail.com>
Accept-Language: it-IT, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tm-as-product-ver: SMEX-10.5.0.1057-7.500.1017-20650.005
x-tm-as-result: No--42.276200-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/UDtfi83hf9S4BVd927NvZPMJ4Gk
Cc: General discussion of application-layer protocols <apps-discuss@ietf.org>, "Julian F. Reschke" <julian.reschke@gmx.de>, Graham Klyne <GK@ninebynine.org>, Mark Nottingham <mnot@mnot.net>, "urn@ietf.org" <urn@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: Wed, 23 Apr 2014 10:05:17 -0000

I am wondering if it is useful and maybe necessary to define what a 'persistent identifier' is .... as many of you said technology is mot persistent per se but policy underpinning the system can make persistent the identifiers and the service linked to them .... in the APARSEN project www.aparsen.eu in WP 22 we reached agreement with many experts about a list of criteria that a 'trusted persistent identifier system' must have and we could start from this work to define a broader consensus .... doing so in my view we  could clearly distinguish between a URN or URI and a PI ... does it sound reasonable?

thanks

Maurizio Lunghi

> On 22 Apr 2014, at 16:18, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:
> 
>> On Fri, Apr 18, 2014 at 3:53 PM, John C Klensin <john-ietf@jck.com> wrote:
>> 
>> 
>> --On Friday, April 18, 2014 11:44 +1000 Mark Nottingham
>> <mnot@mnot.net> wrote:
>> 
>>> I have to say that I'm sympathetic to the proposed outcomes,
>>> albeit for different reasons, perhaps.
>>> 
>>> We have two communities using a shared artefact (URIs) with
>>> vastly differing use cases and viewpoints about them. Managing
>>> this situation has already proven extremely difficult for the
>>> IETF, and it seems to me to be very pragmatic to cease forcing
>>> them to co-exist, constantly bickering about angels dancing on
>>> pins.
>> 
>> Mark,
>> 
>> The above is actually a slightly different version of what drove
>> me to propose the "separate URNs" change in the new draft.  As
>> you say, we have two different communities with different
>> assumptions, exemplars, and perceived needs.  The one thing they
>> have in common is that neither accepts and interprets the
>> examples of the other in the same way.
> 
> I think the disagreement is over what counts as an example.
> 
> Back in the early days of URNs I remember a lot of people telling me
> that naming 'was hard' but could not explain why and that 'only a few
> people understand it' but not who.
> 
> After a while I got rather tired of that mode of argument and decided
> that I won't accept any argument that is not stated within the four
> corners of the message or cited directly.
> 
> 
>> Indeed, each community
>> tends to reject the legitimacy of the position and arguments of
>> the other and often to be dismissive and as far as I can tell,
>> largely stops listening.  More on that below, but let me suggest
>> there are two separate discussions that we can have now:
> 
> Well either a URN is a distinct class from a URL or it isn't.
> 
> One of the things that makes me rather suspicious about the argument
> is that every URL is based on a name, that is either a DNS name or an
> IP address both of which are names in tat the relationship between the
> signifier and the signified is purely convention. (In the case of an
> IP address the addresses are resolved via BGP)
> 
> Making a distinction between URIs that are based on a naming
> infrastructure that is defined by the IETF and those that are not
> seems to me to be a perfectly sensible approach for the IETF to take.
> 
> 
>> (1) Whether to continue to try to defend a Grand Unified
>> "Uniform Resource Identifier" theory (and, in your words,
>> "shared artifact"), with each of those words meaning whatever it
>> does to the person who pronounces it, or to let the communities
>> you mention go off and develop solutions to their own perceived
>> problems.  The predictable consequence of the first is going to
>> be standards development elsewhere, rather than stopping what
>> some perceive as bad behavior... we are just past "stopping"
>> those communities with which some other community disagrees.
> 
> I am not sure what the above means. I can't parse it.
> 
> The IETF has limited bandwidth, the Internet has 3 billion users. So
> less than 1/millionth of the Internet population is currently active
> in IETF. Decisions and standards are going to get made in many places.
> 
> Whether any grand unified theory can be defended depends on the claims
> made. If the claims made are extensive then the theory is likely to
> collapse. If the claims are weak then it can be defended but has
> little impact.
> 
> 
>> (2) The details of what the community that the draft identifies
>> as "content industries and memory organizations" need in URNs
>> and how to organize that information.  I will comment on that
>> subthread, but only on the URN list.
> 
> This is the part that I always have problems with, the idea that the
> structure or syntax of the identifier has any impact on whether it
> meets requirements such as long term resolution.
> 
> The only URI that is guaranteed to resolve to the signified content
> unconditionally is the DATA method.
> 
> The only URIs that are shorter than the signified data that can claim
> to be permanent are indexical, in most cases based on one way
> functions such as 'hashes', 'fingerprints' and 'digests'.
> 
> Its not the syntax of a naming infrastructure that gives it longevity,
> it is the political and business context in which it operates.
> 
> 
>> Sadly, some of these same arguments --including the implied "I
>> am right, you don't count, and I don't need to listen" tone of a
>> subset-- go back to the original URI WG and some of the reasons
>> I shut it down in 1995 (and resolved, unsuccessfully, to stay
>> out of this area after that).
> 
> I don't think it was one side of the argument guilty of that.
> 
> Most of my objections to various URN schemes come from the confusion
> of requirements and mechanism. If someone is saying that we must
> recognize a set of URIs as 'special' because of a particular set of
> requirements then I want to see a demonstration that
> 
> 1) The particular set of requirements can be met
> 
> 2) The distinction insisted on helps meet them
> 
> 
>> It has become clear in URNBIS WG
>> discussions that some of those in other communities sincerely
>> believe that RFC 3986 doesn't represent consensus, only an
>> example of how a determined minority can outlast and then
>> overwhelm others (and, from their point of view, reason and
>> experience).
> 
> Yep
> 
> 
>> I'm still convinced that the IETF's experience, perspective, and
>> scope still have useful things to bring to this discussion.
>> Maybe I'm naive.  But it seems to me that the choice at this
>> particular time isn't between how broadly URIs can reach, how
>> much hair-splitting we can perform about "persistent" or
>> "locator versus object identifier" but about whether we can
>> separate things sufficiently to let the two (or more)
>> communities go their own ways under a broad IETF umbrella or
>> whether we prefer standardization work in this set of areas to
>> be done elsewhere, most likely (given trends in W3C and WHATWG
>> as well as in URNBIS) with most of the relevant groups agreeing
>> only the 3956 is not relevant to their needs and plans.
> 
> Which is precisely why I suggest dividing the world up into 'that
> which the IETF is authoritative on' and 'that which the IETF is not
> authoritative on'.
> 
> -- 
> Website: http://hallambaker.com/
> 
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>