[rfc-i] Committee for opposing more tedious boilerplate (was:
rousskov at measurement-factory.com
Tue Apr 13 15:34:47 PDT 2004
IMO, the logically correct action here is to limit the size of
the boilerplate, NOT the amount of information! For example, here is a
6-line boilerplate that can be used to express everything in the
current RFC boilerplate and everything you mentioned in your plea
This document specifies an IETF _____ Standard. The
following resources are incorporated here by reference:
The text, labels, and URLs should be polished, but you get the idea...
On Tue, 13 Apr 2004, John C Klensin wrote:
> >> Not sure anyone suggested this yet but another approach might
> >> be to add some boiler plate to each new RFC pointing to the
> >> errata page.
> > Yep, that's a possibility. If so, maybe along the lines of:
> > RFCs are forever; an RFC is never modified after publication.
> > However, RFCs can be reclassified: made historic, obsoleted
> > completely, or updated by subsequent RFCs. The current
> > status of an RFC must be checked in the RFC index [URL], not
> > in the document itself. Editorial errata for RFCs is also
> > available at [URL2].
> _Please_ let's not go down this path. RFCs have already ended
> up with an unpleasant ratio of boilerplate to informational
> content (unless they are already _very_ long). There is ample
> evidence that, when boilerplate gets long enough --and we are
> almost certainly past that limit already-- people don't read the
> stuff. It registers as boilerplate, and then they start
> searching for whatever they are really looking for. That, in
> turn, can be bad news, since they may skip something that really
> is important.
> Suggestion: A case can be made that all sorts of information
> that is not now present in RFCs would be useful -- pointers to
> the index for status material and to errata, information about
> contacting the IETF about Standards Track material, suggestions
> about how to locate authors if the address information goes bad,
> etc. I suggest that anyone proposing more boilerplate material
> also should propose a stopping rule for determining which
> suggestions of that variety are not appropriate.
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest