Re: [urn] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice
Adam Roach <adam@nostrum.com> Tue, 07 January 2020 16:35 UTC
Return-Path: <adam@nostrum.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 96375120855; Tue, 7 Jan 2020 08:35:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level:
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 d05P0sxs3B5X; Tue, 7 Jan 2020 08:35:22 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 68DFD120851; Tue, 7 Jan 2020 08:35:18 -0800 (PST)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 007GZEEY063997 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 7 Jan 2020 10:35:16 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1578414917; bh=kh6+P4K8azbFqbi6ACYIBh3BOFCHbZc1rccEKnmGM0A=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=TDf+0KU4w5wgOd6b0WPrKO0xIbU/DD0d7eEr+PG1cQXNYXNtUdCcFNV0jDgAL4De3 6KkWoZf38deb3FsVYydMxXdm3v4P/L1sUvue8E/836iG8eWgUW5TomcufbkQbPwzf0 2wHAQJpFo5KSt5gVTnAnXSOk5rPdChZKWXxRHE9I=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: John C Klensin <john-ietf@jck.com>, iesg@ietf.org
Cc: art@ietf.org, mnot@mnot.net, urn@ietf.org, ietf@ietf.org
References: <87E116C31DAF1434C3C3937F@PSB>
From: Adam Roach <adam@nostrum.com>
Message-ID: <a267e8d7-e88f-fe84-a3d4-eb12b88a46ad@nostrum.com>
Date: Tue, 07 Jan 2020 10:35:09 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <87E116C31DAF1434C3C3937F@PSB>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/5J6Ss0w9OaQeE57Aboyda_Kn5Co>
Subject: Re: [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 16:35:28 -0000
To help with framing this conversation, the changes from RFC 7320 are highlighted here: https://www.ietf.org/rfcdiff?url1=rfc7320&url2=draft-nottingham-rfc7320bis-03 I have some rather extensive thoughts on the process of creating bis documents [1]. While I'm not going to reiterate all of them here, I want to highlight a specific passage that seems to bear on John's comments: > One major concern that drives these incremental document updates is > that an attempt to republish an RFC as originally described in RFC > 2026 can result in such an effort being bogged down by issues that > exist in text unrelated to the desired changes. Such issues can > arise from a change in the consensus of the IETF around best current > practices, such as in the areas of security, privacy, or > architectural design of an underlying protocol. This complication > arises from the fact that processing of an updated full version of an > RFC is procedurally identical to processing of a green-field > definition of a new protocol: review by the IETF at large, and review > by the IESG, are performed on the entire document, leaving legacy > text open to comments that will delay - and occasionally block - > publication of such documents. /a ____ [1] https://tools.ietf.org/html/draft-roach-bis-documents-00 On 1/7/20 12:57 AM, John C Klensin 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. >
- Re: [urn] [art] URNs and Last Call: <draft-nottin… Phillip Hallam-Baker
- [urn] URNs and Last Call: <draft-nottingham-rfc73… John C Klensin
- Re: [urn] [art] URNs and Last Call: <draft-nottin… Michael Richardson
- Re: [urn] URNs and Last Call: <draft-nottingham-r… Adam Roach
- Re: [urn] URNs and Last Call: <draft-nottingham-r… Barry Leiba
- Re: [urn] URNs and Last Call: <draft-nottingham-r… John C Klensin
- Re: [urn] [art] URNs and Last Call: <draft-nottin… Phillip Hallam-Baker
- Re: [urn] [art] URNs and Last Call: <draft-nottin… Christian
- Re: [urn] [art] URNs and Last Call: <draft-nottin… Larry Masinter
- Re: [urn] [art] URNs and Last Call: <draft-nottin… Phillip Hallam-Baker
- Re: [urn] [art] URNs and Last Call: <draft-nottin… Peter Saint-Andre
- Re: [urn] [art] URNs and Last Call: <draft-nottin… John C Klensin
- Re: [urn] [art] URNs and Last Call: <draft-nottin… Dale R. Worley