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-11
Reviewer: Paul Kyzivat
Review Date: 2017-09-14
IETF LC End Date: 2017-09-14
IESG Telechat date: TBD
Summary:
This draft has serious issues, described in the review, and needs to be
rethought.
General Comments:
I had great difficulty deciding how to approach this review. Rather that
pick at lots of small points I have elected to focus on the the ones I
find most notable.
As part of doing this review I investigated prior discussions of prior
versions of this draft (by Barry Leiba, Patrik Fältström and Dale
Worley), that have occurred over several *years*. I found some
substantial issues raised that IMO were not adequately addressed. The
following is a useful starting point into that discussion:
https://www.ietf.org/mail-archive/web/urn-nid/current/msg01270.html
I have borrowed some points from that discussion and from other
information that Dale Worley sent privately to you.
Issues:
Major: 2
Minor: 5
Nits: 0
(1) MAJOR: Scope of the document
This document is nominally the specification of a URN. However the
actual scope of the document is much broader - partially specifying a
complete system for federating the naming and access to legal documents.
Much of the contained information goes well beyond what is useful for
defining the URN, and yet is frustratingly incomplete when it comes to
defining the broader system.
It would be better to split this into multiple documents. One would
cover solely the specification of the URN, while the other(s) would
define the broader system in which the URN operates.
(2) MAJOR: Name or query?
A URN is by definition a *name*. Some parts of this document do focus on
the lex URN as a name. But the document also proposes using the lex URN
as a *query*. The following text from section 2 highlights this:
"To cope with possible incomplete or inaccurate uniform names,
the implementation of a catalogue, based on a relational-
database, able to associate a URN to related URLs, is
suggested, as it will lead to a higher flexibility in the
resolution process. A resolver can provide names normalization,
completion of inaccurate or incomplete names, and finally their
resolution in network locations (see Section 8.2 and 8.3 for
characteristics and behaviour of a catalogue for resolution)."
This behavior is inconsistent with the intent of URNs.
(3) MINOR: Jurisdiction identifiers:
URNs are required to remain valid indefinitely. But country codes are
occasionally reassigned. The draft doesn't fully resolve this problem.
Specifically, section 11.2 doesn't address the case where a request
comes from a jurisdiction that corresponds to a country and the
jurisdiction code is the same as a top level ccTLD, which *is* already
registered for a different entity.
A solution could be to simply follow the rules for a multinational or
international organization in this case.
The suggestion in section 11.2 to use names of the form '<name>.lex' in
effect appropriates 'lex' as a TLD, even though it has not been so
assigned. Or else it presumes that it never will be assigned. This is a
bad assumption. Some other naming convention should be chosen for this case.
(4) MINOR: Full utility of this URN form as described in this document
seems to require a browser extension for resolving lex urns, or for urns
in general. It is not at all clear that such an extension will be widely
deployed as part of standard browser distributions, limiting this
function to users who extend their browser with a plugin. And browser
support for plugins is decreasing. I would hope to see an explanation
for using lex URNs without such a browser extension.
However, the mechanism for resolving URNs probably belongs in a
companion document.
(5) MINOR: Use of Punycode
The document calls for use of %-encoding to handle non-ASCII characters.
The inclusion of %-encoding within <alphanum> allows this widely.
However, section 4.4 recommends that non-ASCII characters be handled by
Punycode-encoding them. Because Punycode contains "-" it isn't valid
according to the current syntax in the many fields that are defined as
'alfanum *normal'.
The inclusion of Punycode appears to have been an afterthought. If it is
to be supported then it needs much better specification.
(6) MINOR: Ambiguity between components and features
The syntax for <manifestation>:
manifestation = format *(";" specification)
":" editor *(";" specification)
[":" component *(";" specification)]
[":" feature *(";" specification)]
is syntactically ambiguous in that in a form like:
urn:lex:it:stato:legge:2000-04-03;56
$application-pdf;1.7:parlamento.it:xxx
it is not clear whether "xxx" is a "component" or a "feature".
(7) MINOR: Purpose of the Attachment D
There are no references to Attachment D within the body of the document,
and it seems entirely unnecessary to the understanding of the document.
This ought to be removed - perhaps incorporated into another document
describing a proposed system for using and resolving lex URNs.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
