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

John C Klensin <> Mon, 22 February 2021 22:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BCBD3A2A39; Mon, 22 Feb 2021 14:56:36 -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 cNWuDVAzyl9v; Mon, 22 Feb 2021 14:56:33 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED9F13A24E8; Mon, 22 Feb 2021 14:54:09 -0800 (PST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id D6674F40797; Mon, 22 Feb 2021 14:54:01 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E8B9F40797 for <>; Mon, 22 Feb 2021 14:54:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FB36TrICHj8w for <>; Mon, 22 Feb 2021 14:53:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPS id E800FF40795 for <>; Mon, 22 Feb 2021 14:53:56 -0800 (PST)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1lEK5a-000Juh-9A for; Mon, 22 Feb 2021 17:54:02 -0500
Date: Mon, 22 Feb 2021 17:53:56 -0500
From: John C Klensin <>
Message-ID: <7C7234B7EF4B131225B9C92E@PSB>
In-Reply-To: <>
References: <>
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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "rfc-interest" <>

--On Monday, February 22, 2021 13:10:44 -0600 Robert Sparks
<> wrote:

> On 2/22/21 2:15 AM, Carsten Bormann wrote:
>> On 22. Feb 2021, at 08:35, Julian Reschke
>> <> wrote:
>>> Note that the recommendations are inconsistent, and that the
>>> first one (from the web site) adds a link to
>> ? which has served us well as a landing page for a draft.
>> People like that page a lot because it has the relevant
>> metadata and links as well as the content of the draft.
>> (The equivalent data tracker page has more, but less useful
>> and less usefully presented metadata, and it only has the
>> first two pages of the draft, because it was *not* designed
>> to serve as the landing page.)
> Minor, but important note - it only shows the first two pages
> by default  for concern (at the time it was made) about
> bandwidth for consumers -  the site does allow you to control
> getting the whole draft on that page  by cookie. I realize
> that's not useful (or is a negative) for making it  the URL
> you might cite. But perhaps we should revisit at least the
> first  part of the document cookie and either always serve the
> whole document  there, or flip the default to always serve.
> That said, the page you are looking for is probably going to be
> I am in the middle of significantly changing that to have the
> same  information in the header as the draft pages at tools,
> remove the normal  datatracker nav menu and tabs, and to
> follow the same general formatting  style in what's at tools.

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

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.


rfc-interest mailing list