[rfc-i] Committee for opposing more tedious boilerplate (was:
John C Klensin
john+rfc at jck.com
Tue Apr 13 15:01:41 PDT 2004
>> 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
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.
More information about the rfc-interest