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

[Enrico Francesconi <[e-mail]>]

 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: [phone]
Fax: [phone]
email: [e-mail]
---------------------------------------------------------

> On 21 set 2017, at 09:57, Hakala, Juha E <[e-mail]> 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:[e-mail]] On Behalf Of Alexey Melnikov
>> Sent: 20. syyskuuta 2017 15:13
>> To: [e-mail]
>> Cc: [e-mail]
>> 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: [e-mail]
>>         phone: [phone]
>> 
>>         contact: Enrico Francesconi
>>         e-mail: [e-mail]
>> 
>>      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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/urn