[rfc-i] Order of numbered and un-numbered sections in RFCs

Bob Braden braden at ISI.EDU
Tue Sep 7 16:13:39 PDT 2004

  *> >
  *> >(From draft-rfc-editor-rfc2223bis-08.txt:)
  *> >
  *> >    A published RFC may contain the sections in the following list.  Some
  *> >    of these sections are required, as noted.  The order shown is
  *> >    required, except that the order shown for the sub-items 7a-7f within
  *> >    Body of Memo is generally recommended but not required.
  *> >
  *> >
  *> >       1.  First-page header           [Required]
  *> >       2.  Status of this Memo         [Required*]
  *> >       3.  Copyright Notice            [Required*]
  *> >       4.  IESG Note                   [As requested by IESG*]
  *> >       5.  Abstract                    [Required]
  *> >       6.  Table of Contents           [Required for large documents]
  *> >       7.  Body of the Memo            [Required]
  *> >        7a.  Contributors
  *> >        7b.  Acknowledgments
  *> >        7c.  Security Considerations   [Required]
  *> >        7d.  IANA Considerations
  *> >        7e.  Appendixes
  *> >        7f.  References
  *> >       8. Author's Address             [Required]
  *> >       9. IPR Boilerplate              [Required*]
  *> I'd avoid numbers here, because this may otherwise be confused
  *> with the numbering of the sections.
  *> Also, 7a should be something like 'real body' or 'actual spec'


No, Body of the Memo should be considered to be the "real body".
Any other definition gets you into trouble.  We have tried it.

  *> or whatever. Also, my understanding is that since very recently,
  *> a IANA section is required.

This has to be qualified.  An IANA section is now required in every I-D
submitted for publication.  This includes the "null" case of an IANA
Considerations section that says "There are no IANA considerations".
This is useful information to IANA, but frankly we think it looks dumb
in an archival document, so we normally remove such null IANA
considerations sections before publication; in that sense it is
optional (but this area has been in flux for several years, and
perhaps it would be better if the list above did say "Required".)

  *> >>rfc-editor-rfc2223bis-08.txt includes a pretty good order, though by
  *> >>default I'd change the order or references and appendices.
  *> >

Some RFCs have VERY large appendices; have you ever tried to find the
references in a 120 page document that includes 90 pages of appendices?
For this reason, we generally prefer references after appendices, even
though in other publication venues, the other order is more customary.
But in the end it is authors' choice; situations differ.

  *> >I have seen documents with the various parts of the "body" in different 
  *> >positions. Should we make hard-and-fast rules for future RFCs, or leave 
  *> >the body order floating?

It is a long-standing RFC Editor policy to give authors as much
freedom as possible, while keeping the general look of an RFC the
same.  We think that is the right policy.

  *> I use to think about security considerations and IANA considerations
  *> as part of the actual spec, which means that in the above point
  *> 7, they should come first. Having references last is helpful because
  *> that's the point one goes to most often during reading the rest
  *> of the doc, but the boilerplate at the end makes this less easy
  *> than if they were really at the end. If there is an index, it
  *> should usually come after the references.
  *> It would also be good to have contributors, acknowledgements,
  *> and author's addresses close together, because they are all related.
  *> But then we already have conflicting constraints :-(.
  *> (it should be "Author's Address or Authors' Addresses", btw).

These are all useful suggestions for authors, but again, situations

Bob Braden for the RFC Editor

  *> Regards,    Martin.
  *> _______________________________________________
  *> 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