Telechat Review of draft-spinosa-urn-lex-13
review-spinosa-urn-lex-13-genart-telechat-kyzivat-2020-02-18-00
Request | Review of | draft-spinosa-urn-lex |
---|---|---|
Requested revision | No specific revision (document currently at 24) | |
Type | Telechat Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2020-02-18 | |
Requested | 2020-02-07 | |
Authors | PierLuigi Spinosa , Enrico Francesconi , Caterina Lupo | |
I-D last updated | 2020-02-18 | |
Completed reviews |
Opsdir Last Call review of -11
by Scott O. Bradner
(diff)
Genart Last Call review of -11 by Paul Kyzivat (diff) Opsdir Telechat review of -13 by Scott O. Bradner (diff) Genart Telechat review of -13 by Paul Kyzivat (diff) |
|
Assignment | Reviewer | Paul Kyzivat |
State | Completed | |
Request | Telechat review on draft-spinosa-urn-lex by General Area Review Team (Gen-ART) Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/gen-art/xR44OWrdejWK77_8CywYhuYsvZo | |
Reviewed revision | 13 (document currently at 24) | |
Result | Ready w/issues | |
Completed | 2020-02-18 |
review-spinosa-urn-lex-13-genart-telechat-kyzivat-2020-02-18-00
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-spinosa-urn-lex-13 Reviewer: Paul Kyzivat Review Date: 2020-02-18 IETF LC End Date: 2017-09-14 IESG Telechat date: 2020-02-18 Summary: This draft is on the right track but has open issues, described in the review. General: I did a Last Call review on version -11 three years ago. Given the amount of time that has passed, and the extent of changes, I'm surprised that there wasn't another Last Call prior to scheduling the Telechat! I had difficulty classifying the severity of the issues. Individually most of them may be minor, but in aggregate they imply that IMO the document still requires a lot of work. Issues: Major: 1 Minor: 15 Nits: 2 1) MAJOR: Structure & ordering of the document In spite of my earlier experience with this document I found it very difficult to read in a single front to back pass. In retrospect, I think it would have made much more sense if I had read Section 7 first. A major problem was that I got the impression it was a goal that an arbitrary legal document reader should be able to construct a valid LEX URN to that document from information readily available to him, typically in the body of the document itself. Yet I found many places where terms must be chosen in ways that are not deterministic. In retrospect, especially after reading Section 7, I tentatively reached the conclusion that my first impression was wrong. Instead, it appears that an expert (probably within the Jurisdiction Registrar) must choose the LEX URN representation(s) for the legal document. This can then be incorporated into the document and/or some metadata about the document that is potentially available to those who later have need to reference the document. I'm not sure I'm right about this. How this is intended to work should be spelled out early in the document. I suggest moving Section 7 early in the document, and elaborating it to cover this. Section 3 (Registration Template) is very hard to follow when reading the document front to back. Understanding it requires information that hasn't yet been provided. In particular, section 3.1 gives an overview of the syntax of 'jurisdiction', but not for 'local-name'. It then goes on to present examples of full lex URNs. I suggest that it would be helpful to move sections 2 and 3 to a position later in the document - somewhere after section 5. Near or in Section 11 (IANA considerations) would be a good place. 2) MINOR(?): Encoding national characters and diacritic signs Section 4.4 has guidelines for encoding national characters and diacritic signs for compatibility with DNS. I'm not qualified to evaluate whether these guidelines are in agreement with best practice for DNS. If it hasn't already, this document should be reviewed and approved by relevant experts. 3) MINOR: Section 5 (Specific Syntax and Features of the LEX Identifier): It isn't clear to me what specific components of the syntax are being addressed in this section. I *think* these apply to 'jurisdiction-unit'. Can you please make this clear? I'm concerned that most of the specifications here are only RECOMMENDED. Who makes the decision whether to follow these rules, and how can it be assured that they are followed consistently? It is a problem if a consistent approach to these isn't followed. For instance, when a reader of a document is trying to create a LEX URN manually from a reference in the text, how will he know whether to follow the recommendation or not? (However, if the expectation is that an expert constructs the URN then this is less of a concern.) 4) MINOR: Annexes and Sub-Annexes: When I read Section 6.4 the first time I was confused about the significance of multiple annexes in a name - whether this refers to peer annexes of the main document, or to a sub-annex of an annex. I later learned (in section 7) that it means sub-annexes. This is an example of why the doc needs reordering. Or else spell this out in this section. 5) MINOR: "original" as document version Both sections 6.6 and C1.2 discuss using "original" as the document version to identify the original version of the document. But this is allowed to be written in different languages. However it doesn't specify how the language for this is chosen. How can someone constructing the URN from a textual reference decide which spelling to use? More specification is needed. 6) MINOR: Manifestation: The following in section 6.7: Note that the value "all" can be expressed by language-dependent equivalents. To indicate possible features or peculiarities, each main element of the manifestation MAY be followed by further specifications, for example as regards <format> the version, for <editor> the archive name and the electronic publisher, etc. doesn't appear to be normative regarding what the "specification" means for any particular element. Rather it merely gives "examples". There needs to be normative text defining the semantics. (Section 7 clarifies things to an extent, but also isn't normative.) Also, as with "original" above, the language to be used for "all" isn't specified. Also, by using semicolon to separate the format from its specification you have excluded using semicolon to denote mime type parameters, as is conventionally done. (E.g., in Content-Type header fields.) Some mime types have mandatory parameters, so this will exclude using those types at all. Some discussion of mime type parameters is needed. The following example: - XML format (version 2.2 DTD NIR) of the text of the act and PDF format (version 1.7) of the "Figura 1" (figure 1) contained in the body, edited by the Italian Senate: "urn:lex:it:stato:legge:2000-04-03;56$text-xml;dtd-nir- 2.2:senato.it:testo" introduces further confusion, by mapping "XML format (version 2.2 DTD NIR)" to "text-xml;dtd-nir-2.2". I see nothing that specifies how to perform this mapping. Nor how to find out what this means. It appears to be very ad hoc. Also, the XML Format is normally encoded within the XML itself, so why should it be encoded in the LEX URN? Then I had trouble deciphering the following example: the Spanish URN of the html format of the whole Judgement of the European Court of Justice n. 33/08 of 11/06/2009, in Spanish version, published in the Jurifast data base in anonymized form: "urn:lex:eu:tribunal.justicia:sentencia:2009-06-11;33- 08@original:es$ the Spanish URN of the html format of the whole Judgement of the European Court of Justice n. 33/08 of 11/06/2009, in Spanish version, published in the Jurifast data base in anonymized form: "urn:lex:eu:tribunal.justicia:sentencia:2009-06-11;33- 08@original:es$text-html:juradmin.eu;jurifast:todo:anonimo" As best I understand, "todo" is the 'component' and "anonimo" is the 'feature. I discovered the Spanish "todo" means "everything" in English. So apparently this means the anonymized form of everything. But how would someone know to use "todo" or "everything"? Is the language for this word determined by language tag in "original:es"? And even if the language is well defined, how is the term to use ("everything" rather than "all", etc.) determined? Again this seems underspecified, and may lead to interoperability problems. (Is this covered by section 7.2 that puts this responsibility on the Jurisdictional Registry? If so, it would be good to have an exhaustive list of things that the Jurisdictional Registry must define.) 7) MINOR: Partition Identifiers: It appears that section 6.8 is attempting to invent a one-off mechanism for partition identifiers that is entirely redundant to the r- and q- components of a URI as specified in RFC8141. ISTM it would be better to embrace those mechanisms. 8) MINOR: Resolution Examples: While the high level intent of section 8.1 is reasonably clear, the details are not. Some concrete examples showing relevant DNS records would be extremely helpful. 9) MINOR: Catalogs for Resolution: While a catalog db for lex URN resolution (section 8.2) could offer some advantages, it will be only as good as the content that populates it. For such a catalog to be well populated it will probably need to be fed the results of applying a good resolver algorithm, such as described in section 8.3. If you have that, then the db really only serves as a optimizer. I think this section needs better explanation. 10) MINOR: Normalizing the Partition ID: Section 8.3 says to separate the Partition ID and then use it determine what to return. Not mentioned is that the partition ID itself may be inaccurate, so normalization of it is also likely to be required. This may even involve a trial and error mechanism to try different transformations of the partition ID until the one that works is found. Again it would be helpful for the document to mention this. 11) MINOR: Returning multiple manifestations: The following in Section 8.3: Lacking more specific indications, the resolver SHOULD select the best (most recent) version of the requested source of law, and provide all the manifestations with their related items. A more specific indication in the uniform name to be resolved will, of course, result in a more selective retrieval, based on any suggested expression and/or manifestations components (e.g. date, language, format, etc.). implies that multiple items are to be returned. The form to return these isn't specified. Are these to be returned as a single document containing all this information? (May or may not be possible.) Or as multiple documents? (Represented how?) For instance, if I'm looking for text/plain and there are multiple annexes, will they come back as a multipart/mixed, or a zip of the parts, or simply a concatenation of all the pieces as a single text/plain? How will it know what I'm prepared to receive? (For some retrieval protocols the types I can receive are specified in the request.) 12) MINOR: Jurisdiction-code registration Section 11.2 doesn't address what is to happen when a domain name that has been used as a jurisdiction code is assigned to a different entity. (And can this also happen for ccTLDs?) The old owner of the domain name may then get a different domain name. And both the old and new entities may want to assign LEX URNs. This situation needs to be addressed. And regarding the IANA Jurisdiction-code Registry, it is common practice when defining a new IANA registry to supply a template for what must be supplied. Perhaps the first bullet list in section 11.2 is intended to be that, but it is pretty vague, especially regarding the registrant. It should be more explicit about what information is to be provided and the format for how it is to be provided in a new registration and how it is to be represented in the IANA registry. 13) MINOR: jurisdiction-code syntax: I suspect the following syntax in Attachment A: jurisdiction-code = 2*alf-dot is not exactly what you want, though I'm not certain exactly what you do want. I suspect you are trying to forbid a code that is a single character. If so, then the following might be better: jurisdiction-code = alfanum alf-dot 14) MINOR: ABNF ambiguities (Attachment A): First, the rule 'specification' is used in a variety of contexts. But the semantics differ with the context. I strongly recommend making them separate rule names that correspond to the semantics they denote. And then refer to the corresponding names in the text. Also, the following is ambiguous: ;------------------------------------------------------------------- ; Structure of the <authority> element ;------------------------------------------------------------------- authority = issuer *("+" issuer) issuer = (institution *(";" body-function)) / office institution = alf-dot body-function = alf-dot office = alf-dot Something matchng 'alf-dot' could be either an 'institution' or a 'office'. This can present problems when using tools to generate a parser from the ABNF. 15) MINOR: Purpose of Attachment D (Http LEX Identifier): There are no references to Attachment D within the body of the document, and it seems entirely unnecessary to the understanding of the document. And it doesn't appear to be normative. Consideration should be given to moving this to another document describing a system for using and resolving LEX URNs. If it is to be retained in this document, then there should be a reference to it from within the body of the document, explaining its reason for being included. 16) NIT: Use of "However": Section 3.2 says: The "lex" NID syntax conforms to [RFC8141]. However, a series of characters are reserved to identify elements or sub-elements, or for future extensions of the identifier. The use of "However" here is confusing. It seems to suggest that this is an exception to conformance with RFC8141. If that is not what is intended, then this should be reworded. For instance: The "lex" NID syntax conforms to [RFC8141]. A series of characters are reserved to identify elements or sub-elements, or for future extensions of the identifier. Hence only a subset of the syntax allowed by RFC8141 is available for definition of local-names. 17) NIT: Use of "Recently" There are a couple of uses of "recently" that won't (haven't) age(d) well: In the following text from section 2: The use of r- and q- components, recently introduced by [RFC8141], with LEX URNs is not defined in this document. RFC8141 is now almost three years old. I don't think you can still call this recent. There is a similar issue in the following from Section D1: Http URIs have been recently promoted as stable and location- independent identifiers [RFC3986]. This same wording was in version -11 from three years ago, so it isn't very recent. And if the "recent" reference is really in RFC3986 then it is much older. In both cases I think you should find more suitable wording that recognizes that these are by now well established. (THE END)