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

Robert Sparks <> Tue, 23 February 2021 15:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD5A13A2C92; Tue, 23 Feb 2021 07:42:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, NICE_REPLY_A=-0.001, 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
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h2NA4fyU6ZVf; Tue, 23 Feb 2021 07:42:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DBE0E3A2E2C; Tue, 23 Feb 2021 07:42:17 -0800 (PST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 35DA4F40751; Tue, 23 Feb 2021 07:42:09 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7BACF40751 for <>; Tue, 23 Feb 2021 07:42:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HR58MbM8xR1o for <>; Tue, 23 Feb 2021 07:42:01 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) by (Postfix) with ESMTPS id 511E1F40744 for <>; Tue, 23 Feb 2021 07:42:00 -0800 (PST)
Received: from unformal.localdomain ([]) (authenticated bits=0) by (8.16.1/8.16.1) with ESMTPSA id 11NFg5f5031749 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for <>; Tue, 23 Feb 2021 09:42:06 -0600 (CST) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1614094926; bh=9tjn5KInp0NK+Ul0fkK1sm30Qv3vDGrXMJSr5apXyQM=; h=Subject:To:References:From:Date:In-Reply-To; b=V161niyfyMbSNeahTU4rFYb4SLLJgOTT4/OjnmevQ9+qusA7kLBurFPks8kxqb+hy /3p9M38BrXTCCOIDJAvZSzUzo6BbI7Dz3Qmr4O+9naycJWC1VI7r2aXx7OcAIHoCbv 2j1dParVvC3YfyVaFTyY+TB9c+pWqyU4N9GJMaGc=
X-Authentication-Warning: Host [] claimed to be unformal.localdomain
References: <> <7C7234B7EF4B131225B9C92E@PSB> <> <96AB7E5BDFAAF70FD1F3BB9D@PSB> <>
From: Robert Sparks <>
Message-ID: <>
Date: Tue, 23 Feb 2021 09:42:00 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Language: en-US
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-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: "rfc-interest" <>

On 2/23/21 6:16 AM, tom petch wrote:
> On 23/02/2021 03:41, John C Klensin wrote:
>> --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.
> For me, the datatracker page that I get to from a datatracker WG page 
> has the metadata that I need to work, whereas the tools page is sadly 
> lacking in that regard.  Yes, there is less metadata but I need that 
> missing metadata so leaving it out is counter-productive.
> Also, from<i-d name>
To  be clear, that page is not going away.
> I get what is to me a clear display of the document history from which 
> I can navigate to (almost) any earlier version.  I am puzzled that 
> there should be any difficulty in clicking on the green or purple bar 
> to select a different version (except when the submissions window is 
> closing and authors submit three versions in under 24 hours and the 
> bars shrink to zero).
> I think that the datatracker took a giant leap forward at some point 
> from being unusable to being the best way into the work of the IETF so 
> my home page became Active WGs. I often want to return there so that 
> having the nav bar is most useful.
> Tom Petch
>>>> 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.
>> best,
>>     john
>> _______________________________________________
>> rfc-interest mailing list
> _______________________________________________
> rfc-interest mailing list
rfc-interest mailing list