Request for comments on Requests For Comments
Jon Postel's 1982 memo that tells authors how to state an RFC's purpose and how to format it.
Postel, J., "Request for comments on Requests For Comments", RFC 825, DOI 10.17487/RFC0825, November 1982, <https://www.rfc-editor.org/info/rfc825>.
@misc{rfc825,
series = {Request for Comments},
number = 825,
howpublished = {RFC 825},
publisher = {RFC Editor},
doi = {10.17487/RFC0825},
url = {https://www.rfc-editor.org/info/rfc825},
author = {J. Postel},
title = {{Request for comments on Requests For Comments}},
pagetotal = 2,
year = 1982,
month = nov,
} RFC text
Network Working Group J. Postel
Request for Comments: 825 ISI
November 1982
Request for Comments on Requests for Comments
This RFC is intended to clarify the status of RFCs and to provide some
guidance for the authors of RFCs in the future. It is in a sense a
specification for RFCs.
There are several reasons for publishing a memo as an RFC, for example,
to make available some information for interested people, or to begin or
continue a discussion of an interesting idea, or to specify a protocol.
Each RFC is to include on its title page or in the first or second
paragraph a statement describing the intention of the RFC.
The following sample paragraphs may be used to satisfy this
requirement:
Specification
This RFC specifies a standard for the ARPA Internet community.
Hosts on the ARPA Internet are expected to adopt and implement
this standard.
Discussion
The purpose of this RFC is to focus discussion on particular
problems in the ARPA Internet and possible methods of solution.
No proposed solutions this document are intended as standards
at this time. Rather, it is hoped that a general consensus
will emerge as to the appropriate solution to such problems,
leading eventually to the adoption of standards.
Information
This RFC is presented to members of the ARPA Internet community
in order to solicit their reactions to the proposals contained
in it. While perhaps the issues discussed are not directly
relevant to the research problems of the ARPA Internet, they
may be particularly interesting to some researchers and
implementers.
RFC on RFCs
Status
This RFC is issued in response to the need for current
information about the status and progress of various projects
in the ARPA Internet community. The information contained in
this document is accurate as of the date of publication, but is
subject to change. Subsequent RFCs may reflect such changes.
Report
This RFC is issued to report on the results of a meeting. It
may document significant decisions made that impact the
implementation of network protocols, or limit or expand the use
of optional features of protocols. Other meeting results may
be indicated including (but not limited to) policy issues,
technical topics discussed and problems needing further work.
Of course these paragraphs need not be followed word for word, but
the general intent of the RFC must be made clear.
RFCs are distributed online by being stored as public access files, and
a short messages is sent to the distribution list indicating the
availability of the memo.
The online files are copied by the interested people and printed or
displayed at their site on their equipment. This means that the format
of the online files must meet the constraints of a wide variety of
printing and display equipment.
To meet these constraints the following rules are established for the
format of RFCs:
The character codes are ASCII.
Each page must be limited to 58 lines followed by a form feed on a
line by itself.
Each line must be limited to 72 characters followed by carriage
return and line feed.
No overstriking (or underlining) is allowed.
These "height" and "width" constraints include any headers, footers,
page numbers, or left side indenting.
Requests to be added to or deleted from this distribution list should be
sent to NIC@SRI-NIC. Submissions for RFCs should be sent to
POSTEL@USC-ISIF.
AI ELI5
On this page
§1Purpose of the Memo
RFC 825 clarifies the status of RFCs and gives guidance to future authors. It is, in a sense, a specification for RFCs. A memo may be published as an RFC to make information available, to begin or continue a discussion, or to specify a protocol.
It is a rulebook for how to write the internet's memos, and it explains why anyone would write one.
§2Stating the Intention
Each RFC is to include, on its title page or in the first or second paragraph, a statement describing its intention. The memo offers sample paragraphs for five kinds: Specification (a standard that ARPA Internet hosts are expected to adopt), Discussion (no proposed solutions are standards yet), Information (to solicit reactions), Status (current information, subject to change) and Report (results of a meeting).
The paragraphs need not be copied word for word, but the general intent of the RFC must be made clear.
Every memo should say right at the top whether it is a rule, an idea to talk about, a news note, a progress update or a meeting report.
§3Format Rules
RFCs are distributed online as public files, and people copy and print them on a wide variety of equipment. To fit, the character codes are ASCII, each page is limited to 58 lines followed by a form feed on a line by itself, and each line is limited to 72 characters followed by carriage return and line feed. Overstriking and underlining are not allowed.
These height and width limits include any headers, footers, page numbers and left indenting.
Every page has to be the same small size so it prints on any machine, and no fancy underlining is allowed.
§4Distribution and Submission
New RFCs are stored as public access files and a short message is sent to the distribution list saying the memo is available. Requests to join or leave the list go to NIC@SRI-NIC, and submissions for RFCs go to POSTEL@USC-ISIF.
When a new memo is ready, everyone on a mailing list gets a note. To join the list or send in a memo, you write to the addresses given.