[rfc-i] rfc-interest Digest, Vol 196, Issue 22
daedulus at btconnect.com
Tue Feb 23 04:16:46 PST 2021
On 23/02/2021 03:41, John C Klensin wrote:
> --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.
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 https://datatracker.ietf.org/doc/<i-d name> 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.
>>> 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
> rfc-interest at rfc-editor.org
More information about the rfc-interest