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

Enrico Francesconi <enrico.francesconi@gmail.com> Fri, 15 September 2017 16:03 UTC

Return-Path: <enrico.francesconi@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83766132D4B; Fri, 15 Sep 2017 09:03:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 CgKBFQ1HaL7t; Fri, 15 Sep 2017 09:03:18 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 7B8441321A4; Fri, 15 Sep 2017 09:03:18 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id i189so9547290wmf.1; Fri, 15 Sep 2017 09:03:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=raZ7iBR8juxSdZeUTv8HThqIPjeRVrHMMk1jLZA/q48=; b=QuM64W1xTqdeiHA5YpWBSmYPzyQ9wx+6AHb5DVkSWPv7S8/ygrnUNYEn86XlwLNQOU tQ2NE53hQ+tDa4fbG1zL/FN3OD6ZTeu9OWOtWVJmWIgNd6YMMcRlmC6JZ9enZ8W5FAaw MIuXbdPFijfx7zi6aOnqKpDWhLiPBkum7j3FwJ6nG89i0cVr0dyqWej3Oz5BjjM0Q8ev 1qNodv9gN8MePpjS2lWIuIsoxPNGqm217Xu7U7xvK93NhSMYFCo4uql1+ARWjNak/flO +1rmNPVgbIwTNByzlJvsIm10G3DgGuFgMZBB6LVY4oyp76kaCipt0Mh9hNV6nKNqXxeO SETA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=raZ7iBR8juxSdZeUTv8HThqIPjeRVrHMMk1jLZA/q48=; b=ouiPn8v78mT1aSDqTA/FXkFNmww94IGYKiV7XIAabR09Kb1jdS1JgPunMuOOujWoL0 ZJbH9vcFcmnMKOnWELM18GJXXuKR2fOn2at4fCt9KnwRi8ig4r2wpwYUCREnKP68e+K4 9ChC8cLpEGCssB/Gao80xXsj91sqhukBmCcQnC+kPrxaNbDcfFZR/zwGQ1kxCE/ZGFla 1STzXR1x/ODgV/jvMcnblDiL7PjBjtZr6xxFW15ojUWjSDdCzPm+ph9kBEk8JuV/vzM6 YrPCHftHFUcIGp+Hp5n47KRc22e1YERwxeqyU7F1EgPTXALVGjoP95klwf26ZjGOokMg Av/g==
X-Gm-Message-State: AHPjjUi7FvIDxnZMt00l8/y7RILHEvWRBOsY012pHHR9eBiAQZoGmPwM 4qaXn4Kre9z75Fhav2Oge6c=
X-Google-Smtp-Source: AOwi7QDA4ftjhKBJn+OngiRQyf78DNJWPBng9EN4L2YKzzhIe217V7/Fe/HfYrzSRPR6tUAJiEoPBQ==
X-Received: by 10.28.232.138 with SMTP id f10mr187489wmi.130.1505491396635; Fri, 15 Sep 2017 09:03:16 -0700 (PDT)
Received: from air-di-enrico.homenet.telecomitalia.it (host136-125-dynamic.46-79-r.retail.telecomitalia.it. [79.46.125.136]) by smtp.gmail.com with ESMTPSA id y84sm861105wmg.43.2017.09.15.09.03.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Sep 2017 09:03:13 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Enrico Francesconi <enrico.francesconi@gmail.com>
In-Reply-To: <d9bd361c-e080-ae30-c2cc-b1764b4887d3@alum.mit.edu>
Date: Fri, 15 Sep 2017 18:03:12 +0200
Cc: Alexey Melnikov <alexey.melnikov@isode.com>, draft-spinosa-urn-lex.all@ietf.org, General Area Review Team <gen-art@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B3FC1E30-EF22-4A98-A902-3BDAB0534284@gmail.com>
References: <470a7b0a-ca03-f002-b427-8003e3f7f592@alum.mit.edu> <B21F7E94-7E48-47F6-9109-693496BDED24@isode.com> <d9bd361c-e080-ae30-c2cc-b1764b4887d3@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3094)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/4knf2dUpDGLSRokcdQQr13fYS2o>
X-Mailman-Approved-At: Fri, 15 Sep 2017 13:43:16 -0700
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-spinosa-urn-lex-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Sep 2017 16:03:20 -0000

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.

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: francesconi@ittig.cnr.it
---------------------------------------------------------

> On 14 set 2017, at 19:04, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> Hi Alexey,
> 
> On 9/14/17 12:25 PM, Alexey Melnikov wrote:
>> 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 <pkyzivat@alum.mit.edu> wrote:
>>> 
>>> (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.
>> 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).
> 
> 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