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

"Enrico Francesconi (IGSG-CNR [ex ITTIG-CNR])" <enrico.francesconi@igsg.cnr.it> Sun, 16 February 2020 22:19 UTC

Return-Path: <enrico.francesconi@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2308512008A; Sun, 16 Feb 2020 14:19:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sF-2cC-_I1_Z; Sun, 16 Feb 2020 14:19:52 -0800 (PST)
Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6319F120043; Sun, 16 Feb 2020 14:19:49 -0800 (PST)
Received: by mail-wm1-f41.google.com with SMTP id t23so15287467wmi.1; Sun, 16 Feb 2020 14:19:49 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CLPqT1AeIxnp3FTk8Ok8s0rtzDm5VXNw6fk607j5OMo=; b=auPzL921cy3o/ixQy7R7/xBUTA2VpgLQWWy7MxH65Yo31yiY5ic82G/eKv68eo1upK EPCXOIoNmdOrX2GrBGOd7TIJRGijNRxY5vrW4Acj739sgtof+AjRirw0cWEUvUuDLbpw 4tJdfxdcQut/PG28qYiM15kYfArTrHqrNI0PRy3ynW6ZW4ktlGX2pPb23pxgRYjsfUub jYyMTTwV+94lVL5Ka/DAaNK8q4FRzQRjWTGR8AahQAoQX/1l4JDLmQ9R7bWSzGdFjJzV lMfmOdy13PzoCNmcTWRrQ/pRB6viCiExinkwKkb55Qw6unZJY2lfToCpH9Wd0lFpWfkr GW5A==
X-Gm-Message-State: APjAAAVOJ/f1wQpQV4RaXSUG+WqsfEKxxZgEIFnRY6uxAzc1hI7q0djO 2xaCl2usGo9DmKEbqmTQkK2SgVpuE3g=
X-Google-Smtp-Source: APXvYqyoA/oIulwmSYnBhvuKaAdgjbQO8InK1fCdykR0zVBQuOpQlWZ3NX5c11PcEvH0qnMAsOYRKw==
X-Received: by 2002:a1c:4c5:: with SMTP id 188mr17743044wme.82.1581891587655; Sun, 16 Feb 2020 14:19:47 -0800 (PST)
Received: from ?IPv6:2a02:678:406:1b00:69f5:a5f6:18e2:ac75? ([2a02:678:406:1b00:69f5:a5f6:18e2:ac75]) by smtp.gmail.com with ESMTPSA id w7sm16815940wmi.9.2020.02.16.14.19.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Feb 2020 14:19:46 -0800 (PST)
From: "Enrico Francesconi (IGSG-CNR [ex ITTIG-CNR])" <enrico.francesconi@igsg.cnr.it>
Message-Id: <A7240335-B296-468A-8181-94A6FBCD3C02@igsg.cnr.it>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F5EC455D-B05C-4175-9F2D-E420B98FF7A3"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 16 Feb 2020 23:19:45 +0100
In-Reply-To: <158153808734.18108.11306196873034140596@ietfa.amsl.com>
Cc: ops-dir@ietf.org, last-call@ietf.org, draft-spinosa-urn-lex.all@ietf.org
To: Scott Bradner <sob@sobco.com>
References: <158153808734.18108.11306196873034140596@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/sm8vZCFjj5Tb6auUZr2F8Z9LWig>
X-Mailman-Approved-At: Sun, 16 Feb 2020 15:10:22 -0800
Subject: Re: [Last-Call] Opsdir telechat review of draft-spinosa-urn-lex-13
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Feb 2020 22:19:54 -0000

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: enrico.francesconi@igsg.cnr.it <mailto:enrico.francesconi@igsg.cnr.it>


> On 12 Feb 2020, at 21:08, Scott Bradner via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Scott Bradner
> Review result: Has Issues
> 
> the comments in my previous review were not addressed
>