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<francesconi@ittig.cnr.it>  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:pierluigi.spinosa@ittig.cnr.it
Web:http://www.ittig.cnr.it
----------------------------------------------------------------------