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