[urn] urn:lex draft v. 12

[Enrico Francesconi <[e-mail]>]

Dear All,
   we have just finalized and uploaded in the IETF website a new version (v.12) of the urn-lex draft. This new version follows your remarks and our change proposals
https://datatracker.ietf.org/doc/draft-spinosa-urn-lex/ <https://datatracker.ietf.org/doc/draft-spinosa-urn-lex/>

In particular we have organized your remarks in three groups according how they have been addressed: 

a) fixed according to the proposed solution
b) fixed in a way similar to the proposed solution (details in the the draft)
c) not yet fixed, waiting for agreement on a solution

Here below are the details of your remarks (as listed in our previous emails) including our proposals and classified in one of the 3 groups.

Waiting for your feedback
Best regards
   Pierluigi and Enrico


1. Annex A: Use of alfanum, etc.

Req: Simplifying syntax with non-terminal elements
a) 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 puny code incompatible
a) 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
a) Ans: declare that the syntax conforms to RFC 8141
b) 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"
b) Ans: To keep backward compatibility with existing applications in some jurisdictions, the "lex" NID syntax does not include the use of the 
   character "/" in this version.

4. Sez. 11.2: The pseudo-TLD ".lex"

Req: it no longer works if .lex is assigned
a) 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
a) Ans: 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
b) To Deepen: Common problem with all components where a domain name is indicated. Think of a solution through aliases
 
b) Ans: Since publishers' domain names may vary over time, manifestations already assigned by a publisher remain 
     unchanged even if the identified object is no longer accessible. In this case, in order to make its materials accessible, the publisher 
     will have to create for each of them a new manifestation with the new domain name;



6. Abstract

Req: World Wide Web Consortium reference for resource identification
a) Ans: Replace W3C with IETF


7. Sez. 1.1: The Purpose of Namespace "lex"

Req: Useful when mapped on HTTP URLs and not URIs
b) 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
a) changed URIs with URLs. We have retained the URI indication when it comes to identifier and not locator


8. Sez. 1.4: General Characteristics of the System

Req: SHOULD seems more appropriate than MUST
a) 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
a) 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
a) 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
a) To Deepen: Check rules for writing section titles
a) Ans: we checked all the titles and capitalized the nouns

Req: representation of non-ASCII characters in RFCs
b) Ans: right: the guidelines suggest using the Unicode convention U + XXXX
b) Ans: the guidelines suggest using the Unicode convention U + XXXX, then we brought 4 hexadecimal digits after U +


12. Examples

Req: Are the examples shown real or hypothetical?
a) 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
a) Ans: add "Western" before "Arabic numbers"


14. Sez. 6.1: Basic Principles

Req: substitution suggestion of "by parser" with "from parser”
a) 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
a) Ans: Correct syntax according to Dale's suggestions in the presence of features, component (if absent) is set to "all" (whole document)
a) Ans: Correct syntax in a conforming manner (even if not equal) 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

b) To Deepen: It is true, but it depends on the level of granularity of the identification systems (documents or also partitions?).
b) Ans: It is true, but it depends from the type of text marking; we have tried to explain better as it allows you to identify an element or just a point


17. Sez. 8.1: The General Architecture of the System

Req: Incomplete reference: RFC 3403 only defines NAPTR records
a) 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
a) 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, …
a) Ans: review the syntax, according to Dale's suggestions. We tested the syntax with Bill's ABNF Parser


20. Annex A: Summary of the syntax of the uniform names of the "lex" namespace

Req: syntax error for % encoded
b) To Deepen: Correct the % encoded syntax (see RFC 3261 par.25.1)
b) Ans: Correct the % encoded syntax in a more simple way, as other RFCs


21. Annex A, Sec. B1.4 (Indication of the Body) and B1.5 (Indication of the Function)

Req: ambiguity between body / function / office
a) Ans: Correct syntax to eliminate ambiguities


22. Annex D and D1: Http-based LEX identifier

Req: HTTP and non-HTTP-based
a) Ans: delete "based"

Req: Same names used for http and urn elements: same semantics but different syntax
b) Ans: Use same names in http and urn elements (that have the same syntax), maybe change delimiters
 

23. Sez. D1: Http-based URI

Req: Wrong Link to Linked Data
b) To Deepen: Correct reference to Linked Data
b) Ans: the reference to Linked Data is to Berners Lee article 


24. Scope of the document

Req: Doc. describes not only URN but a fully federated system. Better divide the two documents
c) 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
c) To Deepen: Document: URN Full and Unique; references: URN incomplete, but useful (see e-mail sent to Dale on 9/20)


26. Sez. 11.2: Jurisdiction-code Registration

Req: Re-assigning ccTLD: using the solution of international institutions?
b) 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
a) 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
c) 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
c) 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
a) 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]
a) Ans: get rid of the syntax ambiguity in the manifestation (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 
c) To Deepen: postpone the decision at the end of this revision phase


31.	Name or query? 
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
c) 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? 
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
b) Ans: 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)


33. urn NID registry
Req: Expert review should be completed before your document can be approved for publication as an RFC
c) 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?
b) Ans: We contacted 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
a) Ans: provide only a generic information, <urn-lex.zone.org>


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?

c) 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 
c) Ans: we’ll wait the final RFC approval


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.
c) 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? 

b) 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.
b) 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
b) 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
c) To Deepen: not clear the motivations
b) Ans: we added that unacceptable characters in URI are to be escaped


40. Resolution
Req: ITTIG-CNR intends to maintain a centralized resolution service for urn:lex. Better one for  each jurisdiction
b) 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. 
b) Ans: Currently it is not foreseen




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