On 29.10.2010 18:20, Hadriel Kaplan wrote:
... The problem with a labeling scheme like this is it's subjective. "Updates" and "Obsoletes" are not subjective, and to determine whether to apply those two labels is fairly easy. Labels of the form *-Quality would cause massive debate and need a WG-wide or larger consensus agreement process, if you mean them to be formal labels. ...
It's only sometimes easy. It get's really hard when the "old" RFC combines too many different things (like a new HTTP method, one application for it, and a registry because previously there was none), or when the new spec is actually a set of RFCs.
For some of what you describe above, people already produce RFCs to document - RFCs which deprecate a previous RFC, or enumerate issues found, or BCPs, etc. And obviously errata are already captured by the RFC editor. What's missing I think is some way to remind/force readers of an RFC to check for errata and updating/obsoleting RFCs, and how. Since it's a static document when published, I think the most natural way would be to add to the boilerplate a sentence reminding the reader to check for updates, obsoletes, and errata at "http://datatracker.ietf.org/doc/rfcXXXX"; where XXXX is filled in by the RFC Editor upon RFC publication.
All RFCs published since last January have that pointer in the boilerplate, it goes to
http://www.rfc-editor.org/info/rfcNNNN (now if we published specs in (X)HTML, people might actually click on it)
Or if you want to be really fancy, you could have the IETF auto-create a Wiki type page for each RFC, that allows open community wiki-input about quality and implementation/deployment experience and such, with a big banner indicating the wiki content is not an official IETF position.
That might be a good thing to have. Best regards, Julian _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf