Re: [art] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice

Barry Leiba <barryleiba@computer.org> Tue, 07 January 2020 17:48 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A14A1200E9; Tue, 7 Jan 2020 09:48:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Sj02Aq8RDiIK; Tue, 7 Jan 2020 09:48:14 -0800 (PST)
Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (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 B48E31200CC; Tue, 7 Jan 2020 09:48:14 -0800 (PST)
Received: by mail-io1-f47.google.com with SMTP id h8so243535iob.2; Tue, 07 Jan 2020 09:48:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IuOpvnuUwP/KQ++zdKH6O9Dn1kirFI26FmD411J8kFo=; b=Mfw4ZjImsvORLT7oJY47TinaeoBE4xmWTTXxw9Ynel8EI0ijKfg2ZxlLgUC/HxaDW6 5FyPFryWTmLfQKP2szTM1OsSnaRv6csegUGgVzxg/tg0j6OySZndVf7DZG6xQrSecxjH ZeNDkNMAvSRlTbGZBjRpNdzfRzZpxJ8dOIetbxoO4NB0m7xw62+lArmJD5Q62YRUO+B8 F7rcmFmhDjE49xG7DzEPKwpQps++qVIuT0dvfzMTapLVpmABUnYDGEwftm/InEJZRGmt DkFDlZ2JSXlVVG5bwEkjenKYRI12UW/1voi5PLOy/bDDq9trr8CxE9EjE9nU2bVfuNoO bFTQ==
X-Gm-Message-State: APjAAAXKyZ6zs5BAfpV/zXgWalNcry127VVhsoSq1Fa0Ep/kEbe/RYrJ c4wFvbGSnpqAchvsaTJysA3Y2M8QHzahKIjePaMEuA==
X-Google-Smtp-Source: APXvYqz+iMHKRZ6cE/ZPkUmY/G7J7oTUieATdjzbRNz0GeAS2qd7qpmAN1yC/IUyviKzZwXXAF4nw+lZLuprGt/73V8=
X-Received: by 2002:a5e:8417:: with SMTP id h23mr84197ioj.17.1578419293573; Tue, 07 Jan 2020 09:48:13 -0800 (PST)
MIME-Version: 1.0
References: <87E116C31DAF1434C3C3937F@PSB>
In-Reply-To: <87E116C31DAF1434C3C3937F@PSB>
From: Barry Leiba <barryleiba@computer.org>
Date: Tue, 07 Jan 2020 12:48:02 -0500
Message-ID: <CALaySJJoeBVnsc300eD0d0Kpqan-n2U_ckmr0OCpmOSy=s9w=w@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: IESG <iesg@ietf.org>, art@ietf.org, Mark Nottingham <mnot@mnot.net>, urn@ietf.org, IETF discussion list <ietf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/8PgNFH8F-1d7Zdncv7nS3Zs80gw>
Subject: Re: [art] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2020 17:48:16 -0000

I think we need to tease apart two things in John's note: the URN
scheme, and the concept of URNs as opposed to URLs, the two together
forming what we call URIs.

It's clear to me that BCP 190 has no actual effect on "urn:", because
the things it talks about simply don't apply there, or are taken care
of by the fact that URN namespaces are completely controlled by the
owners of the namespaces.  There is no internal hierarchy within URN
namespaces unless the specification of the namespace creates one and
defines how that hierarchy works and is managed.

For the other part of the issue, I'm not fully in agreement with
Phillip and Michael, in that I do think there's a useful distinction
between a URI that names something without specifying how to locate
it... and one that is a locator.  There is, for example, a fundamental
difference between, say, "http:" and "ni:" (see RFC 6920).

That said, I also think that existing URI schemes that define *names*
lack hierarchies, and are similarly not really affected by BCP 190.
As I read through 7320bis and placed my "Yes" ballot, I didn't see
anything, neither in the original text nor in the changed text, that
made me question this, and as I look back through it now I still
don't.

So I don't have any concerns here.  If anyone has something specific
to raise, please raise it now, while the document is still in IESG
Evaluation and we can more easily discuss it and make changes.

Barry

On Tue, Jan 7, 2020 at 1:58 AM John C Klensin <john-ietf@jck.com> wrote:
>
> Hi.
>
> My apologies for the extreme lateness of this note.  I have
> tried to pass URN work on to others since RFCs 8141 and 8254 and
> had assumed that someone else would check through this document
> to be sure that it appropriately covered both locator-type and
> name-type URIs (particularly URNs) (see RFC 3986 Section 1.1.3).
> I had assumed that reviews within the ART area and/or a specific
> ART Area Review would address that topic but, AFAICT, they may
> not have done so.
>
> I've had occasion to look through the document and I'm actually
> not sure about the name-locator distinction as it may apply to
> it.  This note will be short and is rather more about asking the
> IESG to be sure that any possible issues are addressed than to
> try to do a detailed review of the issues.
>
> AFAICT, the focus of the I-D is to be sure that applications and
> elaborations of any URI scheme be firmly under the control and
> management of the owner of that scheme and that possible
> deviations from that principle are well-controlled.
> http://www.w3.org/TR/2004/REC-webarch-20041215, Section 2.2.2.1,
> cited in the draft as [webarch] is clear that the ownership of a
> URN is delegated to the owners of URN Namespaces rather than
> being bound to the "urn" URI scheme itself.  I believe it is
> possible to read this document in a way that has no impact on
> URNs and URN namespaces.   However, it appears to me that, if
> read without appropriate care, some of the restrictions imposed
> on queries and fragments may be inconsistent with mechanisms and
> syntax for use in particular URN Namespaces or URNs generally
> that were contemplated and extensively discussed during the
> development of RFC 8141.  Those ideas were deferred by the WG
> for future work but the mechanisms may well be in use in
> important URN namespaces.  Because the last paragraph of Section
> 1.1 of this I-D essentially declares any existing specification,
> even a standards-track one or one adopted by other bodies, that
> does not comply with the recommendations of the I-D to be
> incorrect and in need of correction, the effects of a reading
> that retroactively restricts URN Namespace practices that are
> under the control of the Namespace owners could be quite serious.
>
> My preference would be that someone who has been more active
> with URN work and Namespace registrations in the last couple of
> years do a careful review of the document to determine whether
> my concerns justify some tuning of the text.  However, given how
> late it is in the review process (again, my apologies for not
> catching the issue until now), a reasonable alternative would be
> to simply insert a sentence early in the I-D that says that it
> applies primarily to locator-type URIs although name-type ones
> may find it useful as general guidance _or_ to explicitly call
> out the difference in ownership between URNs and other URI
> schemes.
>
>  thanks,
>    john
>
> p.s. It would be, IMO, helpful if the IESG and the community
> would think about the implications of BCP (or IETF-stream
> Informational) documents that effectively obsolete or deprecate
> existing standards without identifying them or explicitly
> updating them and whose responsibility it is to find the
> discrepancies.
>