Subject: [Gen-art] Gen-ART Last Call review of draft-spinosa-urn-lex-11

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Sep 2017 11:45:36 -0400

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.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 14 Sep 2017 17:25:01 +0100

Hi Paul,
I am not an author, but let me disagree with one of your reported issues:

> On 14 Sep 2017, at 16:45, Paul Kyzivat <[email-masked]> wrote:
> 
> 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:
> 

I think the document is only talking about names. Association with URLs is the result of URN resolution process, which is a part of URN architecture. If this is not clear, I think it should be clarified (if authors agree that this is the intent).

Best Regards,
Alexey

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Sep 2017 13:04:07 -0400

Hi Alexey,

> I think the document is only talking about names. Association with URLs is the result of URN resolution process, which is a part of URN architecture. If this is not clear, I think it should be clar…

I found it very difficult to sort out what was fundamental and normative 
regarding the URN from the parts that are aspirational about resolution 
and use. Hence my recommendation that this document be split. Such a 
split may well resolve this issue for me.

I only pointed to this one place, but there are other places that 
express an intention that it be possible to "guess" or recreate a lex 
URN based on metadata about the document. That only makes sense if then 
intent is that the resulting URN be resolvable to the document. But 
there are so many elements to chosen and used or not for a given 
document that reasonable people are likely to arrive at different forms 
of the URN. That ties in to the quote above.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Sep 2017 14:27:30 -0400

Enrico,

On 9/15/17 12:03 PM, Enrico Francesconi wrote:
> Dear Paul and Alexey,
>     thanks for your remarks. We are pleased to work with you to fix all the issues still remaining in the current urn:lex version.
> 
> As regards the quoted issue on names or queries, the urn:lex draft actually talks about names. As pointed out by Alexey, any reference to queries is meant to clarify the principles of the resolution process for urn:lex, moreover the section “resolution” is expected in the draft template.
> 
> As regards Paul’s remarks on the possibility to arrive at different forms of urn:lex starting from document metadata, this is actually meant to facilitate interoperability. A typical example is the possibility to create equivalent urn:lex names in different languages. Moreover, the addressed flexibility is also meant to cope with promoting interoperability when, for example, it is necessary to link legal resources from incomplete textual citations. In this case the suggested behavior of the resolution system can facilitate the discovery of the target resource.

I still have trouble understanding this except as a form of query.

Let me try to explain. I'm drawing a distinction between two classes of 
users for these URNs:

1) The authority who is formally assigning lex URNs to documents. The 
authority can choose which of the various optional parts of the urn are 
applicable to a given document. A question is whether the goal of the 
authority should be to choose the "best" name for the document, or 
should attempt to assign every possible name that any reasonable person 
might guess to be the name of the document.

2) Someone interested in referencing the document. Some people may only 
be interested in obtaining a name to use to point at the document, but 
that always implies an assumption that someone will want to retrieve the 
document using that name, so I'll assume that the goal here is to 
retrieve the document.

2a) One possibility is that this person is given the name by someone who 
obtained it directly from (1), so that it is known to refer to a document.

2b) This person is aware of some metatdata about the document, and 
attempts to independently construct a URN identifying the document from 
this metatdata. (I take this to be an important use case from the point 
of view of the draft.) In this case, this person may get lucky and come 
up with an identical URN to one assigned by (1). On the other hand, 
given the number of possible optional fields, he may not be so lucky. 
His chances are better if (1) attempted to define every imaginable 
permutation, but that is a lot of work and I doubt one can count on this.

You imply an environment where such an undefined URN can be resolved by 
a smart resolver. But in this case the input URN is not actually a URN 
to the document in question - it is a query for some document. And that 
is my point.

ISTM that the definition of the URN should be concerned with (1) and 
(2a). But as I read the draft it certainly feels to me that it has a 
heavy concern for (2b).

	Thanks,
	Paul

> For the other issues raised, we will analyse them in details and get back to you soon.
> 
> Best regards
>     Pierluigi and Enrico
> 
> 
> 
> ---------------------------------------------------------
> Enrico Francesconi
> ITTIG - CNR
> Institute of Legal Information Theory and Techniques
> Italian National Research Council
> 
> Via de' Barucci 20
> 50127 Florence
> Italy
> 
> Tel: +39-055-4399-665
> Fax: +39-055-4399-605
> email: [email-masked]
> ---------------------------------------------------------
> 
>> On 14 set 2017, at 19:04, Paul Kyzivat <[email-masked]> wrote:
>>
>> Hi Alexey,
>>
>> I found it very difficult to sort out what was fundamental and normative regarding the URN from the parts that are aspirational about resolution and use. Hence my recommendation that this document be split. Such a split may well resolve this issue for me.
>>
>> I only pointed to this one place, but there are other places that express an intention that it be possible to "guess" or recreate a lex URN based on metadata about the document. That only makes sense if then intent is that the resulting URN be resolvable to the document. But there are so many elements to chosen and used or not for a given document that reasonable people are likely to arrive at different forms of the URN. That ties in to the quote above.
>>
>> 	Thanks,
>> 	Paul
> 
>

---

From: Enrico Francesconi <[email-masked]>
Date: Fri, 15 Sep 2017 18:03:12 +0200

Dear Paul and Alexey,

Best regards
   Pierluigi and Enrico

Via de' Barucci 20
50127 Florence
Italy

Tel: +39-055-4399-665
Fax: +39-055-4399-605

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 18 Sep 2017 02:11:46 -0400

Let me speak in favor of draft-spinosa-urn-lex.

My understanding of the intention of the draft is essentially the
creation of a universal system for bibliographic citations of legal
works, using the syntax of URNs to express the citations.  This
understanding colors how I think about the namespace proposal.

The intention seems to be that every document is assigned one or more
URNs by a governing jurisdiction, or by a publisher of a version of the
document.  Note a point that I did not understand until recently, that
the uniqueness rule for URNs permits multiple URNs to refer to one same
resource.  As the authors note, one use of this is providing references
to a document which are based on multiple natural languages.

The resolution process for assigned URNs is a typical indirection
system, where the URN is looked up in a database.  However, the system
supports a usage that is much more like other library or bibliographic
systems -- the user can compose the information that he knows about the
document into an "approximate" URN which can be searched for in a
database using a "closest match" rule, which both converts the queried
URN into an assigned URN and provides information about the document
itself.  In this usage, the user-composed URNs are fundamentally
equivalent to queries.

The current draft does not clearly separate the information about the
query/resolution process.  It would be helpful if the resolution
information were in a separate section, as the registration template
format in RFC 8141 recommends.  It would also be helpful if there was a
clear distinction between the parts of the resolution process that are
well-defined and fixed, and (IIRC) some information which has not been
firmly fixed.

However, the messy part is the user-created "query" URNs.  To get these
within the formal rules for URN namespaces, we need to recognize them as
a special subclass whose definition does not come from assignment to a
document by an authority, but rather from the namespace definition
itself, in a clause somewhat like:

    A URN that is not assigned to a document is defined to represent a
    query into the universe of URNs that have been assigned to
    documents, whose resolution is current set of assigned URNs that
    most closely match the URN.

Clearly, there are some rough edges to that.  But the meaning of a URN
is time-invariant as a query, despite that the results of the query
depend on the time.  And when a URN is assigned to a document, the URN
is equivalently a query that returns just that one document (since it is
a perfect match to itself as an assigned URN).

Some of this reasoning is a stretch, but (a) I've written URN definitions
that aren't perfectly compatible with RFC 8141, and (b) this pattern of
definition and usage seems to be ideal for handling bibliographic
references.

So I think the overall concept is good and useful, though the
presentation needs to be cleaned up in the ways that we've been
discussing.

Dale

---

From: Enrico Francesconi <[email-masked]>
Date: Wed, 20 Sep 2017 19:55:52 +0200

Dear Dale,
  thanks for your remarks. As they are very sensitive in the on-going discussion, we send you and the other reviewers some considerations about them, in order to clarify our approach in the URN:LEX proposal. 

URN:LEX has been conceived to cope with two main objectives:
- sources of law identification
- facilitate sources of law accessibility from references usually present in different types of documents (other sources of law (legislation, case law or administrative acts) was well as newspapers, legal doctrine, etc.)

In this respect the URN:LEX proposal distinguishes two aspects:

1) sources of law URNs creation and attribution
	a) always complete and unequivocal;
	b) generated through a complex set of metadata, which nevertheless is able to guarantee uniqueness of document identification (among versions, languages, formats, within a federated system characterized by different issuing authorities and publishers)
	c) assigned by an issuing authority or publisher

2) sources of law references
They can be present in any document, even non legal. 
Legal references are often incomplete or inaccurate, therefore the URN derived from a reference will be incomplete as well, either generated by a human or by a software tool (a parser).
Since the aim of the approach is to facilitate document retrieval, an intelligent resolver can use the derived, even incomplete, URN to retrieve the best matching documents. Then, the user will be able to choose, among the results, the document matching his requirements.
This mechanism exploits the possibility to detect metadata within a textual reference expressed in natural language and create an even incomplete URN, rather than forcing a user to search for the exact URN within an remote database.

In the legal domain the access to the last version of a law is typically required. Since the information expressed in references correspond usually to metadata at the FRBR Work level, the URN that can be derived is not complete (it lacks information at Expression and Manifestation levels; ex: Regulation (EU) No 1308/2013 of the European Parliament and of the Council of 17 December 2013).

Moreover, a part from references expressing amending actions which are typically static (they make reference to a specific version of a target act or partition at the moment of their modification), legal references are typically dynamic (they make reference to the version of the target act or partition “in-force” today). Therefore, describing a reference by a complete URN is wrong even from a conceptual point of view.

An effective URN resolver has to be able to provide all the URNs at Work level matching the incomplete one derived from the reference.
Then, the user can choose the desired URN and the resolver can provide the different versions associated to that Work (in case highlighting the “in-force” version). Then, chosen a version, the resolver can provide all the possible manifestations among which the user can choose the required document.
Such resolver behavior is actually made easy by the hierarchical structure of URN:LEX (work, expression and manifestation levels clearly separated by @ and $ characters).

In the URN-LEX proposal we followed such principles, with the aim to distinguish between these two aspects (sources of law naming and sources of law referencing). Obviously we are available to modify the URN:LEX draft so that these principles can be more clear.

We are also analyzing the other remarks of the reviewers; shortly we will send you some proposals to solve the issues raised. 

Thanks!
Best regards
  Pierluigi and Enrico

Via de' Barucci 20
50127 Florence
Italy

Tel: +39-055-4399-665
Fax: +39-055-4399-605

> On 18 set 2017, at 08:11, Dale R. Worley <[email-masked]> wrote:
>