Re: A few quick thoughts on "lex" (was" Re: [urn] continued use of list) (Dale R. Worley) Wed, 31 December 2014 23:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 086BC1A1A78 for <>; Wed, 31 Dec 2014 15:40:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.514
X-Spam-Status: No, score=0.514 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_LETTER=-2, SPF_SOFTFAIL=0.665] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VF1QXzvM2TQx for <>; Wed, 31 Dec 2014 15:40:55 -0800 (PST)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC38F1A1A4A for <>; Wed, 31 Dec 2014 15:40:54 -0800 (PST)
Received: from ([]) by with comcast id aPgu1p0042N9P4d01PgunT; Wed, 31 Dec 2014 23:40:54 +0000
Received: from ([]) by with comcast id aPgt1p0011KKtkw01PgtFG; Wed, 31 Dec 2014 23:40:54 +0000
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id sBVNeWKG010576; Wed, 31 Dec 2014 18:40:34 -0500
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id sBV0EZjk010273; Tue, 30 Dec 2014 19:14:35 -0500
X-Authentication-Warning: worley set sender to using -f
From: (Dale R. Worley)
To: John C Klensin <>
Subject: Re: A few quick thoughts on "lex" (was" Re: [urn] continued use of list)
In-Reply-To: <> (
Sender: (Dale R. Worley)
Date: Tue, 30 Dec 2014 19:14:35 -0500
Message-ID: <>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1420069254; bh=3WY8W7t650hyhOWD4F6nI5dFN88E88UbnLhtabtYWX0=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=SMPLB3x+kuMVSlPYR6c/EX1lQGsBWB/26yNM43KFGX3cE+vh1mADaPWApHqK5GaoY JMJz1SMXKNdLmJtt6Jl4PlF7q26aTLMmMOrO3J8qyOqK0DvJInvuL8Pmz30TwolgI9 KBOdGPsKJ84ET0h5h4bs5/mwm00L0FbrskY2QkabycrxwWt+GFFE0YrSAW79z9rWko fgVcgltEJAANx78KHLywPvpyVXicKuJRRRstMTjy4znSRt17kYpCPaTYi12zJtCtno YaQwWnS5fEmu5XHIxFUnH9wfPAXpR0iVucMpJ3oOIxhBMyeldnpRKSRLXFjt2eK/wg e0BxaCaWMy4AA==
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Dec 2014 23:40:58 -0000

John C Klensin <> writes:
> 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).  [etc.]

All of this is very well-said.

Experience shows that the IETF is not a good forum to address issues
traditionally handled by librarians.

It seems to me that there are two ways to proceed with this document.

One way is to provide proper references to a sufficiently universal
association/authority of legal scholarship/librarianship/legislation
that has examined and approved the underlying naming system, so that the
IETF can be assured that the system as a whole has been examined and
approved by people who are subject-matter experts.

A second way is to consider this to be an experimental proposal.  Then
we can approve the publication of the current state of the proposal in
order to inform the public, but leave the long-term development of the
system to ITTIG or whoever.

However, assuming that we proceed with the second method, there are some
issues that must be resolved.

1) The syntax as presented in the draft produces URNs which are not
accepted by the syntax of RFC 3986, even if we extend 3986 with the
query and fragment syntax of 2396.  (This is a critical technical

2) The authorities that govern certain elements of the syntax are
neither specified clearly or flagged as requiring further work.  For
example, the jurisdiction codes seem to be intended to be ISO 3166
Alpha-2 codes with assorted exceptions, but how the exceptions are
defined is not made clear.  Similarly, how the codes for
non-nation-state entities are allocated is unclear.  The proposal seems
to allow for <jurisdiction-code>s to be reassigned, requiring wholesale
reassignment of URNs.  This is contrary to the principles of URN
assignment.  (The reassignment of codes is a critical technical

3) The discussion of <jurisdiction-unit> gives as examples
"br:governo:decreto", "br;sao.paulo:governo:decreto", and
"br;sao.paulo;campinas:governo: decreto".  But none of these conform to
the provided syntax -- ":" is not permitted in <jurisdiction-unit>, and
" " is not permitted in URIs.  I believe that this is simply an
oversight, and that the intended examples are "br", "br;sao.paulo", and
"br;sao.paulo;campinas".  But the fact that such an error has been made
in the text suggests that the proposal has not been carefully edited.
The proposal needs to be edited to be free of easily-visible errors as a
demonstration that sufficient care has been taken in composing its text.
(This is a matter of assuring the quality of the proposal document.)

4) The handling of characters outside of the 26-letter Latin alphabet
seems to be philosophically contrary to internationalization.  Indeed,
the approach of requesting that all elements which are derived from
natural language be turned into sequences of Latin letters is what I
would expect a naive American to propose!  In contrast, the URI system
provides a method of encoding the full Unicode character set.  (Albeit
this encoding is visually ugly, it is uniquely mappable to and from a
representation of the URI with the escapes represented by the glyphs
they represent -- the latter representation is visually compatible with
the original natural language.)  Similarly, the DNS system (via
Punycode) provides a method of encoding the full Unicode character set
as components of DNS labels.  And modern computer systems seem to
commonly support the full Unicode character set.  These considerations
taken together suggest to me that an international legal reference
system should express that the glyphs of all writing systems are equal.
(This is a matter of supporting the IETF's principles of