A few quick thoughts on "lex" (was" Re: [urn] continued use of urn-nid@ietf.org list)

John C Klensin <john-ietf@jck.com> Tue, 30 December 2014 15:31 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: urn-nid@ietfa.amsl.com
Delivered-To: urn-nid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C66E11A01CB; Tue, 30 Dec 2014 07:31:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2gAX7ZuW2Fjj; Tue, 30 Dec 2014 07:31:43 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BCC71A019B; Tue, 30 Dec 2014 07:31:43 -0800 (PST)
Received: from h8.int.jck.com ([] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1Y5ylk-000BWr-RZ; Tue, 30 Dec 2014 10:31:36 -0500
Date: Tue, 30 Dec 2014 10:31:31 -0500
From: John C Klensin <john-ietf@jck.com>
To: Barry Leiba <barryleiba@computer.org>
Subject: A few quick thoughts on "lex" (was" Re: [urn] continued use of urn-nid@ietf.org list)
Message-ID: <1BCA16D96EC2C307E29BFABC@JcK-HP8200.jck.com>
In-Reply-To: <CALaySJJU1XdwrOyTdJ4nobrW8=piQ40Z0=Ay-5KvJY9-iGTEYQ@mail.gmail.com>
References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> <5499C04C.6040605@andyet.net> <549A58E4.30206@it.aoyama.ac.jp> <844A0581B9447C7703322432@JcK-HP8200.jck.com> <CALaySJJU1XdwrOyTdJ4nobrW8=piQ40Z0=Ay-5KvJY9-iGTEYQ@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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-nid/FstxGpOmbhSEnGpeBmBMcBp8qdg
Cc: urn-nid@ietf.org, urn@ietf.org
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn-nid/>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Dec 2014 15:31:46 -0000

--On Monday, December 29, 2014 15:37 -0500 Barry Leiba
<barryleiba@computer.org> wrote:

> The possible exception is "lex", which has been held up very
> long already.  It is, on the other hand, one that I find
> problematic for a number of reasons, and when the authors have
> responded to my last comments to them I'm inclined to ask you,
> John, to be its document shepherd... which may, in itself,
> throw it into the "delayed" pile (if you share my concerns, at
> least some of them, and/or have your own).

Against my better judgment, I looked through this (that is
"looked through", not "read carefully").  I see multiple
problems which start with the observation that I know of at
least a few international legal document referencing systems
that would not fit this mold without considerable distortion
(I'm not an expert; if I were, I'd probably know of more); the
document commits Punycode abuse and, at the risk of appealing to
3986, there is no obvious reason to avoid use of %-encoding for
the non-ASCII cases they cite; they claim to be international,
but all of their thinking and examples seem to be tied to
sometimes-extended Latin script (in particular, Section 3.5
could create a huge mess and, for Section 3.9, someone should
explain to them what an "Arabic numeral" looks like); and so on.

As a slightly more complex example, Section 2.4 contains text
starting "In case of country code re-assignement...".  Perhaps
more study would help, but I'm not sure what it actually means
in practice but believe that it might violate the fundamental
principle of stability in URNs.

I also note that, while the introductory material (first
paragraph of 1.1) claims this is about legal materials and
sources of law and not, e.g., about legal doctrine, they
identify at least one example of a legitimate registrant who is
a source of law only in the wildest imagination of its more
doctrinaire adherents.  That particular example calls both the
consistency and the competence of the submission in this
particular area into question.

The naming authority model is also a bit muddy.  The
registration root should really be under control of an
international consensus body/authority, not a research
organization in one country (we've had more than enough proofs
of where the latter leads).  My skimming did not identify any
evidence that national legal/judicial authorities are willing to
sign up for the roles this document seems to give them, and so

I spotted several other issues that might be more important but
that would require a lot more explanation.  One of them is
whether we should be using <foo>.urn.arpa for subtrees that have
neither network protocol implications or broad international use
and acceptance.  If there were the criterion, I don't know if
this would qualify.  Otherwise, and unless the i18n issues are
really sorted out, I'd think that consideration should be given
to whether something like <foo>.urn.eu would be appropriate.

I draw two conclusions for the above.  FIrst, there are a lot of
issues, some related to legal documents, some to URN (or URI)
niceties, and some to authority, that the document just does not
have sorted out yet.  Second, the IETF may be appropriate as a
place to sort out the best syntax model for registering an
established name space as a URN-embedded namespace, but we
should not be in the business of recognizing or ratifying naming
authorities, especially in areas we know almost nothing about
(either technically or in terms of socio-political
relationships).  Except where Internet protocols are concerned,
we should probably refer issues about defining namespace
fundamentals for particular fields to established and competent
bodies in those fields, let them establish their own standards,
and then work with them on URN embedding as needed.   That is
something we haven't written into 2141bis and, especially with
the elimination of experimental RFCs, we probably should figure
out how to say explicitly.   

For the case of this particular document, if the International
Federation of Library Associations and Institutions (IFLA) has
really been consulted, it would be reasonable to approach them,
ideally in consultation with ISO/TC 46, and define an
appropriate international standard that parallels the ISSN and
ISBN, or even DOI, work.  If not, I think we should suggest to
the authors that they try publishing a detailed description of
the underlying system in scholarly legal community journals of
appropriate scope and coverage (including an
internationally-broad editorial board and wide international
readership), see what feedback they get, and then strip this
document down to normative references about the theory and
organization of the namespace.  If they can't get such feedback,
or can't find a reputable and appropriate place to publish, then
no one relevant cares and the IETF should not be in the middle.

As an alternative, if they can get formal EU backing for this,
they might try registering a namespace that assigned codes and
jurisdictions for EU, IT, Brazil if they really want to play,
and any other EU countries they can get to sign up, reserve all
other codes for future expansion, designate the second-level
authorities (presumably ones who have formally agreed) in the
document, and come back to us with a revision plan when they can
show more international interest.  

Given the above and time constraints, I'm not willing to play
shepherd for this document unless at least those issues are
sorted out and clear endorsements and commitments are
established.  THe comments above may give you enough of a review
to get the draft out of "AD contemplation" state.

Melinda and Andy, these two notes seemed important, but sucked
up almost all of my URNBIS time for the week.  Schedule slipping