Re: Application for a formal URN NID

Ted Hardie <> Mon, 15 April 2013 17:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14A9321F9651 for <>; Mon, 15 Apr 2013 10:10:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.505
X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DEAR_SOMETHING=1.605, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M0C5sRMZOBGv for <>; Mon, 15 Apr 2013 10:10:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::229]) by (Postfix) with ESMTP id 90D1E21F9640 for <>; Mon, 15 Apr 2013 10:10:51 -0700 (PDT)
Received: by with SMTP id ar20so5768301iec.28 for <>; Mon, 15 Apr 2013 10:10:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PWs4PncqC4N2o0GQxTEz0FnmEtF2UAoCTAN9kK+DE8w=; b=pAbVhIRjxfRVgV5P75ib+r8PwDRDjcP6LlMdggweN+iXzDP1Aw1Izs0HOH+qBALoYv nq2T2uWfT7NUYru4Krmf/FLsX8bSf4U/EbHedLV1Askj6eh2Dv7qiQViIBQ19H40eWYu WzM3bNrUPaQKwcECouoN8TtPgmsf0Oo0tEicUpG4I+PLJVaK2kbZkfOopRwV5u8VlPZZ 8QHmL72IYaD0rvGOqWkhLJW6usn406TTs9vJCV/fvAUhQODIOcAHLmR6Ro8Oq52ci0Tb o5EakEr7X10TL2RrUi5e6bZ/PzdZViXyPFyB6rAJn4ioBhsNY48hXITxfccMQufQjX1R MCBQ==
MIME-Version: 1.0
X-Received: by with SMTP id cq3mr5915666igb.70.1366045850974; Mon, 15 Apr 2013 10:10:50 -0700 (PDT)
Received: by with HTTP; Mon, 15 Apr 2013 10:10:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Mon, 15 Apr 2013 10:10:50 -0700
Message-ID: <>
Subject: Re: Application for a formal URN NID
From: Ted Hardie <>
To: PierLuigi Spinosa <>
Content-Type: multipart/alternative; boundary=047d7b2e3e00b1e3f904da695555
Cc: Enrico Francesconi <>,
X-Mailman-Version: 2.1.12
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: Mon, 15 Apr 2013 17:10:53 -0000


Some further comments in-line.

On Fri, Apr 12, 2013 at 7:48 AM, PierLuigi Spinosa <> wrote:

> Dear Ted,
>    thanks again for your document review. Please find here below our
> answers:
> Il 27/03/2013 18:57, Ted Hardie ha scritto:
>  Greetings,
>> I note that this document uses ISO3166-1 alpha 2 as the common source
>> of jurisdiction codes; these codes are subject to re-assignment, if I
>> understand it correctly, and some have been re-assigned (e.g. AI).
>> How would the namespace authority handle such a re-assignment?
> From a logical point of view the jurisdiction depends on the date of the
> act. Therefore it is always possible to know at which jurisdiction an act
> belongs to (in case of the "ai" , the acts issued before 1983 belong to the
> French Afar and Issas jurisdiction, since 1983 to the Anguilla jurisdiction)
> From a technical point of view the solution is more complex. Routing can
> be solved in one of the following different solutions:
> 1) in the DNS by a complex regex able to match not only the jurisdiction
> code but also the issuing date;
> 2) by a software developed by the manager of the current jurisdiction
> code, able to route the resolution to the proper resolver.
I do not believe that a DNS-based solution will work, as it would require
delegation to two different parties.  That is, you cannot have the delegated to Anguilla and expect it to have references to
Afar and Issas, but neither can you have it delegated to two different
authorities; you would have to create a new delegation e.g.  Knowing what dates to associate with these
delegations would require prior knowledge in the resolvers; given the rates
of re-delegation are small, this may not be a show-stopper, but it seems
simpler to use the 3-letter versions which have not seen this problem.

>  The document also says this:
>>     In order to keep editing and communication more simple and to avoid
>>     character percent-encoding, it is strongly recommended that national
>>     characters and diacritic signs are turned into base characters (e.g.,
>>     the Italian term "sanitU+00E0" converted into "sanita", the French
>>     term "ministU+00E8re" converted into "ministere"). Otherwise, the
>>     characters have to be percent-encoded according to the UTF-8
>>     character encoding [STD63] (e.g., "sanitU+00E0" encoded into
>>     "sanit%C3%A1").
>>     Anyway each country or jurisdiction decides the uniform names
>>     encoding modality of all the sources of law issued within its
>>     territory.
>> The recommendation to use "base characters" does not work for
>> languages where the base character set is not permitted according to
>> the URN syntax.  Within the EU context, Greek would face this problem;
>> the extension of this system to China, Japan, or Korea would represent
>> similar challenges.  Having a common method seems essentially required
>> for successful parsing, but matching will be a challenge even so,
>> because of the issue that characters which are considered equivalent
>> in one jurisdiction may not be so in others.  If a straight
>> string-match on the encoded characters is sufficient, this can be
>> worked around, but it implies that the namespace authorities will need
>> strict canonicalization rules.  Is that within the scope of this
>> effort?
> As already reported in the specific answers to Patrik, the convertion to
> "base characters" (in case by a transliteration) is recommended to fully
> exploit DNS routing facilities.
> Possible ambiguities or collisions due to different conversion modalities
> are solved, firstly by the jurisdiction code, otherwise, within the same
> jurisdiction, it is up to the Jurisdictional Registrar (as described in
> Section 5.2) to solve them.
If this is the case, I believe this:

Registrar SHOULD establish

should be a MUST instead, as it is critical for maintaining one of the
key properties of URNs:
collision avoidance.

 If such conversion is not accepted by a specific jurisdiction and
> therefore it is used the UTF-8 %-encoding, it is necessary to create a
> routing service relying to a software, out of DNS, addressing a proper
> resolution service.
If the folks are willing to follow the IDN rules on acceptable characters,
conversion to IDN encoding seems like another potential choice here.  I
defer to Patrik on this point, though, as he is far more expert in this
matter than I.


>  Reading through this, I am greatly concerned that the attempt to
>> create a system which is applies to each national legal system but is
>> not obviously delegated to them will result in reference issues.  I am
>> particularly concerned by the implications for countries with multiple
>> national languages; if a country which allows multiple languages, the
>> choice of which to use for sub jurisdictions seems fraught with
>> political impact.  Making them parallel without the input of the
>> jurisdiction seems, unfortunately, to create reference integrity
>> problems.
> Our solution to this problem is described in Section 4.5. The specific
> guideline is to identify the same act with as many equivalent identifiers
> (aliases) as many official languages exist within a jurisdiction.
If you are not concerned that the result will be the same act being
referred to be multiple equivalent names, that's fine; I had misunderstood
that to be a goal of the work.  If one were canonical, it would, of course,
make the inter-relationships easier to follow.

>    An alternative approach is for the relevant national authority to
>> create a namespace and to use that to include legal documents if they
>> wish (New Zealand, for example, has created a URN namespace).  Why is
>> that not the preferable approach here?
>> best regards,
>> Ted Hardie
> Waiting for your feedback
> best regards
>    Pierluigi and Enrico

best regards,

Ted Hardie

>> On Wed, Mar 27, 2013 at 10:08 AM, Enrico Francesconi
>> <>  wrote:
>>> Dear Sirs,
>>>     as per RFC 3406, we are requesting a two-week review for a formal URN
>>> namespace (LEX) related to "Sources of Law". The I-D application for our
>>> formal URN NID request is available at:
>>> Since this Internet Draft is going to expire on April 4th, 2013, we would
>>> kindly ask you if, meanwhile, we have to upload the draft again (even if
>>> no
>>> changes have been made with respect to the current version (v.07)).
>>> Thank you very much
>>> best regards
>>>     Pierluigi Spinosa and Enrico Francesconi
>>> ------------------------------**---------------------------
>>> Institute of Legal Information Theory and Techniques
>>> Italian National Research Council
>>> Via de' Barucci 20
>>> 50127 Florence
>>> Italy
>>> Tel: +39 055 4399665
>>> Fax: +39 055 4399605
>>> ------------------------------**---------------------------
> --
> ------------------------------**------------------------------**----------
> PierLuigi Spinosa
> Istituto di Teoria e Tecniche dell'Informazione Giuridica
> del Consiglio Nazionale delle Ricerche
> Via de' Barucci, 20
> 50127 Firenze
> tel. +39 055 4399-673
> fax  +39 055 4399-605
> e-mail:pierluigi.spinosa@**<>
> Web:
> ------------------------------**------------------------------**----------