Re: [rfc-i] rfc-interest Digest, Vol 196, Issue 22

John C Klensin <> Tue, 23 February 2021 03:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB63F3A253A; Mon, 22 Feb 2021 19:41:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9za3_UA3hMBW; Mon, 22 Feb 2021 19:41:45 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BA7C3A2539; Mon, 22 Feb 2021 19:41:45 -0800 (PST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 0D645F40784; Mon, 22 Feb 2021 19:41:37 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB89FF40784 for <>; Mon, 22 Feb 2021 19:41:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EDuCsbp9YYFU for <>; Mon, 22 Feb 2021 19:41:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPS id 0E44CF40775 for <>; Mon, 22 Feb 2021 19:41:31 -0800 (PST)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1lEOZt-000Kqj-Rb; Mon, 22 Feb 2021 22:41:37 -0500
Date: Mon, 22 Feb 2021 22:41:31 -0500
From: John C Klensin <>
To: Carsten Bormann <>
Message-ID: <96AB7E5BDFAAF70FD1F3BB9D@PSB>
In-Reply-To: <>
References: <> <7C7234B7EF4B131225B9C92E@PSB> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Subject: Re: [rfc-i] rfc-interest Digest, Vol 196, Issue 22
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: "rfc-interest" <>

--On Tuesday, February 23, 2021 01:39 +0100 Carsten Bormann
<> wrote:

>> I am having trouble completely picturing just what you have in
>> mind, but, whatever you do, please keep in mind that
>> references from RFCs are supposed to be completely stable.
>> That means that, if I, as author, reference
>> draft-foo-bar-baz-03 at the time of RFC publication, wherever
>> the link points should produce draft-foo-bar-baz-03 and not
>> its most recent successor, whether that is
>> draft-foo-bar-baz-15 or RFC 9999.  
> Yes, but the landing page for -03 could have pointers to newer
> versions (I-D, RFC, Obsoleting RFC, …).

I have no problem with that as long as the landing page
unambiguously gets the reader to -03.  The current datatracker
page for a draft does not have that property -- one gets a
multiversion page that shows the most recent one and then has to
figure out how to navigate back to a particular version.

>> This is, of course a
>> cousin of whether a new I-D or RFC should be referencing the
>> same target RFC as the document it is replacing or should be
>> referencing the most recent update/replacement for that
>> earlier version.  In both cases, heuristics will frequently
>> be wrong. It might actually be useful for authors to be able
>> to specify "the version we specified, really" versus "most
>> recent version" in markup.
> Which you already can do in the source for an I-D.  RFC
> references are frozen, though.

I probably missed how to do that in I-Ds referencing I-Ds after
I got frustrated many years ago with automated handling of them
and just started typing them in.  

>> I'm even a little hesitant about your pointing to the HTML
>> version as long as at least some of the html versions are
>> synthesized from the text rather than being supplied by
>> authors (who have presumably checked them) or generated from
>> xml2rfc v3 (which is presumably infallible). The synthesis
>> process doesn't make serious errors very often, but, in my
>> experience, it does make them.

> This could easily be fixed.
> I did a PoC for that a while ago.
> The data collection for the fixer does need some effort; this
> could be crowd-sourced or done proactively (probably more
> expensive than we care about this problem).

Personally, I'd much rather see any spare energy in the short
term concentrated on fixing things like indexes.


rfc-interest mailing list