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

[tom petch <[e-mail]>]

On 23/02/2021 03:41, John C Klensin wrote:
>
> --On Tuesday, February 23, 2021 01:39 +0100 Carsten Bormann
> <[e-mail]> 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.

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
> [e-mail]
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>
_______________________________________________
rfc-interest mailing list
[e-mail]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest