[rfc-i] Committee for opposing more tedious boilerplate (was: errata maintenance)

Alex Rousskov 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:

	Legal:   http://rfc-editor.org/foo/bar/legal?v1.1
	Status:  http://rfc-editor.org/foo/bar/st?rfc1234
	Errata:  http://rfc-editor.org/foo/bar/err?rfc1234
	Help:    http://rfc-editor.org/foo/bar/help

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.
>    john
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> http://www.rfc-editor.org/mailman/listinfo/rfc-interest

More information about the rfc-interest mailing list