Massively chopping this thread of (I'm not being snarky) wisdom, down to the part I think I can contribute to ...
On Sun, May 9, 2021 at 3:20 PM John C Klensin <john-ietf@xxxxxxx> wrote:
These distinctions are particularly important if the IETF is
going to publish versions of RFCs with errata incorporated.
Because I honestly don't know who might be reading this e-mail thread, and what they might know, let me say this out loud.
I have no inside knowledge of what the *IETF* might plan to publish, but for what the RFC Editor publishes, this ship has sailed.
Tl;dr
I had the privilege (HAH!!!) of explaining the Theory and Practice of RFC Errata to members of the CELLAR working group that I co-chair with Michael Richardson, during our last virtual meeting. This group has published one RFC, and https://datatracker.ietf.org/doc/html/rfc8794 is 2700 lines long and pretty dense, so they're receiving errata report (mostly through Github, from people who don't even participate in CELLAR, much less grok the difference between the RFC view in the datatracker and the RFC view on rfc-editor.org).
They were horrified to discover that RFCs are immutable, and were imagining that they were going to have to roll another RFC every time someone reported a bug.
I showed them (as an example) that if they searched for RFC3261 on the RFC Editor website, and clicked on the cute "HTML with a green check mark" icon, they got a page that started with this:
This is a purely informative rendering of an RFC that includes verified errata. This rendering may not be used as a reference.
The following 'Verified' errata have been incorporated in this document: EID 316, EID 1051, EID 1073, EID 1470, EID 2051, EID 3183, EID 4567
The following 'Verified' errata have been incorporated in this document: EID 316, EID 1051, EID 1073, EID 1470, EID 2051, EID 3183, EID 4567
And if you click on the links, it shows you where each errata goes, and if you click on "Expand", it shows you the Verified errata, and if the errata had OLD/NEW text, the new text is shown inline.
So, what you get is something like this:
The handling parameter, handling-param, describes how the UAS should react if it receives a message body whose content type or disposition type it does not understand. The parameter has defined values of "optional" and "required". If the handling parameter is missing, or if the Content-Disposition header field is missing, the value "required" SHOULD be assumed. The handling parameter is described in RFC 3204 [19].EID 4567 (Verified) is as follows: Section: 20.11 Original Text: The handling parameter, handling-param, describes how the UAS should react if it receives a message body whose content type or disposition type it does not understand. The parameter has defined values of "optional" and "required". If the handling parameter is missing, the value "required" SHOULD be assumed. The handling parameter is described in RFC 3204 [19]. Corrected Text: The handling parameter, handling-param, describes how the UAS should react if it receives a message body whose content type or disposition type it does not understand. The parameter has defined values of "optional" and "required". If the handling parameter is missing, or if the Content-Disposition header field is missing, the value "required" SHOULD be assumed. The handling parameter is described in RFC 3204 [19].Notes:
None
So, they're SUPER excited about making use of this mechanism, and we can talk about whether people really read Public Service Announcements ("This is a purely informative rendering of an RFC that includes verified errata. This rendering may not be used as a reference.") - but can we blame them for wanting to do that?
So, ISTM that what our current errata system was set up to do (and I can't emphasize enough that I wasn't there when it was set up), was to Reject stuff that wasn't REALLY an errata or obviously not the right correction to make, Verify obvious corrections, and Hold Everything Else For Document Updates, so that a working group has a chance to talk about what The Right Thing To Do is, given that they missed something Technical when they looked at this for the first time, as opposed to having an AD decide *now* what The Right Thing To Do will be at some point in the future, and constraining the working group when they *do* have enough brain cells to update the document. (If that's not the case, my apologies to the people who set it up in the first place).
If we wanted to make life easier for people using IETF specifications (as opposed to going to the Github repos and "making" their own specifications from Master/Main branches, we might think about
- How much we want to "warn people away" from using the really helpful errata inlining mechanism that is already available from the RFC Editor, and
- How much stuff that's not Verified would be useful to present to the people who use our documents - especially stuff that's Rejected because it doesn't reflect the thinking of (my own favorite) the NFSv4 working group more than a decade ago, but is really close to what they are thinking today.
As always, thanks for listening. And Do The Right Thing.
Best,
Spencer, who used the tools format of RFCs in HTML almost exclusively for at least a decade, and then switched to the datatracker HTML format, neither of which were the canonical txt-then, XML-now formats that we wish people would use.
