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

John C Klensin <john-ietf@jck.com> Tue, 07 January 2020 06:57 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C455F1200BA; Mon, 6 Jan 2020 22:57:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham 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 avWJNij_kYRR; Mon, 6 Jan 2020 22:57:42 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01A2120096; Mon, 6 Jan 2020 22:57:42 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ioio6-0005qR-CL; Tue, 07 Jan 2020 01:57:38 -0500
Date: Tue, 07 Jan 2020 01:57:32 -0500
From: John C Klensin <john-ietf@jck.com>
To: iesg@ietf.org
cc: art@ietf.org, mnot@mnot.net, ietf@ietf.org, urn@ietf.org
Message-ID: <87E116C31DAF1434C3C3937F@PSB>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/dw7pA79uYILTdjOHrU21oBeuIzo>
Subject: [urn] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2020 06:57:49 -0000

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.