Subject: Re: Application for a formal URN NID

From: PierLuigi Spinosa <[email-masked]>
Date: Fri, 12 Apr 2013 16:47:42 +0200

Dear Patrick,
    thanks for your remarks. Please find here below our considerations 
about the problems you raised.

Il 27/03/2013 18:55, Patrik Fältström ha scritto:
> On 27 mar 2013, at 18:08, Enrico Francesconi<[email-masked]>  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:
>> http://datatracker.ietf.org/doc/draft-spinosa-urn-lex
>> 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)).
> I have a few comments on this namespace, which I in general believe is a Very Good Idea:
>
> 1. Non-allocated TLD .LEX
>
> I object to use of the non-allocated TLD .LEX
We thought that the registration of a virtual domain was not necessary, 
and actually under the domain lex.urn.arpa there can be inserted an 
entry "eec.lex", addressed by a suitable regex, routing to an existing 
server under a registered domain through NAPTR records.
However if you consider that this solution might be not suitable or 
accepted, we can ask for the registration of the LEX TLD, or maybe more 
easily ask for the registration of a sub-domain of ORG TLD (lex.org), 
and obviously changing the urn:lex specification draft accordingly.

Please let us know which can be the best solution for you.
> 2. Casing
>
> The text in section 3.3 must be much more clear as there is nothing called case insensitivity globally. Instead it must be clear whether the identifiers are lower case or upper case of whatever base string is chosen, and whether the base string or its case folded equivalent is to be used in the identifier.
>
> More generically, it must be decided what normalisation form strings should be in to be used as tokens in this URN.
We think to re-write the section as follows

3.3  Case sensitivity

Although the case does not change the logical identification of the 
source of law and therefore the names belonging to the "lex" namespace 
should be considered functionally equivalent independently from the 
case, nevertheless to take advantage of memory caching and simplify the 
resolution process the specific name MUST be always created in lower 
case (e.g., "Ministry" will be recorded as "ministry").

> 3. Use of Unicode codepoints
>
> I do not think the full Unicode codespace should be allowed, even if the codepoints are %-encoded
We can change section 3.4 as follows:

3.4  National Characters and Diacritic Signs

    In order to exploit DNS as a routing tool towards the proper 
resolution system, 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 ASCII characters 
(e.g., the Italian term "sanitU+00E0" converted into "sanita", the French
    term "ministU+00E8re" converted into "ministere"), in case by 
transliteration (e.g. "MU+00FCnchen" converted into "Muenchen").

    If such solution is unacceptable by a specific jurisdiction, the 
characters have to be percent-encoded according to the UTF-8 character 
encoding [STD63] (e.g., "sanitU+00E0" encoded into
    "sanit%C3%A1").  In this case routing via DNS is not fully supported 
and it is to be implemented a routing service via a specific software.

    Anyway each country or jurisdiction decides the uniform names 
encoding modality of all the sources of law issued within its territory.

> 4. Sub namespaces
>
> Is there an intention to have a registry for for example <authority>?
In Section 5.2 we suggest the implementation of an authority registry to 
define the authority name forms and help the composition of the document 
identifier and the creation of references.

> 5. Language tags
>
> I think you should refer to BCP-47 instead of ISO 639-1.
We agree to refer to the BCP-47 instead of ISO 639-1, therefore the part 
related to <language> in Section 4.6 will be rephrased as  follows:

  <language> is the identification code of the language in which the
    document is expressed, according to [BCP-47] (it=Italian,
    fr=French, de=German, etc.). The granularity level of the language 
(for example the specification of the German language as used in 
Switzerland rather than the standard German) is left to each specific 
jurisdiction.
The information is not necessary when the text is expressed in the unique
    official language of the country or jurisdiction.

> 6. Mapping from lex namespace tokens to DNS tokens
>
> What is to be made when/if the lex namespace token include non-ascii?
This issue should be solved by changes reported as answer at your 
question 3. (subject: Unicode).
As further specification we can add the paragraph marked by +++ (here 
below) within Section 6.1

"Likewise the institution responsible for the jurisdiction uniform
    names (e.g., "urn:lex:br") has the task of managing the relative root
    in the DNS system (e.g., "lex.senado.gov.br" zone) and routing the
    resolution towards its resolvers on the basis of parts of the uniform
    names. In similar way it can delegate the resolution of
    country/organization sub-levels (e.g., "urn:lex:br;sao.paolo")
    towards the relative zone (e.g., "lex.sao-paolo.gov.br").
+
+ Such DNS routing chain does not work for all the urn components 
containing %-encoded characters. Therefore in these cases a proper software
+ implementing routing service has to be implemented.
+
    The resolution service is made up of two elements: a knowledge base
    (consisting in a catalogue or a set of transformation rules) and a
    software to query the knowledge base itself."

> 7. Algorithm for the DNS resolution
>
> In addition to [6], I see there is a mapping from '.' to '-'. Is there some formal syntax to be included?
Actually we do not understand which part of the document this remark is 
referred to.

> 8. Bidirectionality
>
> There is no mention of potential implications of bidirectional codepoints, and/or the general directionality of the lex identifier itself.
We are going to highlight such urn property in Section 1.4:

  Registrants wish now to promote interoperability among legal
    information systems by the definition of a namespace convention and
    structure that will create and manage identifiers for legal
    documents. The identifiers will be:
    - globally unique
    - transparent
+ - bidirectional
    - persistent
    - location-independent, and
    - language-neutral.
    These qualities will facilitate legal document management as well as
    provide a mechanism of stable cross-collections and cross-country
    references.
+
+ Transparency means that given an act and its relevant metadata 
(issuing authority, type of measure, etc.) it is possible to
+ create the related urn identifier.
+ Moreover this identifier is able to unequivocally identify the related 
act.
+ These  two properties makes the identification system bidirectional 
(from an act to its urn and from a urn to the related act).
+
    Language-neutrality is an especially important feature that will
    promote adoption of the standard by organizations that must adhere to
    official-language requirements. The proposed standard will provide
    useful guidance to both public and private groups that create,
    promulgate, and publish legal documents. Registrants wish to minimize
    the potential for creating conflicting proprietary schemes, while
    preserving sufficient flexibility to allow for diverse document types
    and to respect the need for local control of collections by an
    equally diverse assortment of administrative entities.

>     Patrik

Waiting for your feedback
best regards
    Pierluigi and Enrico

-- 

----------------------------------------------------------------------
PierLuigi Spinosa
ITTIG / CNR
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:[email-masked]
Web:http://www.ittig.cnr.it
----------------------------------------------------------------------

---

From: PierLuigi Spinosa <[email-masked]>
Date: Fri, 12 Apr 2013 16:48:04 +0200

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.

> 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").
> 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 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.

> 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.

>   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

>
> On Wed, Mar 27, 2013 at 10:08 AM, Enrico Francesconi
> <[email-masked]>  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
>>
>>
>>
>> ---------------------------------------------------------
>> ITTIG - CNR
>> 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
>> email:[email-masked]
>> ---------------------------------------------------------
>>

--

---

From: Ted Hardie <[email-masked]>
Date: Mon, 15 Apr 2013 10:10:50 -0700

Greetings,

Some further comments in-line.

On Fri, Apr 12, 2013 at 7:48 AM, PierLuigi Spinosa <
[email-masked]> wrote:

> 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:
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
ai.lex.urn.arpa 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.
pre-1983ai.lex.urn.arpa.  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.

> 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.

> routing service relying to a software, out of DNS, addressing a proper
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.

> 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.

best regards,

Ted Hardie

>>> http://datatracker.ietf.org/**doc/draft-spinosa-urn-lex<http://datatracker.ietf.org/doc/draft-spinosa-urn-lex>
>>>
>>> ------------------------------**---------------------------
>>> ITTIG - CNR
>>> ------------------------------**---------------------------
>>>
>>>
> --
>
> ------------------------------**------------------------------**----------
> PierLuigi Spinosa
> ITTIG / CNR
> e-mail:pierluigi.spinosa@**ittig.cnr.it<[email-masked]>
> ------------------------------**------------------------------**----------
>
>