[rfc-i] Problems and requirements for RFC Format
sm at resistor.net
Wed Apr 18 00:56:47 PDT 2012
At 14:13 17-04-2012, Heather Flanagan (RFC Series Editor) wrote:
>whether or not I've captured consensus on the problem space. Note that
>I'm avoiding formal use of MUST and SHOULD right now, though I have
>tried to indicate level of requirement as I understand it so far.
MUST and SHOULD are only relevant for the stream that uses the
Standards Track. Should the RFC Editor elect to be on the Stinkards
Track, it side-steps such a level of formality.
From some old RFC:
There is a tendency to view a written statement as ipso facto
authoritative, and we hope to promote the exchange and discussion of
considerably less than authoritative ideas. Second, there is a natural
hesitancy to publish something unpolished, and we hope to ease this
Nowadays, there is what some people refer to as the RFC Format. Here
are some nits:
1. Document should match .txt file as closely as possible in
structure, format, and content.
2. Standard page size is 8 1/2 by 11 inches.
3. Leave a margin of 1 inch on all sides (top, bottom, left, and
4. Text should have a point size 10 points with a line spacing
of 12 points.
5. Three fonts are acceptable: Helvetica, Times Roman, and Courier,
plus their bold-face and italic versions.
6. Prepare diagrams and images based on lowest common denominator.
The average reader may be able to understand how to do the
above. Nit 2 has been an issue since a long time. I don't recall
anyone complaining about it.
The following is the checklist:
1. No text beyond the 72nd column of a line. This is especially important
for diagrams and code, which the RFC Editor may not be able to trivially
reformat to fall within the margins.
2. Must be ragged right
3. No hyphenation for line-breaks. However, hyphenated words (e.g.,
"Internet-Draft") may be split at the hyphen across successive lines.
4. No footnotes
5. ASCII-only, no control characters (other than CR, NL and FF).
6. Do not number the "Status of Memo" or "Abstract" sections
7. Reasonably well formatted for readibility and clarity
People complain about point 1 and point 5. My guess is that most
people complaining about point 1 are not accessing the authoritative
version of the document. A quick look at
http://www.ietf.org/about/standards-process.html does not contradict that.
Some of the categories of activity of the RFC Editor are:
(a) Editing, processing, and publication of documents.
(b) Archiving and indexing the documents and making them accessible.
(c) Series rules and guideline
Document Lifecycle falls item (a). There are valid concerns about
that and it is fine to offer people the space to talk about it. "It
is not from the benevolence of the butcher, the brewer, or the baker,
that we expect our dinner, but from their regard to their own
interest". Is it in the interest of the RFC Editor to tackle (a) now
instead of (b) and (c)? Item (a) has more visibility.
More information about the rfc-interest