Subject: [Last-Call] Opsdir telechat review of draft-spinosa-urn-lex-13

From: Scott Bradner via Datatracker <[email-masked]>
Date: Wed, 12 Feb 2020 12:08:07 -0800

Reviewer: Scott Bradner
Review result: Has Issues

the comments in my previous review were not addressed

---

From: "Enrico Francesconi (IGSG-CNR [ex ITTIG-CNR])" <[email-masked]>
Date: Sun, 16 Feb 2020 23:19:45 +0100

Dear Scott,
   thanks for your contribution and sorry for not having addressed your previous comment, which we report here below and more below our answer.

> The document describes a URN syntax and provides a set of principles relating to
>  a resolution service for the URNs.
>
> I do not quite know how to approach this document for an OPD-DIR review since such
> reviews primarily focus on any issues that might impact a network operator or the operator
>  of a service and this document mostly consists of the URN syntax and support for the syntax.
>
> The document mentions that "the "lex" namespace resolver will be expected to cope with a wide
> variety of "dirty" inputs" (section 8.1).  The document attempts to describe a design of a "flexible and
> robust" resolver but I expect that the foibles of the real world will too frequently cause resolution failures -
> I do not have any suggestions to make this less likely although it seems to me that being quite as forgiving
> in what the resolver tries to deal with (partial matches, etc.) may not be worth the effort.  It seems to
> me that the only way for someone to have a LEX URN to resolve is to get it from a publisher (since it will
> be essentially impossible for someone to guess one) why is it not reasonable to assume the URN is an
> accurate copy of what the user received and simply reject it if it does not parse.  (I say that it seems
> impossible for someone to guess since the URN hierarchy and components seems so locally defined.)
>
> So, personally I would recommend removing the fuzzy matching part and thus simplify
> operation and reduce operational issues.
>

The specifications for the fuzzy/partial matching behaviour of a resolver have been introduced to address the specific nature of legal references.
In fact, the most part of legal references, by nature, are expressed at Work level only, thus referring to a set of resources; only very rarely they are at Expression level; never at Manifestation level.
In this sense they are, so to say, partial/incomplete with respect to the full identifier.
What is most interesting is in fact to get to the addressed document and then only subsequently to choose, if necessary, between the various versions and/or manifestations (using for example links between different versions of the document such as [RFC8288], see par. C1.1)
Moreover, sometimes textual legal citations may lack some elements of identification (or they are implicit), therefore, in these cases, it can be difficult or impossible to automatically generate the complete “lex” identifier associated to a reference, even at the Work level only.
For this reason the exact 1-to-1 matching between provided ID and document ID in the resolution is almost without sense in the legal domain. On the other hand, the resolver can be configured to provide, by default, the "best copy” (according to certain rules) of a set of documents (this is actually what the http-based version of the lex identifier is meant to do).

Best regards
   Pierluigi and Enrico

---
Enrico Francesconi
IGSG - CNR    [ex ITTIG - CNR]
Institute of Legal Informatics and Judicial Systems
Italian National Research Council

Via de' Barucci 20
50127 Florence
Italy

Tel: +39-055-4399-665
Fax: +39-055-4399-605
email: [email-masked] <mailto:[email-masked]>

> On 12 Feb 2020, at 21:08, Scott Bradner via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Scott Bradner