Paul, thanks for your review. I have cc’ed you on my DISCUSS ballot. Best, Alissa
> On Feb 18, 2020, at 1:29 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > > 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) > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
