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

Adam Roach <> Tue, 07 January 2020 16:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96375120855; Tue, 7 Jan 2020 08:35:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.98
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d05P0sxs3B5X; Tue, 7 Jan 2020 08:35:22 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68DFD120851; Tue, 7 Jan 2020 08:35:18 -0800 (PST)
Received: from Svantevit.local ( []) (authenticated bits=0) by (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
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; 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: Host [] claimed to be Svantevit.local
To: John C Klensin <>,
References: <87E116C31DAF1434C3C3937F@PSB>
From: Adam Roach <>
Message-ID: <>
Date: Tue, 7 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: <>
Subject: Re: [urn] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:

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.



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.
>, Section,
> 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.