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

John C Klensin john-ietf at jck.com
Mon Feb 22 19:41:31 PST 2021

--On Tuesday, February 23, 2021 01:39 +0100 Carsten Bormann
<cabo at tzi.org> 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.


More information about the rfc-interest mailing list