Subject: Re: [urn] Request for new URN namespace review: LEX

From: Enrico Francesconi <[email-masked]>
Date: Fri, 6 Oct 2017 21:00:55 +0200

Dear All,
   thanks a lot everyone for the global revision of the urn-lex draft and for your useful comments on the document. We have finalized the analysis of most of them, therefore we send you here below a sum-up of the interventions we would like to provide to the document.
We will be back with feedback to the most recent comments from Sabrina’s and Juha’s in a following email.
We grouped comments with respect to each reviewer and, for each remark, we provide:
a synthesis of the requests (Req:)
our answers (Ans:)
arguments for a further analysis (To Deepen:)

In case approved we will prepare a draft v.12 accordingly, to be then validated.
Please let us know how to proceeed or any additional remarks.
Thanks again for your collaboration
best regards

Pierluigi and Enrico

******************************
Dale's comments
******************************
A. Major items

1. Annex A: Use of alfanum, etc.
Req: Simplifying syntax with non-terminal elements
Ans: We will simplify the syntax in the direction required

2. Sez. 4.4: How are non-ASCII characters to be handled?
Req: Different management of non-ASCII characters in different sections. UTF-8% encoded or punycode incompatible
Ans: strongly recommend the use of ASCII base. In this case we can use a straightforward DNS query for routing. In case this solution is unacceptable for a jurisdiction: use UTF-8% encoded in URNs and use punycode conversion in DNS. In this case, the jurisdiction has to implement a software conversion as an interface for DDDS

3. Sez. 3.2: Compatibility with RFC 2141 and use of "~"
Req: character "~" not allowed in RFC 2141
Ans: declare that the syntax conforms to RFC 8141

To Deepen: For backward compatibility, the "/", previously prohibited in URNs, is reserved for future use, then we can remove the "/" from prohibited characters and include it in "future expansions"

4. Sez. 11.2: The pseudo-TLD ".lex"
Req: it no longer works if .lex is assigned
Ans: use pseudo-domain "lex.arpa"

5. Sez. 6.7: Dealing with publishers
Req: Possible issues if an event is assigned by an editor independently
To Deepen: By joining the federated system, a publisher accepts the urn-lex rules. The Jurisdictional Registrar (Section 7.2) provides guidelines and monitors their application
Req: Domain Name Editor: persistence of the manifestation depends on the publisher
To Deepen: Common problem with all components where a domain name is indicated. Think of a solution through aliases

B. Minor points

6. Abstract
Req: World Wide Web Consortium reference for resource identification
Ans: Replace W3C with IETF

7. Sez. 1.1: The Purpose of Namespace "lex"
Req: Useful when mapped on HTTP URLs and not URIs
To Deepen: we often talk about http uri. Maybe we can emphasize its function as identifier rather than as locator.  The identifier is often not an absolute URL

8. Sez. 1.4: General Characteristics of the System
Req: SHOULD seems more appropriate than MUST
Ans: replace "must" with "should"

9. Sez. 2: Syntax label
Req: The syntax and semantics of components r- and q- are not defined in the document
Ans: after: "... introduced by [RFC8141]" insert: "The use of r- and q- components with LEX URNs is not defined in this document. But they provide new ... "

10. Sect. 2: Documentation
Req: better replace "none" with a reference to the same document
Ans: replace "none" with: "The details of the syntax, semantics and use of LEX URNs are given in [this RFC]."

11. Sect. 3.1: Identifier structure
Req: Capitalization of Section Title: non-consistent document
To Deepen: Check rules for writing section titles

Req: representation of non-ASCII characters in RFCs
Ans: right: the guidelines suggest using the Unicode convention U + XXXX

12. Examples
Req: Are the examples shown real or hypothetical?
Ans: Include the following: "All URN examples in the document are hypothetical"

13. Sez. 5.3: Ordinal Numbers
Req: To clarify whether it is Western or Eastern Arabic numbers
Ans: add "Western" before "Arabic numbers"

14. Sez. 6.1: Basic Principles
Req: substitution suggestion of "by parser" with "from parser"
Ans: replace "by parser" with "from parser"

15. Sez. 6.7: Structure of the Document Identifier at Manifestation Level
Req: syntax ambiguity: with only one element, it is not clear whether it is component or feature
Ans: Correct syntax according to Dale's suggestions in the presence of features, component (if absent) is set to "all" (whole document)

16. Sez. 6.8: Sources of Law References
Req: Partition ID indicates an element and not a simple location
To Deepen: It is true, but it depends on the level of granularity of the identification systems (documents or also partitions?).

17. Sez. 8.1: The General Architecture of the System
Req: Incomplete reference: RFC 3403 only defines NAPTR records
Ans: Add reference to RFC 3405 explaining why the lex.urn.arpa domain is created

18. Sez. 11.2: Jurisdiction-code Registration
Req: missing the description of the registry structure
Ans: Specify format and examples of the registry of jurisdiction codes

19. Annex A: Summary of the syntax of the uniform names of the "lex" namespace
Req: Reported several errors or ambiguities: lowercase; body/function/office, component/feature, ...
Ans: review the syntax, according to Dale's suggestions. Test the syntax with a parser

20. Annex A: Summary of the syntax of the uniform names of the "lex" namespace
Req: syntax error for % encoded
To Deepen: Correct the % encoded syntax (see RFC 3261 par.25.1)

21. Annex A, Sec. B1.4 (Indication of the Body) and B1.5 (Indication of the Function)
Req: ambiguity between body / function / office
Ans: Correct syntax to eliminate ambiguities

22. Annex D and D1: Http-based LEX identifier
Req: HTTP and non-HTTP-based
Ans: delete "based"

Req: Same names used for http and urn elements: same semantics but different syntax
To Deepen: Use same names in http and urn elements, maybe change delimiters

23. Sez. D1: Http-based URI
Req: Wrong Link to Linked Data
To Deepen: Correct reference to Linked Data

******************************
Paul's comments
******************************

A. Major items

24. Scope of the document
Req: Doc. describes not only URN but a fully federated system. Better divide the two documents
To Deepen: postpone the decision at the end of the discussion

25. Name or query?
Req: Doc. also describes how to use URNs as a query, incompatibility with URNs
To Deepen: Document: URN Full and Unique; references: URN incomplete, but useful (see e-mail sent to Dale on 9/20)

B. Minor points

26. Sez. 11.2: Jurisdiction-code Registration
Req: Re-assigning ccTLD: using the solution of international institutions?
Ans: The Registry of Jurisdiction Codes solves this problem. If the ccTLD was reassigned, the old assignment remains in the log. If it was already assigned, the applicant should choose a different one

Req: <name> .lex is no longer valid if .lex is assigned
Ans: use pseudo-domain "lex.arpa" (see answer to Dale’s remark n.4)

27. Full utility of this URN form
Req: it seems that a browser plugin in needed
To Deepen: The DDDS for URNs is fully described in various RFCs (3401-05). However, to the best of our knowledge, the "urn:" schema is not recognized by browsers, the most widely used tool for accessing information. Therefore, to activate a resolution process from a native reference as "... href = ‘urn: ...’ ", there are 2 possibilities:

1. Develop a browser plug-in, that can recognize the urn schema. Such a plug-in could route the urn to a service, active on one (or more) servers, which is able to walk through the DNS chain and return the address of the resolver (typically via http);

2. Transform a native urn reference to an http one (like: ... href = "httReq: // <service>?urn: ..."), through a pre-processor or style sheet, where the urn is a parameter of the call to the service previously described.

Req: Move the solution in a separate document

To Deepen: Postpone the decision to the end of this review

28. Sez. 4.4: Use of Punycode

Req: The syntax has to be revised for the non-ASCII. It includes %-encoding but not punycode

Ans: Use UTF-8 %encoded within a URN; convert punycode in the DNS (see Dale point 2.)

29. Sez. 6.7: Ambiguity between components and features

Req:	syntax ambiguity: with one element it is not clear if it is a [component] or a [feature]

Ans: get rid of the syntax ambiguity in the manifestazione (see Dale's point 15.)

30. Annex D: Http-based LEX identifier

Req: it seems unuseful, there are no references: remove or incorporate in another doc

To Deepen: postpone the decision at the end of this revision phase

31.	Name or query? (Answer to Alexey)
Req: it is difficult to separate naming rules from the resolution aspects: split the document in two?
Req: there are several elements which are difficult to identify by a user and drive you to the construction of different URNs
To Deepen: a document has always a complete and unequivocal URN; a reference can have an incomplete URN, nevertheless useful for a retrieval service. (See also the mail sent to Dale on 9/20)

32. Name or query? (Answer to Enrico’s email)
Req: The user attempts to build a URN by some metadata he knows. The input URN is not actually a URN to the document under analysis - it is a query for some documents
To Deepen: In the RFC we can better clarify the case of 1) a complete and unequivocal URN as document identifier; 2) an incomplete URN but still useful for retrieval and that can  be used in references (See also the e-mail sent to Dale on 9/20)

---------------------------------------------------------
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-4399-665
Fax: +39-055-4399-605
email: [email-masked]
---------------------------------------------------------

> On 21 set 2017, at 09:57, Hakala, Juha E <[email-masked]> wrote:
> 
> Hello, 
> 
> I have a few comments. 
> 
> Mandate
> 
> Based on the I-D, it is not clear to me what mandate ITTIG-CNR has. URN:LEX would complement existing systems; for instance in Finland laws are identified with cool URIs. For instance, English translation of Child welfare act can be found from http://finlex.fi/en/laki/kaannokset/2007/en20070417.pdf. In the short term there might not be much interest to implement urn:lex in the Finlex system.
> 
> However, I do believe that establishing a urn namespace to sources of law can be useful in the long term. 
> 
> Administration 
> 
> ITTIG-CNR will be responsible of maintaining the uniqueness of the <jurisdiction> element. In the level of country codes this will be easy. But there may be a large number of sub-divisions within each country, and also organization-based sub-divisions. If urn:lex becomes popular, it may be a substantial task to maintain <jurisdiction> and to support organizations in making their urn:lex identifiers actionable. 
> 
> Has ITTIG-CNR estimated the amount of work required in the short term / long term?   
> 
> Semantics and syntax 
> 
> The template does not provide sufficient information about the semantics and syntax of NSS, but luckily draft-spinosa-urn-lex-11 is very detailed in that respect. 
> 
> Most URN namespaces (and traditional identifiers) have relatively simple semantics. Identifiers may be totally "dumb" (it is impossible to see from the NSS what the URN identifies) and even if the identifier has some semantic like ISBN, things are kept simple (for those in the know, ISBN reveals the country and the publisher). Other persistent identifier system are even more extreme when it comes to semantics: identifiers in ARK, Handle and DOI are usually dumb, and recommend strongly that all semantics should be avoided. 
> 
> URNs from proposed urn:lex namespace may contain a lot of information about the identified resource. For instance, I-D contains an example URN like this: 
> 
> urn:lex:eu:tibunal.justicia:sentencia:2009-06-11;33-08@original:es$text-html:juradmin.eu;jurifast:todo:anonimo 
> 
> It may be difficult, both for humans and applications, to make sense of this. 
> 
> ITTIG might consider making NSS simpler, and including at least some of the information which is now embedded in NSS (such as date and file format) into metadata records that would accompany URN:LEX identifiers. Having a lot of semantics in the NSS may overload the resolvers with tasks which should be done by passing a request to an appropriate target system. It is also more challenging to develop assignment rules for a very semantic identifier system, and to be able to use such system correctly.    
> 
> As regards syntax, I am concerned about un-encoded use of @ to indicate an expression of a work: 
> 
> local-name = work ["@" expression] ["$" manifestation]
> 
> Resolution
> 
> ITTIG-CNR intends to maintain a centralized resolution service for urn:lex. That is necessary for organization-based sub-domains. But for country-code based subdomains such as urn:lex:fi, resolvers may be established in the national level (just as in country code based sub-domains of urn:nbn). Generally, if it is not necessary to establish a global resolver service for a namespace, it is better to decentralize, since otherwise there will be a single point of failure. 
> 
> It would of course be possible to harvest URN - URL mapping tables from national lex resolvers into the central resolver maintained by ITTIG-CNR. 
> 
> All the best,   
> 
> Juha
> 
>> -----Original Message-----
>> From: urn [mailto:[email-masked]] On Behalf Of Alexey Melnikov
>> Sent: 20. syyskuuta 2017 15:13
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [urn] Request for new URN namespace review: LEX
>> 
>> Hi,
>> as responsible AD for draft-spinosa-urn-lex, I would like to request Expert
>> Review for a new URN Namespace.
>> The registration template was extracted from draft-spinosa-urn-lex-11:
>> 
>>      Namespace Identifier:
>> 
>>         "lex" requested according to [RFC8141].
>> 
>>      Version:
>> 
>>         1.0
>> 
>>      Date:
>> 
>>         2017-05-25
>> 
>>      Registrant:
>> 
>>         Institute of Legal Information Theory and Techniques (ITTIG)
>>         Italian National Research Council (CNR)
>>         Via de' Barucci, 20
>>         50127 Florence
>>         Italy
>>         e-mail: [email-masked]
>>         phone: +39 055 43995
>> 
>>         contact: Enrico Francesconi
>>         e-mail: [email-masked]
>> 
>>      Purpose:
>> 
>>         The purpose of the "lex" namespace is to assign an unequivocal
>>         identifier, in standard format, to documents that are sources
>>         of law.
>> 
>>         In the last few years a number of institutional initiatives
>>         have arisen in the field of legal document management. They
>>         were aimed at introducing standards for sources of law
>>         description and identification using XML and URI techniques,
>>         respectively (for more details see Section 1.3) LEX identifier
>>         is conceived to be general enough, so to provide guidance at
>>         the core of the standard and sufficient flexibility to cover a
>>         wide variety of needs for identifying all the legal documents
>>         of different nature, namely legislative, case-law and
>>         administrative acts. Moreover, it can be effectively used
>>         within a federative environment where different publishers
>>         (public and private) can provide their own items of an act
>>         (that is there is more than one manifestation of the same act).
>> 
>>         The LEX identifier is conceived to be: globally unique,
>>         transparent, bidirectional, persistent, location-independent,
>>         and language-neutral. It is organized into parts. The first
>>         part uses a predetermined standard to specify the country (or
>>         more generally the jurisdiction) of origin for the legal
>>         document being identified; the remainder is intended for local
>>         use in identifying documents issued in that country or
>>         jurisdiction. This second part depends only on sources of law
>>         identification system operating in that nation. For more
>>         details on the nature of the LEX characteristics and the
>>         general internal organization, see Section 1.4.
>> 
>>         The LEX name is linked to the document through specific meta-
>>         information, internally (with a tag) or externally (with a
>>         attribute) (for details on this see Section 1.5)
>> 
>>         LEX names will be used on a large scale in references either in
>>         (X)HTML document or, more generally, in XML documents format
>>         compliant with the relative DTD/XMLSchema (see Section 1.6 for
>>         more information).
>> 
>>      Syntax:
>> 
>>         The identifier has a hierarchical structure as follows:
>> 
>>                             "urn:lex:" NSS
>> 
>>         where <NSS> is the Namespace Specific String composed as
>>         follows:
>> 
>>                   NSS = jurisdiction ":" local-name
>> 
>>         where:
>> 
>>         <jurisdiction> is the part providing the identification of the
>>         jurisdiction, generally corresponding to the country, where the
>>         source of law is issued. It is also possible to represent
>>         international organizations (either states or public
>>         administrations or private entities);
>> 
>>         <local-name> is the uniform name of the source of law in the
>>         country or jurisdiction where it is issued; its internal
>>         structure is common to the already adopted schemas. It is able
>>         to represent all the aspects of an intellectual production, as
>>         it is a legal document, from its initial idea, through its
>>         evolution during the time, to its realisation by different
>>         means (paper, digital, etc.).
>> 
>>         LEX specifications gives information on the internal structure
>>         of both <jurisdiction> and <local-name>, including
>>         specifications about case sensitivity, the use of national
>>         characters and diacritics, as well as spaces, connectives,
>>         punctuation marks, abbreviations, acronyms, date formats and
>>         ordinal numbers. For more details on the internal structure and
>>         syntax of the LEX identifier, see Section 3, 4 and 5.
>> 
>>         Recently the r- and q- components have been introduced by
>>         [RFC8141]. They provide new and interesting perspectives when
>>         using URNs in a complex sector as sources of law, characterized
>>         by different versions, languages, publishers, and so on. In
>>         particular, by using the r-component at the resolver level, and
>>         therefore at the whole NSS level, you can select from the same
>>         work only expressions written in a given language, or
>>         manifestations published by a particular institutional site,
>>         etc. Using the q-component at the act metadata level, you can
>>         select versions that are valid at a particular date, or
>>         modified by a specific act, etc.
>> 
>>      Assignment:
>> 
>>         The Jurisdictional Registrar (or those it delegates) of each
>>         adhering country or organization is responsible of the
>>         definition or acceptance of the uniform name's primary elements
>>         (issuing authority and type of legal measure).
>> 
>>         Any country or jurisdiction, aiming to adopt this schema,
>>         identifies a Jurisdictional Registrar, an organization which
>>         shares and defines the structure of the optional part of the
>>         name, according to the organization of the state or
>>         institution. The process of assigning the <local-name> will be
>>         managed by each specific country or jurisdiction under the
>>         related <jurisdiction> element (details on this can be found in
>>         Section 7.2).
>> 
>>         Identifiers in the "lex" namespace are defined through a
>>         <jurisdiction> element assigned to the sources of law of a
>>         specific country or organization, and a <local-name> assigned
>>         by the issuing authority. The goal of the LEX schema is to
>>         maintain uniqueness and persistence of all resources identified
>>         by the assigned URNs. The elements values for the LEX
>>         identifier within a jurisdiction are defined by the
>>         Jurisdictional Registrar, this ensures that the constructed
>>         URNs are unique (see Section 7.3 for details on uniqueness).
>> 
>>         The persistence of identifiers depends on the durability of the
>>         institutions that assign and administer them (see Section 7.3
>>         for details on persitence)
>> 
>>      Security and Privacy:
>> 
>>         This document introduces no additional security considerations
>>         beyond those associated with the use and resolution of URNs in
>>         general.
>> 
>>      Interoperability:
>> 
>>         As open standard naming convention to identify sources of law
>>         at international level, LEX is meant to guarantee
>>         interoperability among legal information systems across
>>         national boundaries.
>> 
>>         The characteristics of the LEX naming convention facilitate
>>         legal document management as well as provide a mechanism of
>>         stable cross-collections and cross-country references, thus
>>         allowing the distribution of the legal information towards a
>>         federated architecture.
>> 
>>      Resolution:
>> 
>>         The resolution service associates a LEX identifier with a
>>         specific document address on the net. The related system will
>>         have a distributed architecture based on two fundamental
>>         components: a chain of information in DNS (Domain Name System)
>>         and a series of resolution services from URNs to URLs, each
>>         competent within a specific domain of the namespace (see
>>         Section 8.1 for more details).
>> 
>>         To cope with possible incomplete or inaccurate uniform names,
>>         the implementation of a catalogue, based on a relational-
>>         database, able to associate a URN to related URLs, is
>>         suggested, as it will lead to a higher flexibility in the
>>         resolution process. A resolver can provide names normalization,
>>         completion of inaccurate or incomplete names, and finally their
>>         resolution in network locations (see Section 8.2 and 8.3 for
>>         characteristics and behaviour of a catalogue for resolution).
>> 
>>      Documentation:
>> 
>>         None
>> 
>>      Additional Information:
>> 
>>         See [FRAN] and [SPIN].
>> 
>>      Revision Information:
>> 
>>         None
>> 
>> _______________________________________________
>> urn mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/urn

---

From: Enrico Francesconi <[email-masked]>
Date: Thu, 12 Oct 2017 23:27:12 +0200

Dear All,
   as agreed please find below our replies to the remaining remarks, those of Sabrina and Juha. We will then proceed by including the proposed changes in the new draft.

Also these new replies have been grouped with respect to each reviewer and, for each remark, we provide:
a synthesis of the requests (Req:)
our answers (Ans:)
arguments for a further analysis (To Deepen:)
Best regards
   Pierluigi and Enrico

******************************
Sabrina’s comments
******************************
33. urn NID registry
Req: Expert review should be completed before your document can be approved for publication as an RFC
Ans: waiting for the conclusion of the revision

34. Sect. 11.1 - NAPTR records
Req: approval of the IAB to implement NAPTR records. Is the host lex.ittig.cnr.it guaranteed for a long term?
To Deepen: We can contact other institutions able to guarantee long-term maintenance of a hostname, ex. “registro.it”, the CNR (Italian National Research Council) service which provides registration of the domain names .it and .eu

Req: It might be better to document the approach in such a way that that exact form of the NAPTR record is not in the I-D
Ans: provide only a generic information, ex. dns-lex.foo

35. Jurisdiction codes registry

Req: Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing
category at http://www.iana.org/protocols?

To Deepen: see point 18, anyway at the beginning there are no records in it

36. Final operations
Req: only when the RFC will be approved
Ans: we’ll wait the final RFC approval

******************************
Juha’s comments
******************************
37. Mandate
Req: Based on the I-D, it is not clear what mandate ITTIG-CNR has. 
Would URN:LEX complement existing systems?
Establishing a urn namespace to sources of law can be useful in the long term.
Ans: No specific mandate: this is a proposal for a global namespace which every system can adhere to

38. Administration
Req: ITTIG-CNR will be responsible of maintaining the uniqueness of the <jurisdiction> 
element.
Req: In the level of country codes this will be easy. But there may be a large number of sub-
divisions within each country, and also organization-based sub-divisions. If urn:lex becomes popular, it may be a substantial task to maintain <jurisdiction> and to support organizations  in making their urn:lex identifiers actionable.
Has ITTIG-CNR estimated the amount of work required in the short term / long term?
Ans: The responsibility of maintaing jurisdiction codes will be distributed at the level of each 
jurisdiction, according to a federative de-centralized approach (see sect. 7.2)

39. Semantic and syntax
Req: The template does not provide sufficient information about the semantics and syntax of NSS, but luckily draft-spinosa-urn-lex-11 is very detailed in that respect. Most URN namespaces (and traditional identifiers) have relatively simple semantics. Identifiers may be totally "dumb" (it is impossible to see from the NSS what the URN identifies) and even if the identifier has some semantic like ISBN, things are kept simple (for those in the know, ISBN reveals the country and the publisher) URNs from proposed urn:lex namespace may contain a lot of information about the identified resource It may be difficult, both for humans and applications, to make sense of this.
Ans: The suggested metadata are necessary to guarantee, unequivocal identifiers, nevertheless not all of them are mandatory. In the references, only metadata at the level of Work are required (see email on 9/20 in response to Dale’s remarks)

Req: Having a lot of semantics in the NSS may overload the resolvers with tasks which should be  done by passing a request to an appropriate target system. It is also more challenging to develop assignment rules for a very semantic identifier system, and to be able to use such 
system correctly
Ans: the hierarchical structure paves the way to a structured resolution (see e-mail to Dale on 
9/20)

Req: As regards syntax, concerns about un-encoded use of @ to indicate an expression of a work
To Deepen: not clear the motivations

40. Resolution
Req: ITTIG-CNR intends to maintain a centralized resolution service for urn:lex. Better one for  each jurisdiction
Ans: Actually not. The idea is to de-centralize the system, starting from the jurisdiction, 
until the issuing authority. We will emphasize Sections 8.1 and 8.2

Req: It would of course be possible to harvest URN - URL mapping tables from national lex 
resolvers into the central resolver maintained by ITTIG-CNR.
Ans: Currently it is not foreseen

Via de' Barucci 20
50127 Florence
Italy

Tel: +39-055-4399-665
Fax: +39-055-4399-605

> On 06 ott 2017, at 21:00, Enrico Francesconi <[email-masked]> wrote:
> 
>  Dear All,
> email: [email-masked] <mailto:[email-masked]>
>> On 21 set 2017, at 09:57, Hakala, Juha E <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hello, 
>> 
>> I have a few comments. 
>> 
>> Mandate
>> 
>> Based on the I-D, it is not clear to me what mandate ITTIG-CNR has. URN:LEX would complement existing systems; for instance in Finland laws are identified with cool URIs. For instance, English translation of Child welfare act can be found from http://finlex.fi/en/laki/kaannokset/2007/en20070417.pdf <http://finlex.fi/en/laki/kaannokset/2007/en20070417.pdf>. In the short term there might not be much interest to implement urn:lex in the Finlex system.
>> 
>>> From: urn [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Alexey Melnikov
>>> To: [email-masked] <mailto:[email-masked]>
>>> Cc: [email-masked] <mailto:[email-masked]>
>>>         e-mail: [email-masked] <mailto:[email-masked]>
>>>         phone: +39 055 43995
>>> 
>>>         e-mail: [email-masked] <mailto:[email-masked]>
>>> 
>>>      Purpose:
>>> 
>>> [email-masked] <mailto:[email-masked]>

---

From: "Hakala, Juha E" <[email-masked]>
Date: Fri, 13 Oct 2017 11:47:49 +0000

Dear Enrico,

thank you for the answers; I have some further comments below.

From: Enrico Francesconi [mailto:[email-masked]] On Behalf Of Enrico Francesconi
Sent: 13. lokakuuta 2017 0:27
To: [email-masked]
Cc: Alexey Melnikov <[email-masked]>; [email-masked]; Pierluigi Spinosa <[email-masked]>; Hakala, Juha E <[email-masked]>
Subject: Re: [urn] Request for new URN namespace review: LEX

Dear All,

  *   a synthesis of the requests (Req:)
  *   our answers (Ans:)
  *   arguments for a further analysis (To Deepen:)
Best regards
   Pierluigi and Enrico

34. Sect. 11.1 - NAPTR records
Req: approval of the IAB to implement NAPTR records. Is the host lex.ittig.cnr.it<http://lex.ittig.cnr.it> guaranteed for a long term?
To Deepen: We can contact other institutions able to guarantee long-term maintenance of a hostname, ex. “registro.it<http://registro.it>”, the CNR (Italian National Research Council) service which provides registration of the domain names .it and .eu
Juha: a name like lex.registro.it would be better than lex.ittig.cnr.it, which has a lot of semantics in it. Here in Finland, the national library runs a URN resolver at the URI http://urn.fi, which is as neutral as possible.
Req: It might be better to document the approach in such a way that that exact form of the NAPTR record is not in the I-D
Ans: provide only a generic information, ex. dns-lex.foo

36. Final operations

******************************
Juha’s comments
******************************
37. Mandate
Req: Based on the I-D, it is not clear what mandate ITTIG-CNR has.
Would URN:LEX complement existing systems?
Establishing a urn namespace to sources of law can be useful in the long term.
Ans: No specific mandate: this is a proposal for a global namespace which every system can adhere to
Juha: OK. Since ITTI-CNR has no specific mandate, it is easy to see a situation where the coordinator responsibility is passed to another organization in Italy or even elsewhere. Therefore it is important to have a neutral domain like lex.registro.it or something similar.
38. Administration
Req: ITTIG-CNR will be responsible of maintaining the uniqueness of the <jurisdiction>
element.
Req: In the level of country codes this will be easy. But there may be a large number of sub-
divisions within each country, and also organization-based sub-divisions. If urn:lex becomes popular, it may be a substantial task to maintain <jurisdiction> and to support organizations  in making their urn:lex identifiers actionable.
Has ITTIG-CNR estimated the amount of work required in the short term / long term?
Ans: The responsibility of maintaing jurisdiction codes will be distributed at the level of each
jurisdiction, according to a federative de-centralized approach (see sect. 7.2)’
Juha: efficient de-centralization often requires at least some level of central co-ordination. In this case, I think it would be useful to maintain a central registry of Jurisdictional Registrars. This would make it easy for any organization which wishes to use urn:lex to find out if there already is a registrar for their country or jurisdiction. The registry would also minimize the risk of having multiple organizations in one country accidentally adopting the registrar role.
I wonder if it would be useful to mention in chapter 10 (Community considerations) of draft-spinoza-urn-lex something about how potential registrars may find information about this system. A completely new identifier system usually needs some promotion in order to become popular. Similarly, chapter 7.2 might mention promotion of URNs and URN:LEX as one of the registrar tasks.

39. Semantic and syntax

Req: Having a lot of semantics in the NSS may overload the resolvers with tasks which should be  done by passing a request to an appropriate target system. It is also more challenging to develop assignment rules for a very semantic identifier system, and to be able to use such
system correctly
Ans: the hierarchical structure paves the way to a structured resolution (see e-mail to Dale on
9/20)
Juha: yes, I do understand that some semantics is required for resolution. URN:NBN, which I have registered, uses (mandatory) country code and additional information to locate the right resolver.
But in lex, semantics goes much beyond what is required for finding a resolver. And some of the assumptions about semantics may not be valid in all jurisdictions. For instance, you say

Each version is characterized by the period of time during which that
   text is to be considered as the valid text (in force or effective).
Finland, for instance, cannot provide this kind of date/time information about validity of legal documents.
All Finnish laws are available online for free from a system called Finlex. The URI of the current Finnish copyright act in Finnish is
http://finlex.fi/fi/laki/ajantasa/1961/19610404
and in Swedish
http://finlex.fi/sv/laki/ajantasa/1961/19610404
Note that 19610404 is not a date, but act number 404 in 1961.
Lex work level urn could then be something like:
urn:lex:fi:oik:laki:1961;0404
where OIK refers to the Ministry of justice and LAKI to an act.
Since 1961, Copyright act has been amended many times, but URI has remained the same ever since the online system was established. A user who retrieves the text, can see the changes and when there were made. But the original version is no longer there.
Chapter 6 has a lot of examples, but they are all similar with respect to e.g. date. It would be good to have more diversity among examples, so that potential users do not misunderstand the requirements.
Syntax might be made simpler by using URN f-component to identify partitions. Then for instance the URN in this example:

to refer to the paragraph 3 of the article 15 of the French

   Act of 15 may 2004, n. 106, the reference is written

   "urn:lex:fr:etat:loi:2004-05-15;106~art15;par3").
might become
 urn:lex:fr:etat:loi:2004-05-15;106#art15par3
if the text encoding of the identified document allows that. This would also simplify things from retrieval point of view; it is likely that even with the original URN the entire text of the legal document will be retrieved, and then it is up to the browser to take the user to the correct place. With URI fragment that is technically simple; with syntax like ~art15;par3 it may be necessary to build the required functionality to the user interface.

Juha: the motivation was just to say that it is necessary to percent encode special characters which cannot be expressed in HTTP URIs in unencoded form, such as @.

Juha: it should be possible to make resolvers in urn:lex aware of each other, if there is a central registry of resolvers. This would make it possible, at some point in the future, to harvest the mapping tables from all urn:lex resolvers. But I do understand that there is currently no plan to do such a thing. However, within jurisdictions such co-operation may be necessary even in short term.

All the best,

Juha

Via de' Barucci 20
50127 Florence
Italy

Tel: +39-055-4399-665
Fax: +39-055-4399-605
email: [email-masked]<mailto:[email-masked]>
---------------------------------------------------------

On 06 ott 2017, at 21:00, Enrico Francesconi <[email-masked]<mailto:[email-masked]>> wrote:

 Dear All,

  *   a synthesis of the requests (Req:)
  *   our answers (Ans:)
  *   arguments for a further analysis (To Deepen:)

Pierluigi and Enrico

B. Minor points

6. Abstract

9. Sez. 2: Syntax label

12. Examples

A. Major items

25. Name or query?

B. Minor points

Via de' Barucci 20
50127 Florence
Italy

Tel: +39-055-4399-665
Fax: +39-055-4399-605
email: [email-masked]<mailto:[email-masked]>
---------------------------------------------------------

On 21 set 2017, at 09:57, Hakala, Juha E <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

I have a few comments.

Mandate

Administration

Semantics and syntax

Resolution

All the best,

Juha

-----Original Message-----
From: urn [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: 20. syyskuuta 2017 15:13
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [urn] Request for new URN namespace review: LEX

Hi,

     Namespace Identifier:

     Version:

        1.0

     Date:

        2017-05-25

     Registrant:

        Institute of Legal Information Theory and Techniques (ITTIG)
        Italian National Research Council (CNR)
        Via de' Barucci, 20
        50127 Florence
        Italy
        e-mail: [email-masked]<mailto:[email-masked]>
        phone: +39 055 43995

        contact: Enrico Francesconi
        e-mail: [email-masked]<mailto:[email-masked]>

     Purpose:

     Syntax:

                            "urn:lex:" NSS

        where:

     Assignment:

     Security and Privacy:

     Interoperability:

     Resolution:

     Documentation:

        None

     Additional Information:

        See [FRAN] and [SPIN].

     Revision Information:

        None

_______________________________________________
urn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/urn

---

From: Enrico Francesconi <[email-masked]>
Date: Tue, 24 Oct 2017 22:33:46 +0200

Dear Juha,
   thanks for your reply. Here below (inline) our comments (and sorry for being late to get back to you).

Please don’t hesitate to send any further comment, if any.

Finally, we are about to finalize version 12 of the urn:lex draft, which takes into account your remarks. If you agree we will send it to you all soon, before submission.

Best regards
   Pierluigi and Enrico

Via de' Barucci 20
50127 Florence
Italy

Tel: +39-055-4399-665
Fax: +39-055-4399-605

> On 13 ott 2017, at 13:47, Hakala, Juha E <[email-masked]> wrote:
> 
> Dear Enrico,
>  
> From: Enrico Francesconi [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Enrico Francesconi
> To: [email-masked] <mailto:[email-masked]>
> Cc: Alexey Melnikov <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Pierluigi Spinosa <[email-masked] <mailto:[email-masked]>>; Hakala, Juha E <[email-masked] <mailto:[email-masked]>>
> Req: approval of the IAB to implement NAPTR records. Is the host lex.ittig.cnr.it <http://lex.ittig.cnr.it/> guaranteed for a long term?
> To Deepen: We can contact other institutions able to guarantee long-term maintenance of a hostname, ex. “registro.it <http://registro.it/>”, the CNR (Italian National Research Council) service which provides registration of the domain names .it and .eu
> Juha: a name like lex.registro.it <http://lex.registro.it/> would be better than lex.ittig.cnr.it <http://lex.ittig.cnr.it/>, which has a lot of semantics in it. Here in Finland, the national library runs a URN resolver at the URI http://urn.fi <http://urn.fi/>, which is as neutral as possible.  

We agree on that. Moreover registro.it <http://registro.it/> is maintained by a CNR institute in Italy which is also responsible for the registry of the domain names .eu
Anyway the final name will be decided by the organization which will maintain the lex namespace.

> category at http://www.iana.org/protocols? <http://www.iana.org/protocols?>
> 
> Juha: OK. Since ITTI-CNR has no specific mandate, it is easy to see a situation where the coordinator responsibility is passed to another organization in Italy or even elsewhere. Therefore it is important to have a neutral domain like lex.registro.it <http://lex.registro.it/> or something similar.

See above

> I wonder if it would be useful to mention in chapter 10 (Community considerations) of draft-spinoza-urn-lex something about how potential registrars may find information about this system. A comple…

We agree on that: in the Jurisdiction Registry a field is foreseen including the information of the Registrars. Querying the Registry it will be possible to check if a jurisdiction has been registered and who is the registrar.
Moreover, the promotion of urn:lex namespace is definitely important: we are confident that each new registrar can promote the use of urn:lex within its jurisdiction.

> http://finlex.fi/fi/laki/ajantasa/1961/19610404 <http://finlex.fi/fi/laki/ajantasa/1961/19610404>
> and in Swedish
> http://finlex.fi/sv/laki/ajantasa/1961/19610404 <http://finlex.fi/sv/laki/ajantasa/1961/19610404>

Urn:lex semantics is more oriented to legal document identification rather than to the resolution routing. Such semantics is complex because it is complex the legal identification framework. In the Finnish system it seems that only the in-force version is provided to the user, but in other jurisdictions it is important to identify the previous versions too (for example in case we need to access a version of a law which is in-force at the date when a given crime or administrative offence to be judged has happened).

In paragraph 6.8 of the urn:lex draft all the reasons why we used ‘~’ rather than ‘#' are explained.
Anyway the possibility to process forms like ~art15;par3 is up to the resolver. 
Moreover the possibility to identify a hierarchy in the subdivisions allows to retrive a subdivision up to the available granularity level (in the example: the possibility to retrieve art15 and not par3 if this one is not available because not marked-up)

> Juha: the motivation was just to say that it is necessary to percent encode special characters which cannot be expressed in HTTP URIs in unencoded form, such as @.

For the users this problem will be transparent. 

> Juha: it should be possible to make resolvers in urn:lex aware of each other, if there is a central registry of resolvers. This would make it possible, at some point in the future, to harvest the m…

We don’t think it is the case to include this requirement in the draft, even if it’s definitely an interesting future possible development.

> On 06 ott 2017, at 21:00, Enrico Francesconi <[email-masked] <mailto:[email-masked]>> wrote:
>  
>  Dear All,
> Based on the I-D, it is not clear to me what mandate ITTIG-CNR has. URN:LEX would complement existing systems; for instance in Finland laws are identified with cool URIs. For instance, English translation of Child welfare act can be found fromhttp://finlex.fi/en/laki/kaannokset/2007/en20070417.pdf <http://finlex.fi/en/laki/kaannokset/2007/en20070417.pdf>. In the short term there might not be much interest to implement urn:lex in the Finlex system.
> 
> https://www.ietf.org/mailman/listinfo/urn <https://www.ietf.org/mailman/listinfo/urn>