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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [70.88.254.51]) (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 ([198.252.137.35] 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-Connect-IP: 198.252.137.35
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 on. 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 accordingly. john
- Re: [urn] continued use of urn-nid@ietf.org list Sean Leonard
- Re: [urn] continued use of urn-nid@ietf.org list Martin J. Dürst
- Re: [urn] continued use of urn-nid@ietf.org list John C Klensin
- Re: [urn] continued use of urn-nid@ietf.org list Barry Leiba
- Re: [urn] continued use of urn-nid@ietf.org list Sean Leonard
- Re: [urn] continued use of urn-nid@ietf.org list John C Klensin
- A few quick thoughts on "lex" (was" Re: [urn] con… John C Klensin
- Re: A few quick thoughts on "lex" (was" Re: [urn]… Dale R. Worley
- Re: [urn] continued use of urn-nid@ietf.org list Barry Leiba
- Re: [urn] continued use of urn-nid@ietf.org list John C Klensin
- Re: [urn] continued use of urn-nid@ietf.org list Sean Leonard
- Re: [urn] continued use of urn-nid@ietf.org list Barry Leiba
- Re: [urn] continued use of urn-nid@ietf.org list Sean Leonard
- Re: [urn] continued use of urn-nid@ietf.org list Juha Hakala
- Re: [urn] continued use of urn-nid@ietf.org list Barry Leiba