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

John C Klensin john-ietf at jck.com
Tue Feb 23 09:15:35 PST 2021


Let me distinguish between two types of use contexts:

(1) Trying to find relevant I-Ds, working with I-Ds, trying to
build new documents, and so on.  While there are design issues
and matters of taste we could quibble about and debate endlessly
(the issue of whether the home page for an I-D should show a
page or two or the current /latest version or the whole thing is
probably a good example).  For me, apparently like you, the
current datatracker setup is entirely satisfactory for that
purpose.   Moreover, even about those matters of taste that were
decided in a way that does not match my preferences, I worry a
bit about improvements because I'm used to doing things the way
they are now and making things better might me extra work to
readjust those habits.   There are also things that I think
would make it lots better.  For example, I wish the IESG would
strongly encourage a "Changes since the last version" appendix
and that the datatracker would pick that information up and show
the subsection for the most recent version on that first page --
far more useful than the complete document, which is only a
click away in any of several formats.

(2) References from RFCs.  These need to be, at least by
default, exact.  The flexibilities that are an advantage with
the above can be a liability here.  Why? Because it is not
unusual for the substantive content of an I-D to change as work
evolves and consensus emerges (or doesn't).  If, for example,
version NN of an I-D said "the outside of the bikeshed MUST be
painted blue", version NN+1 said "the outside of the bikeshed
MUST be painted lime green" and explained why, it would be very
important if an RFC that referenced it for color choices point
to the version the RFC's author intended and not some other
version.  Would it be important for the reader to find out that
there is a later version in which things might have changed?
Sometimes, but only the document author is likely to know.


--On Tuesday, February 23, 2021 12:16 +0000 tom petch
<daedulus at btconnect.com> wrote:

> 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.
> 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 at rfc-editor.org
>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

More information about the rfc-interest mailing list