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

best,
   john



More information about the rfc-interest mailing list