Re: [urn] Moving ahead with draft-spinosa-urn-lex

Barry Leiba <barryleiba@computer.org> Tue, 01 May 2018 05:08 UTC

Return-Path: <barryleiba@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 AFEC212E880 for <urn@ietfa.amsl.com>; Mon, 30 Apr 2018 22:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.418
X-Spam-Level:
X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 maQo3Ny2dJOb for <urn@ietfa.amsl.com>; Mon, 30 Apr 2018 22:08:32 -0700 (PDT)
Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B261129C6D for <urn@ietf.org>; Mon, 30 Apr 2018 22:08:32 -0700 (PDT)
Received: by mail-it0-f44.google.com with SMTP id i136-v6so3589730ita.2 for <urn@ietf.org>; Mon, 30 Apr 2018 22:08:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rzZntfv1RMmqJaO+sfKLusoioWitOhOTq6SUPOz8Uk0=; b=D/cLUqTLDwvxn/WubVQBHGM88LKQceIae/1otcgaLapNsbcL6dDACWqOICUfuUkB0h pewfls+sVSO6Agb8AlRwv64vYJx5j6LUZqJ4oHUPyRzhm4yMPg+G6bsFfN+1PNs9Mczp /6XifMcbFSPkMHUZNLHcUTTt4CZUEOP/EdeXJhC3gBuHtsprY4N+zy06UcmY85+3/AKs G9xM1wLZG62VYlk2WzgiEqnTU3JsY7elEcwiWZGYYhuU5GFb7DPjDK8u0Qm6KVBjYqoz 9LRGH/oGfZrroI4KpZmRkrsYvbZTTnTylG6BP9f9QaPJXueJMoA3KVn7HmKhKtsMmzB+ vlog==
X-Gm-Message-State: ALQs6tDTvFORraomrvKWxTlhZs/EJKt8A00qsuk/4lujvRnT5QgJF7RO U7NAzkdx1J4uVKwSk+gaomfNYNsfbTjEYBend5s=
X-Google-Smtp-Source: AB8JxZohlhFQXnapi4S8hF2I+/Hd1JVESrCEwM4SHN5K50g4/0PbdplfmhjPTS7fw1LS2iAz7oFAPmzOU5FackSbHsw=
X-Received: by 2002:a24:4151:: with SMTP id x78-v6mr7928176ita.0.1525151311512; Mon, 30 Apr 2018 22:08:31 -0700 (PDT)
MIME-Version: 1.0
References: <72446a5a-ec31-cc7e-d00a-11029ed941b3@stpeter.im> <87a7tk6wgz.fsf@hobgoblin.ariadne.com>
In-Reply-To: <87a7tk6wgz.fsf@hobgoblin.ariadne.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Tue, 01 May 2018 05:08:20 +0000
Message-ID: <CALaySJK5Rqv2_A_ZA7wxLJGUxPuLEmQDewOtfTEnvAbrpRjV7A@mail.gmail.com>
To: "Dale R. Worley" <worley@ariadne.com>
Cc: Alexey Melnikov <aamelnikov@fastmail.fm>, L.Svensson@dnb.de, Peter Saint-Andre <stpeter@stpeter.im>, caterina.lupo@gmail.com, enrico.francesconi@ittig.cnr.it, john-ietf@jck.com, juha.hakala@helsinki.fi, pierluigi.spinosa@gmail.com, urn@ietf.org
Content-Type: multipart/alternative; boundary="00000000000026ccbc056b1df6e9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/3j3JPcLV8uJ00B-mgefF4GCg4tk>
X-Mailman-Approved-At: Mon, 30 Apr 2018 22:17:53 -0700
Subject: Re: [urn] Moving ahead with draft-spinosa-urn-lex
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 01 May 2018 05:08:35 -0000

Thanks for this, Dale: this seems like a reasonable way forward to me, at
this time.
Do others agree?

Barry

On Mon, Apr 30, 2018 at 8:39 PM Dale R. Worley <worley@ariadne.com> wrote:

> My apologies for not working on this earlier.
>
> The current draft of "urn-lex" is draft-spinosa-urn-lex-12.  People have
> criticized its proposed URN system in many ways, but it seems to me that
> most of the criticisms are "bibliographic", they concern good ways to
> create identifiers for written works.  As such, the IETF is not a good
> forum for correcting most of those problems.
>
> My proposal is that we implement "rough consensus and running code" --
> obtain a usable registration of the "lex" URN namespace so that the
> authors and ITTIG can put the "lex" URNs into practice.  The process of
> using the URNs will educate the authors regarding the correct resolution
> of the various problems, and will likely cause them to later submit a
> revised registration.
>
> That is, the registration we create at this time will be understood to
> be experimental in nature.
>
> In order to be suitable as an "experimental" registration, there are a
> few problems that must be resolved:
>
> 1. The URN syntax must conform to the generic URN syntax.
>
> 2. The requirements of uniqueness and persistence must be met.  (That
> is, any URN designates at most one resource, and the resource that it
> designates must not change over time.  However, it is permissible to
> have multiple URNs designate the same resource.)
>
> 3. The process or authority that assigns each URN must be well-defined.
>
> Item 1 is taken care of, in that the syntax in -12 conforms (as far as I
> can tell) to the URN syntax in RFC 8141.
>
> Item 2 is the responsibility of the Jurisdictional Registrars, in the
> same way that the naming authorities of many other URN namespaces are
> responsible for uniqueness and persistence.
>
> Item 3 requires that a registry of jurisdiction codes and Jurisdictional
> Registrars be maintained.  Section 11.2 of the -12 draft proposes that
> IANA maintain the registry.  Given the experimental nature of the URN
> registration, it seems to me to be premature to involve IANA, especially
> since the principles that the Designated Export must implement are
> likely to change over time.  Instead, it seems to me that the best
> choice for registrar is ITTIG-CNR, the proposer and developer of the URN
> namespace.
>
> When the namespace definition is transitioned to a non-experimental
> status (including fixing a good set of policies to assign jurisdiction
> codes), the registry can be transferred to IANA to implement the proven
> policies.
>
> Following this path requires only small changes for -13, viz., updating
> section 11.2.
>
> Dale
> ----------------------------------------------------------------------
> Archived discussions:
>
> https://www.ietf.org/mail-archive/web/urn/current/msg03828.html
> 16 Nov 2017
> "urn:lex draft v. 12"
>
> https://www.ietf.org/mail-archive/web/urn/current/msg03811.html
> starting 20 Sep 2017
> "Request for new URN namespace review: LEX"
> Message-Id: <
> 1505909590.1544977.1112321704.5FEB92F9@webmail.messagingengine.com>
>
> https://www.ietf.org/mail-archive/web/urn-nid/current/msg01270.html
> starting 29 Apr 2014
> "Publication request for draft-spinosa-urn-lex"
> Message-Id: <CALaySJJk5YiCQZqt6WoWkqfAzi2A04HEAH=
> vG0pVAy8e45N5aQ@mail.gmail.com>
>
> https://www.ietf.org/mail-archive/web/urn-nid/current/msg01204.html
> starting 27 Mar 2013
> "Application for a formal URN NID"
> Message-Id: <23A64284-6B03-4B24-B680-54A61E96BECA at ittig.cnr.it>
>
> https://www.ietf.org/mail-archive/web/urn-nid/current/msg01059.html
> 15 Oct 2009
> "URN LEX Namespace submission"
>
-- 
Barry
--
Barry Leiba  (barryleiba@computer.org)
http://internetmessagingtechnology.org/