Skip to main content

Telechat Review of draft-spinosa-urn-lex-13

Request Review of draft-spinosa-urn-lex
Requested revision No specific revision (document currently at 21)
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
Reviewed revision 13 (document currently at 21)
Result Ready w/issues
Completed 2020-02-18
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 

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


This draft is on the right track but has open issues, described in the 


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.


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 

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:

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

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 

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.