Re: Application for a formal URN NID

[Enrico Francesconi <[e-mail]>]

Dear Ted,
   thanks for your reply. Here below please find in-line our comments.

Il 15/04/2013 19:10, Ted Hardie ha scritto:
> Greetings,
>
> Some further comments in-line.
>
> On Fri, Apr 12, 2013 at 7:48 AM, PierLuigi Spinosa <[e-mail] 
>  <mailto:[e-mail]>> 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 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.

Thanks for your suggestion.
In case of country code re-assignement ("ai" given to Anguilla), in  
any URN this country code will be associated to the new jurisdiction,  
therefore the related documents will be identified by such new  
jurisdiction country code.
This means that the previous jurisdiction ("ai" as associated to  
French Afar and Issas), will use another country code and, at the same  
time, change the first element of each URN identifier already assigned.

A possible choice for jurisdiction renaming in old URNs can be one of  
the following:
1) keeping the old country code and appending a date interval  
corresponding to the period of validity of the code for this  
jurisdiction (ex: "ai-1974-1983")
2) changing the old country code with the new code assigned to the  
same country/jurisdiction (ex: "ai" ---> "dj" (Djibouti))
3) changing the old 2-letters country code with the 3-letters one (ex:  
"ai" --->"afi", however this is currently deleted)

We consider that most effective solution is the one that manage  
delegations according different dates (solution 1)), however it is up  
to the specific jurisdiction to choose the preferred solution.

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

OK

>    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.
Following your suggestion, we can rephrase the previous sentence as  
follows:

"If such conversion is not accepted by a specific jurisdiction and  
therefore it is used the UTF-8 %-encoding, it is necessary:
- to convert the non-ASCII characters to IDN encoding, using the  
rfc3492 punycode translation (es: /München ---> /mnchen-3ya);
- to create a routing service relying to a software, out of DNS,  
addressing a proper resolution service.
However it is up to the specific jurisdiction to choose the preferred  
solution."

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

OK
>
>
>          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?

The approach you propose would imply to register different national  
namespaces, which "lex" would be a sub-namespace of (ex: urn:it:lex,  urn:uk:lex 
, etc.).
In our opinion this approach would be different and more complex, from  
an organization point of view, with respect to the registration of a  
lex namespace (urn:lex), because every country should register its own  
urn namespace (urn:it, urn:uk, etc.), then a "lex" sub-namespace  
should be foreseen and appended to. The related "lex" naming  
convention should then follow the rules now reported in the urn:lex I-D.
On the contrary with the registration of the "lex" namespace each  
country can simply add an entry in the DNS pointing to the proper  
national resolver.
Moreover, using urn national schemas (ex: urn:uk:lex) you will have  
national "lex" sub-schemas which, in principle, may be different to  
one another, without infringing any established rule at international  
level, therefore reducing interoperability between jurisdictions.


>
>
> best regards,
>
> Ted Hardie
>

Waiting Patrik's comment too, we will prepare a new version of the  
document. Then we will send it to you again and, if you agree, will  
submit it as final release.

Best regards

    Pierluigi and Enrico


---------------------------------------------------------
ITTIG - CNR
Institute of Legal Information Theory and Techniques
Italian National Research Council

Via de' Barucci 20
50127 Florence
Italy

Tel: [phone]
Fax: [phone]
---------------------------------------------------------


>
>
>        On Wed, Mar 27, 2013 at 10:08 AM, Enrico Francesconi
>        <[e-mail] <mailto:[e-mail]>>
>         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)).
>
>
>            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: [phone] <tel:%2B39%20055%204399665>
>            Fax: [phone] <tel:%2B39%20055%204399605>
>            email:[e-mail]
>            <mailto:[e-mail]>
>            ---------------------------------------------------------
>
>
>    --
>     
> ----------------------------------------------------------------------
>    PierLuigi Spinosa
>    ITTIG / CNR
>    Istituto di Teoria e Tecniche dell'Informazione Giuridica
>    del Consiglio Nazionale delle Ricerche
>    Via de' Barucci, 20
>    50127 Firenze
>    tel. [phone] <tel:%2B39%20055%204399-673>
>    fax [phone] <tel:%2B39%20055%204399-605>
>
>    e-mail:[e-mail]
>    <mailto:[e-mail]>
>    Web:http://www.ittig.cnr.it
>     
> ----------------------------------------------------------------------
>
>

-- 

----------------------------------------------------------------------
PierLuigi Spinosa
ITTIG / CNR
Istituto di Teoria e Tecniche dell'Informazione Giuridica
del Consiglio Nazionale delle Ricerche
Via de' Barucci, 20
50127 Firenze
tel. [phone]
fax  [phone]

e-mail:[e-mail]
Web:http://www.ittig.cnr.it
----------------------------------------------------------------------