INTERNET-DRAFT J. Reynolds, Editor
draft-rfc-editor-rfc2223bis-00.txt R. Braden, Editor
Obsoletes: 2223 RFC Editor
Category: Informational 20 February 2002
Expires: 20 August 2002
Instructions to Request for Comments (RFC) Authors
** DRAFT 20 Feb 2002 **
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This memo provides instructions for authors of Request for Comments
(RFC) documents, including formatting requirements and editorial
policies. This document addresses frequently asked questions, and
serves as a guideline for constructing a properly formatted RFC.
RFC Editor Informational [Page 1]
Internet-Draft Instructions to RFC Authors 20 February 2002
Table of Contents
1. Introduction .................................................. 3
1.1 The RFC Document Series ................................... 3
1.2 The RFC Editor ............................................ 3
1.3 The RFC Publication Process ............................... 4
2. RFC Editorial and Publication Policies ....................... 6
3. General Format Rules for RFCs ................................. 12
3.1 General ASCII Format Rules ................................ 12
3.2 Postscript Format Rules ................................... 15
3.3 Header and Footer Formats ................................. 16
3.4 Protocol Data Definitions ................................. 16
4. Required Sections in an RFC .................................. 17
5. RFC Information and Contacts .................................. 23
6. Acknowledgments ............................................... 23
Appendix A - RFC Boilerplate ..................................... 24
Appendix B - RFC Preparation Tools ............................... 25
Appendix C - ASCII Character Set ................................. 26
Appendix D - Changes from RFC 2223 ............................... 27
Normative References ............................................. 28
Informative References ........................................... 28
Security Considerations .......................................... 29
Authors' Addresses ............................................... 29
Full Copyright Statement ......................................... 30
RFC Editor Informational [Page 2]
Internet-Draft Instructions to RFC Authors 20 February 2002
1. Introduction
This Request for Comments (RFC) document provides instructions for
authors regarding the preparation of RFCs and describes RFC
publication policies.
1.1 The RFC Document Series
The Requests for Comments documents, commonly known as RFCs, form
a series of more than 3000 memos about computer communication and
packet switching networks. The official specification documents
of the Internet protocol suite are defined by the Internet
Engineering Task Force (IETF) and the Internet Engineering
Steering Group (IESG). These specifications are recorded and
published as standards track RFCs (described in a later section
and in RFC 2026). As a result, the RFC publication process plays
an important role in the Internet standards process.
The RFC series was started in 1969 as a set of technical and
organizational notes of the ARPAnet research community [1]. Since
the early 1980s, the series has focused on the development of the
Internet and the TCP/IP protocol suite. Memos in the RFC series
discuss many aspects of networking, including protocols,
procedures, programs, and concepts as well as meeting notes,
opinions, and sometimes humor. For more information on the
history of the RFC series, see RFC 2555, "30 Years of RFCs" [1].
The RFC numbers provide a single unique address space for locating
a particular RFC. It has proven useful to define specific subsets
or "sub-series" of the RFCs by attaching a secondary index. There
are three secondary indexes in use: -- FYI (For Your Information)
[4], BCP (Best Current Practice) [5], and STD (Standard) [6].
1.2 The RFC Editor
The RFC series is published by the RFC Editor, an organization
that is funded by the Internet Society (ISOC) and is a project at
the Information Sciences Institute of the University of Southern
California (USC/ISI).
The RFC Editor is responsible for the final editorial review and
the publication of RFCs. The RFC Editor also maintains the
official RFC archive and the master index file, which are
accessible via the Web, FTP, and email (see URL in Section 5.)
RFC Editor Informational [Page 3]
Internet-Draft Instructions to RFC Authors 20 February 2002
1.3 The RFC Publication Process
A more complete explanation of the RFC publication procedures will
be found in RFC 2026 [2].
1.3.1 RFC Submission
The procedure for submitting a document for publication as an
RFC differs slightly depending upon the document's source.
Submissions come from the IETF or from an individual.
Before the RFC Editor considers publication of a document, it
must first be submitted as an Internet-Draft (I-D) [1]. All
RFCs have been I-Ds, but not all I-Ds become RFCs.
o Submission from the IETF
RFCs most often originate in the IETF and are submitted to
the RFC Editor from the Internet Engineering Steering Group
(IESG). These submissions are transmitted via official
messages that are recorded at the IETF web site. An IESG
submission may have any of these status values: Proposed
Standard, Draft Standard, Standard, BCP, Experimental, or
Informational, as determined by the IESG. A document with
Proposed Standard, Draft Standard, or Standard status is
said to be a standards-track document [2].
IETF RFCs normally originate in working groups. However,
there are individual submissions to the IESG that have been
accepted into the IETF process.
o Individual Submission
Individuals can also submit Internet-Drafts directly to the
RFC Editor for publication as RFCs. Such individual
submissions may have Experimental or Informational status.
The choice is determined by the author with the agreement of
the IESG (see below).
Once the document has been posted as an Internet-Draft, you
should contact rfc-editor@rfc-editor.org and request that
your document be reviewed for publication as an
Informational or Experimental RFC (please specify which).
Note that the RFC Editor does not accept independent
standards track submissions, as all standards track
documents must be submitted to the appropriate area
directors of the IETF.
RFC Editor Informational [Page 4]
Internet-Draft Instructions to RFC Authors 20 February 2002
Since Internet-Drafts are precursors to RFCs, the rules for
formatting Internet-Drafts are consistent with the RFC
formatting rules presented below. Specific Internet-Draft
guidelines are available from the IETF web page.
If the author has used nroff to prepare the Internet-Draft, it
is helpful to make this available to the RFC Editor. If there
is a Postscript and/or PDF version of the document, the author
should inform the RFC Editor at the time of submission of the
ASCII version.
1.3.2 RFC Review
Memos intended to become RFCs must first be published as
Internet-Drafts. This allows feedback from members of the
Internet community and the IESG.
The IESG reviews IETF RFC submissions for quality and
conformance with IETF procedures. The IESG also reviews
individual submissions to ensure they do not conflict with work
in progress in the IETF and to ensure technical quality. When
the topic of an individual submission is closely related to an
existing IETF Working Group, the IESG may request that the
author coordinate with the working group. This may result in
the production of a revised memo as a working group Internet-
Draft, which will eventually emerge from the IETF process as a
publication recommendation from the IESG to the RFC Editor.
The IESG may suggest improvements to the author of the document
prior to publication. It may be determined that the submitted
document is not appropriate material for publication as an RFC.
In some cases the IESG will agree to the publication with the
addition of an "IESG Position" statement in the document that
defines a limited context within which the specification is
valid, to prevent its misuse.
The RFC Editor will publish all documents submitted from the
IESG but reserves the right to discuss with the IESG any issues
about particular documents. The RFC Editor makes the final
decision about individual submission publications.
1.3.3 Publication
Once a document has been submitted to the RFC Editor, it enters
the RFC Editor's queue. The queue is publicly accessible at
the RFC Editor Web site (Section 6). The RFC remains in the
queue until it is published, or until the IESG or author
requests that it be removed.
RFC Editor Informational [Page 5]
Internet-Draft Instructions to RFC Authors 20 February 2002
The RFC Editor ensures that the document follows the rules
described in this document. The RFC Editor may make minor
editorial changes to clarify readability and to provide a
uniform style and format. If significant changes are required
to satisfy the rules and/or to bring the RFC up to publication
quality, the memo will often be returned to the author for the
additional work.
When editing of the document is complete, the RFC Editor will
send the result to the authors for careful proof-reading. This
quality control step is critical to maintaining the quality of
RFCs. This process has a nominal 48 hour (2 working days)
timeout, so this is known as the "Authors' 48 Hours" process.
The RFC Editor is always willing to give authors a reasonable
amount of additional time to review the document. In general,
all listed authors are considered to be equally responsible for
the correctness of the final document.
In practice, the editorial process among the IESG, the RFC
Editor, and the author(s) can be lengthy and convoluted, and
the time spent in the RFC Editor's queue can vary greatly.
Problems found by either group often result in document
revisions by the authors. These revisions may require the
publication of another Internet-Draft, and the result must be
re-reviewed. Publication may be held up awaiting Internet
Assigned Numbers Authority (IANA) assignments, or in order to
synchronize publication with that of related RFCs.
2. RFC Editorial and Publication Policies
This section summarizes some general policies governing the
publication of RFCs.
2.1 Immutability
Since the RFCs form an archival series, an RFC cannot be altered
once it is published. To change the contents of an RFC, a new RFC
must be written that obsoletes the previous one. (Early in the
history of RFCs, the Editor did occasionally make small editorial
changes after publication, but this led to confusion regarding
which version was correct, and it was a slippery slope. To avoid
these pitfalls, the never-change rule is now strictly enforced.)
Although RFCs are subjected to careful scrutiny by the RFC Editor
and the authors before publication, errors do sometimes creep in.
For this reason, the RFC Editor stongly recommends that the
authors thoroughly review the document during the "authors' 48
hours" period.
RFC Editor Informational [Page 6]
Internet-Draft Instructions to RFC Authors 20 February 2002
The RFC Editor maintains an online list of errata for existing
RFCs. If you find what you believe to be an error in an RFC,
consult the errata page at the RFC Editor web site. If the bug is
not listed, please send e-mail to the authors of the document, and
cc: the RFC Editor at: rfc-editor@rfc-editor.org.
2.2 Not all RFCs are Standards
Eager salesmen have been known to imply that all RFCs represent
official Internet standards. This is completely false and
misleading. While some RFCs are standards track documents, many
have the status of Informational or Experimental and do not
represent a standard of any kind. Even those documents on the
standards track come in three grades -- Proposed Standard, Draft
Standard, and Standard -- and only the last is a full standard.
2.3 Publication Language
Like the Internet itself, the IETF and the Internet Society are
international organizations with representation from all areas of
the world. However, English is the primary language in which IETF
business is conducted, and English is the official publication
language for RFCs.
RFCs submitted for publication are required to meet a reasonable
standard for clear and correct English.
RFC 2026 specifically allows RFCs to be translated into languages
other than English. Repositories may exist for RFCs that have
been translated into particular languages. This is highly
desirable and useful. However, it is not possible for the RFC
Editor to certify that such translations are accurate. Therefore,
the function of the RFC Editor, with respect to non-English RFCs,
is limited to providing pointers to non-English language RFC
repositories. Upon request, the RFC Editor will list any such
repository on its Web page.
2.4 Publication Format(s)
RFCs are published as ASCII text (.txt) files. However, secondary
or alternative versions of an RFC may be provided in PostScript
and/or PDF, to allow the inclusion of fancy diagrams and graphs
that cannot possibly be rendered in ASCII.
The continued use of ASCII text for RFCs, despite the spread
of "more modern" printing formats, is intermittently debated
by the Internet community. The consensus continues to be
that the great advantages of plain ASCII text -- the ability
RFC Editor Informational [Page 7]
Internet-Draft Instructions to RFC Authors 20 February 2002
to readily edit, cut-and-paste, and search documents, as well
as the ubiquitous availability of tools for these functions
-- have made the ASCII choice a clear winner.
The ASCII text version is always the official specification, and
it must adequately and completely define the technical content.
(A very few exceptions have been made over the 30 year history of
RFCs, allowing a definitive .ps version with no .txt version.)
The primacy of the ASCII version typically requires that the
critical diagrams and packet formats be rendered as "ASCII art" in
the .txt version.
Postscript and PDF versions suffer from a serious flaw: the RFC
Editor cannot easily make editorial changes in the source file to
produce a new document in either of these formats. This makes the
editorial process somewhat painful for both the author and editor.
When a .ps (or .pdf) version is submitted with a .txt version, the
RFC Editor will first edit the .txt version. The final form of
the .txt version (or, when feasible, the diffs) will be returned
to the author. The author must then update the .ps/.pdf files to
match, as closely as possible, the content and format of the ASCII
.txt file. When the RFC Editor agrees that the .ps/.pdf versions
are acceptable, they will be published simultaneously.
However, an extremely popular operating system does not deal well
with ASCII files. For the convenience of the users of this
system, the RFC Editor provides PDF versions of all RFCs (see
Section 5).
2.5 Consistent Document Style
The RFC Editor attempts to enforce a consistent style of RFCs. To
do this, the RFC Editor may choose to reformat a submitted RFC or
ask the author to reformat it. Effort is minimized when the
submitted document matches the style of the most recent RFCs.
Please read the rules and recommendations that are presented in
following sections of this memo and look at some recent RFCs, to
adopt an appropriate style.
To format most ASCII RFCs for publication, the RFC Editor uses the
unix "nroff" program with a very simple set of the formatting
commands (or "requests") from the "ms" macro package (see Appendix
A). If a memo submitted to be an RFC has been prepared by the
author using nroff, it is helpful to make the nroff source
available when the document is submitted.
When a .ps version is published, the RFC Editor will also publish
a corresponding .pdf version by using the 'distill' utility.
RFC Editor Informational [Page 8]
Internet-Draft Instructions to RFC Authors 20 February 2002
2.6 Assignment of RFC Numbers
RFC numbers are not assigned until very late in the editorial
process to avoid gaps in the RFC number series. Requests for
early assignment of an RFC number for use in another forum are
generally denied unless they originate from the IAB (Internet
Architecture Board) or the IESG.
2.7 Normative References
Within an RFC, references to other documents fall into two general
categories: "normative" and "informative". Normative references
specify documents that must be read to understand or implement the
technology in the new RFC, or whose technology must be present for
the technology in the new RFC to work. An informative reference
is not normative; rather, it only provides additional information.
For example, an informative reference might provide background or
historical information. Material in an informative reference is
not required to implement the technology in the RFC.
The distinction between normative and informative references is
often important. The IETF standards process and the RFC Editor
publication process need to know whether a reference to a work in
progress is normative. An RFC cannot be published until all of
the documents that it lists as normative references have been
published. In practice, this often results in the simultaneous
publication of a group of inter-related RFCs.
An RFC should include separate lists of normative and informative
references (see Section 4.8 below.)
2.8 URLs in RFCs
The use of URLs in RFCs is discouraged, because many URLs are not
stable references. Exceptions may be made for normative
references in those cases where the URL is demonstrably the most
stable reference available.
2.9 Titles
Choosing an appropriate title for an RFC is not a trivial
exercise. A good title should fairly represent the scope and
purpose of the document, without being too general or too wordy.
Any acronyms in a title should be expanded, unless they are so
common (like TCP, IP, SNMP, FTP, etc.) that every member of the
IETF can be expected to recognize it immediately. It may be
helpful to follow the expansion with the parenthesized acronym.
RFC Editor Informational [Page 9]
Internet-Draft Instructions to RFC Authors 20 February 2002
"Encoding Rules for the Common Routing Encapsulation
Extension Protocol (CREEP)"
Authors should be aware that the title of an RFC may be subject to
policy considerations in addition to the requirement that it
provide a concise and technically sound summary of the document
contents. For example, at various times in the history of the
IETF, the words "Requirements" and "Policies" as well as the
phrase "The Directory" have been banned from RFC titles, each for
its own reason.
RFCs that document a particular company's private protocol must
bear a title of the form "Company XXX's ... Protocol", to clearly
differentiate it from an IETF product.
2.10 IANA Considerations
Many RFCs define protocol specifications that require the
assignment of values to protocol parameters, and some define new
parameter fields. Assignment of these parameter values is often
(and sometimes must be) deferred until publication of the defining
RFC. The IANA and the RFC Editor collaborate closely to ensure
that all required parameters are assigned and entered into the
final RFC text.
Any RFC that defines a new "namespace" [9] of assigned numbers
should include an IANA Considerations section specifying how that
space should be administered. See "Guidelines for Writing an IANA
Considerations Section in RFCs" [9] for a detailed discussion of
the issues to be considered and the contents of this section.
2.11 Relation to other RFCs
Sometimes an RFC adds information on a topic discussed in a
previous RFC or completely replaces an earlier RFC. Two terms are
used for these cases: Updates and Obsoletes, respectively.
Updates
Specifies an earlier document whose contents are modified or
augmented by the new document. The new document cannot be
used alone, it can only be used in conjunction with the
earlier document.
Obsoletes
Specifies an earlier document that is replaced by the new
document. The new document can be used alone as a
RFC Editor Informational [Page 10]
Internet-Draft Instructions to RFC Authors 20 February 2002
replacement for the obsoleted document. The new document
may contain revised information or all of the same
information plus some new information, however extensive or
brief that new information may be.
In lists of RFCs and in the RFC-Index (but not on the RFCs
themselves) the following are used for older documents that were
referred to by Obsoletes or Updates relations in newer documents:
Obsoleted-by
Used to specify newer document(s) that replace the older
document.
Updated-by
Used to specify newer document(s) that modify or augment the
older document.
2.12 Author Lists
Long lists of authors are not generally acceptable on RFCs. While
there may be occasional exceptions, in general the person (or the
few people) who WROTE the document should be listed as the
author(s). Others who contributed to developing the specification
may be listed in an Acknowledgment section. Even when there are a
number of significant contributors, there is usually a single
person tasked with integrating the results into a single document;
that person may be listed as "Editor", with acknowledgments for
the other contributors.
Objections to huge author lists are both practical and
ideological. The practical issues have to do with the long-
existing RFC formatting conventions that do not comfortably handle
large author lists. Ideological objections stem from the Internet
community's tradition of individual rather than corporate action
and responsibility. Some might see a list of 17 authors on one
RFC as motivated by a desire for corporate name-dropping, which
would be inappropriate in the IETF/RFC context. If there is a
desire to demonstrate how many companies are interested in this
spec, a simple acknowledgment section can accomplish the same
goal, without Author Overload.
2.13 April 1 RFCs
Many years ago the RFC Editor established the practice of
publishing one or more satire documents on April 1 of each year.
RFC Editor Informational [Page 11]
Internet-Draft Instructions to RFC Authors 20 February 2002
Readers should be aware that many of the RFCs bearing the date
April 1 are not to be taken seriously. The RFC Editor reviews
April 1 RFC submissions for cleverness, humor, and topical
association with computer networking, and a few of the best are
published. Submissions must be made to the RFC Editor in time for
review and publication.
3. General Format Rules for RFCs
The following formatting rules are intentionally incomplete in some
details. They attempt to define only what is strictly necessary for
uniformity and simplicity (a virtue). Some latitude is allowed to
accommodate a broad range of printers, systems, and evolving
requirements. The general objective is to create a series of
documents that are reasonably uniform and are easy to read, while
accommodating a wide range of content.
3.1 General ASCII Format Rules
(1) Character code
The character code is ASCII (See Appendix E). Only the
printable ASCII characters and the three control characters
CR, LF, and FF are allowed.
Notes: CR and LF must be used only as provided in rule
(2), and LF must be used only as provided in rule (3).
Tab (HT) characters and Backspace (BS) characters are
never allowed (hence there can be no underlining; see
(4) below).
(2) Width
Each line must be limited to 72 characters followed by the
character sequence that denotes an end-of-line (EOL). This
limit includes any left-side indentation.
Note: An ASCII RFC is expected to be stored on a file
disk using the EOL sequence of that system. For
example, MS DOS-based systems use the two-character
sequence CR LF (Carriage Return followed by Line Feed),
Unix systems use the single character LF for EOL, and
EBCDIC systems use the single character NL (New Line).
Whenever an RFC is transmitted across the Internet,
Internet protocol convention requires that each line of
text be followed by the two-character EOL sequence CR LF
(Carriage Return followed by Line Feed). A user level
RFC Editor Informational [Page 12]
Internet-Draft Instructions to RFC Authors 20 February 2002
protocol (e.g., FTP, Telnet, HTTP, SMTP, ...) must make
the appropriate EOL transformation at each line end.
Note that binary transmission of ASCII RFC files can
cause the sender's EOL convention to "leak" into the
receiver, causing confusion.
(3) Height
Each page must be limited to 58 lines followed by a Form Feed
(FF) character, followed by an EOL sequence. The 58 line
limit includes the headers and footers specified below.
All pages, except perhaps the first and last, should have the
same number of lines when headers and footers are included.
That is, footers should not "bounce" from page to page.
Note: The maximum line count includes blank lines.
However, the first line will normally be the first
header line and the last line will be the final footer
line; that is, it will not begin or end with a blank
line.
Note: 58 lines is the maximum; 55 is more commonly used
and may actually produce more readable formatting. The
nroff parameters suggested in Appendix A produce 55 line
pages on many printers, for example.
Note: The effect of the Height rule is that the
following character sequence will be used:
<Last non-blank line of page p> <EOL> FF <EOL>
<First line of page p+1> <EOL> ...
As transmitted across the Internet as ASCII text, the
character sequence is:
<Last non-blank line of page p> CR LF FF CR LF
<First line of page p+1> CR LF ...
Finally, note that the sequence FF CR LF has an
ambiguous effect: on some printers, the FF implies an
EOL, so this may produce a blank line; on other printers
it will produce no blank line. The number 58 and this
sequence were designed to render this ambiguity
unimportant, assuming the (once predominant) printer
standard of 60 lines per page.
RFC Editor Informational [Page 13]
Internet-Draft Instructions to RFC Authors 20 February 2002
(4) No Overstriking
No overstriking (or underlining) is allowed.
(5) No Filling
Do not fill the text with extra spaces to provide a straight
right margin. Do not right justify the text.
(6) No Hyphenation
Do not hyphenate words at the right margin.
Note: There are good reasons why the right page margin
is required to be "ragged", and why hyphenation of words
at the right margin is prohibited. Studies have shown
that text is harder to read when fixed-size spaces are
inserted to adjust the right margins, regardless of
which font is used or how smoothly the blank filler is
inserted. In addition, when technical text in a fixed-
width font is hyphenated at the right margin, the
printed result is not only less readable but also ugly.
(7) Spaces at the End of a Sentence
When a sentence ended by a period is immediately followed by
another sentence, there should be two blank spaces after the
period. This rule provides clarity when an RFC is displayed
or printed with a fixed-width font.
(8) Footnotes
Do not use footnotes. If such notes are necessary, put them
at the end of a section, or at the end of the document.
(9) Line Spacing
Use single-spaced text within a paragraph, and one blank line
between paragraphs.
(10) Page Numbering
Pages must be numbered consecutively, starting from 1 on the
first (cover) page.
RFC Editor Informational [Page 14]
Internet-Draft Instructions to RFC Authors 20 February 2002
(11) Headers and Footers
RFCs must have running headers and footers, as defined below
in Section 3C. The headers and footers must be separated
from the body by at least one and preferably two blank lines.
(12) Indentation
Successive indentation of sub-subsections (as in this
document, for example) is recommended but not required.
Experience has shown that indentation by multiples of 3
columns works well. In any case, the careful use of
indentation can make a very great improvement in the
readability of a document.
3.2 PostScript Format Rules
(1p) Standard page size is 8 1/2 by 11 inches.
(2p) Leave a margin of 1 inch on all sides (top, bottom, left, and
right).
(3p) Main text should have a point size of no less than 10 points
with a line spacing of 12 points.
(4p) Footnotes and graph notations no smaller than 8 points with a
line spacing of 9.6 points.
(5p) Three fonts are acceptable: Helvetica, Times Roman, and
Courier, plus their bold-face and italic versions. These are
the three standard fonts on most PostScript printers.
(6p) Prepare diagrams and images based on lowest common
denominator PostScript. Consider common PostScript printer
functionality and memory requirements.
(7p) The following PostScript commands should not be used:
initgraphics, erasepage, copypage, grestoreall, initmatrix,
initclip, banddevice, framedevice, nulldevice or renderbands.
Note that the number of pages in a document and the page
numbers on which various sections fall will likely differ
between the ASCII and the PostScript versions of an RFC.
Thus, cross references in the text by section number usually
are easier to keep consistent than cross references by page
number.
RFC Editor Informational [Page 15]
Internet-Draft Instructions to RFC Authors 20 February 2002
3.3 Header and Footer Formats
RFCs must include running headers and footers that obey the
following rules.
o Running Headers
The running header in one line (on page 2 and all subsequent
pages) has the RFC number on the left (RFC nnnn), the title
(possibly shortened) in the center, and the publication date
(Month Year) on the right.
o Running Footers
All pages contain a one-line running footer, with the author's
last name on the left, the category centered, and the page
number on the right ([Page nn]).
If there are two authors, the form "name & name" may be used;
for more than two authors, use the form "name, et al."
3.4 Protocol Data Definitions
Many years ago, the RFC series adopted a pictorial approach to
representing data structures such as protocol headers.
Furthermore, the research community adopted a "big-endian"
convention in which the bits and bytes are shown in network byte
order, byte zero is the first byte shown, and bit zero is the most
significant bit in a word or a field [8].
For example, RFC 791 contains the following definition of the IP
header format. We strongly recommend that a new RFC follow the
same formatting conventions, which have been found to work well.
RFC Editor Informational [Page 16]
Internet-Draft Instructions to RFC Authors 20 February 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Datagram Header
4. Sections in an RFC
An RFC may contain the following sections. Some of these are
optional, but if they are present they must be in this order (except
where noted).
1. First-page header
2. Status of this Memo
3. Copyright Notice
4. IESG Note
5. Abstract
6. Table of Contents
7. Body of memo
8. References
9. Security Considerations
10. IANA Considerations
11. Authors' Addresses
12. Full Copyright Statement
The rules for each of these sections are described below in
corresponding subsections.
The Body of the memo will normally contain section numbers. Sections
preceding the Body must not have section numbers; section numbers are
optional for sections following the Body.
RFC Editor Informational [Page 17]
Internet-Draft Instructions to RFC Authors 20 February 2002
4.1. First-Page Header
Please see the front page of this memo for an example of the front
page heading. On the first page there is no running header. The
top of the first page has the following items left justified:
"Network Working Group"
This traditional title must be left-justified on the first line
of the heading. It denoted the ARPANET research group that
founded the RFC series.
"Request for Comments: nnnn"
Identifies this as an RFC and specifies the number, left-
justified on the second line. The actual number is filled in
at the last moment prior to publication by the RFC Editor.
"BCP: nn" or
"FYI: nn" or
"STD: nn"
One of these optional left-justified items indicates the sub-
series number, if the RFC is a member of a sub-series.
"Updates: nnnn" or "Updates: nnnn, ..., nnnn"
Optional left-justified field, containing an RFC number or a
comma-separated list of RFC numbers that are updated by this
RFC. See Section 5.
"Obsoletes: nnnn" or "Obsoletes: nnnn, ... , nnnn"
Optional left-justified field, containing an RFC number or a
comma-separated list of RFC numbers that are obsoleted by this
RFC. See Section 5.
"Category: xxxxxxxxx"
Required left-justified field specifying the category (i.e.,
status) of this RFC. Here xxxxxxxx, the document status (see
RFC 2026 [2]), may be one of: Standards Track, Best Current
Practice, Informational, or Experimental.
The "Standards Track" category indicates that the status is one
of: Proposed Standard, Draft Standard, or Standard. The actual
status may be found in STD 1, "Official Internet Standards", or
from the RFC Editor web site.
RFC Editor Informational [Page 18]
Internet-Draft Instructions to RFC Authors 20 February 2002
The following information appears right-justified in the header:
Author
The author's name (first initial and last name only), right-
justified on the first line of the heading.
Organization
The author's organization, indicated on the line following the
Author name.
For multiple authors, each author name appears right-justified
on its own line, followed by that author's organization. When
more than one author has the same organization, the
organization can be "factored out" and appear only once
following the corresponding Author lines. However, such
factoring is not necessary if it results in an unacceptable
reordering of author lines.
Date
The month and year of the RFC Publication, right-justified on
the line after the last Organization line.
The title appears, centered, below the rest of the heading,
preceded and followed by at least one blank line. Periods
("dots") are not allowed in the title.
The title should be carefully chosen to accurately reflect the
contents of the document. See also Section 2.9.
4.2. Status of this Memo
Each RFC must include on its first page the "Status of this Memo"
section that contains two elements: (1) a paragraph describing the
type of the RFC, and (2) the distribution statement.
The required contents of this section will be found in Appendix B.
4.3 Copyright Notice
The Copyright Notice section consists of the statement, "Copyright
(C) The Internet Society (date). All Rights Reserved." and is
required. The Full Copyright Statement described in Section 4.12
must also appear at the end of the document.
RFC Editor Informational [Page 19]
Internet-Draft Instructions to RFC Authors 20 February 2002
4.4 IESG Note
This optional section will appear only when the IESG requires and
specifies a clarifying comment on an RFC.
4.5 Abstract
Every RFC must have an Abstract section following the Copyright
notice. An Abstract will typically be 5-10 lines, but an Abstract
of more than 20 lines or less than 3 lines is generally useless
and is not acceptable.
The Abstract section should provide a concise and comprehensive
overview of the purpose and contents of the entire document, to
give a technically knowledgable reader a general overview of the
function of the document. In addition to its function in the RFC
itself, the Abstract section text will be used as a summary in
publication announcements and in the online index of RFCs.
Usually an Abstract should begin with a phrase like "This memo
..." or "This document ...". Composing a useful Abstract
generally requires thought and care. A satisfactory abstract can
often be constructed in part from material within the Introduction
section, but a good abstract will be shorter, less detailed, and
perhaps broader in scope than the Introduction. Simply copying
and pasting the first few paragraphs of the Introduction is
tempting, but generally results in an Abstract that is at once
incomplete and redundant. Note also that an Abstract is not a
substitute for an Introduction; the RFC should be self-contained
as if there were no Abstract section.
An Abstract should be complete in itself; it should not contain
citations unless they are completely defined within the Abstract.
Mnemonics appearing in the Abstract should generally be expanded
in parentheses. There is a small set of reasonable exceptions to
this rule; for example, readers do not need to be reminded of the
meaning of the mnemonics "IP" or "TCP" or "MIB". In the end,
therefore, this is a judgment call, but please err on the side of
explicitness.
4.6 Table of Contents
A Table of Contents (TOC) section is required in RFCs longer than
30 pages and recommended for an RFC longer than 15 pages.
A TOC must be positioned after the Abstract and before the
Introduction section (i.e., after the "boiler plate" and before
the body of the RFC.)
RFC Editor Informational [Page 20]
Internet-Draft Instructions to RFC Authors 20 February 2002
The TOC itself should not be too long or detailed, or it loses
value. For example, if many successive TOC entries point to the
same pages of the memo, the TOC probably needs to be coarser.
No specific format is required, but the following example
illustrates a useful format:
1. INTRODUCTION ............................................... 5
1.1 The Internet Architecture .............................. 6
1.1.1 Internet Hosts .................................... 6
1.1.2 Architectural Assumptions ......................... 7
1.1.3 Internet Protocol Suite ........................... 8
1.1.4 Embedded Gateway Code ............................. 10
1.2 General Considerations ................................. 12
1.2.1 Continuing Internet Evolution ..................... 12
1.2.2 Robustness Principle .............................. 12
1.2.3 Error Logging ..................................... 13
4.7 Body of Memo
Following the Table of Contents, if any, comes the body of the
memo. Depending upon the length of the TOC, a judicious page
break can improve readability.
Each RFC should have an Introduction section that (among other
things) explains the motivation for the RFC and (if appropriate)
describes the applicability of the document, e.g., whether it
specifies a protocol, provides a discussion of some problem, is
simply of interest to the Internet community, or provides a status
report on some activity.
Many RFC documents have appendices, some of which may be very
extensive. It is often customary in academic publications to
place appendices at the very end, after references. This is
permissible in an RFC, but we recommend that an author place any
appendices at the end of the body of the text and before the
references. This is appropriate because the references of an RFC
may be normative and should therefore be clearly accessible at the
very end of the document.
4.8 References Section
Nearly all RFCs contain citations to other documents, listed near
the end of the RFC. There are many styles for references, and the
RFCs have one of their own. Please follow the reference style
used in recent RFCs; in particular, see the Reference section of
this RFC for an example.
RFC Editor Informational [Page 21]
Internet-Draft Instructions to RFC Authors 20 February 2002
For a reference to an RFC that has been assigned an STD, BCP, or
FYI subseries number, that subseries number must be included in
the reference.
In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. BCP 14, RFC 2119 [3], defines these words as
they should be interpreted in IETF documents.
Reference lists must indicate whether each reference is normative
or informative. For example, if both normative and informative
references are included, then the reference section should be
split into two sections, e.g.:
s. Normative References
xxx
...
xxx
s+1. Informative References
xxx
...
xxx
Non-normative references to Internet-Drafts are allowed, but they
must take the following restricted form: the author(s), the title,
and the phrase "Work in Progress", for example:
[6] Doe, J., "The Deployment of IPv6", Work in Progress.
The use of URLs in references in RFCs is discouraged, because URLs
are often not stable references. Exceptions will be made in
certain cases where the World Wide Web is demonstrably the most
stable reference available.
4.9 Security Considerations Section
All RFCs must contain a section near the end of the document that
discusses the security considerations of the specification that
are the main topic of the RFC.
4.10 IANA Considerations Section
See Section 2.10 above.
RFC Editor Informational [Page 22]
Internet-Draft Instructions to RFC Authors 20 February 2002
4.11 Author's Address Section
Each RFC must have at the end a section giving the author's
address, including the name and postal address, the telephone
number, (optional: a FAX number) and the Internet email address.
4.12 Full Copyright Statement
Per BCP 9, RFC 2026 [2], "The following copyright notice and
disclaimer shall be included in all ISOC standards-related
documentation." This is the "Full Copyright Statement", whose
text will be found at the end of this RFC as well as in RFC 2026.
A specific request from the IAB is required before the RFC Editor
can include a dual copyright, or for any other variation of the
standard ISOC copyright notice.
5. RFC Information and Contacts
************************************************************
* *
* RFC Editor Email: rfc-editor@rfc-editor.org *
* *
* *
* RFC Editor URL: http://www.rfc-editor.org *
* *
* *
************************************************************
RFC publication announcements are distributed via two mailing lists:
the "IETF-Announce" list, and the "RFC-DIST" list. You don't want to
be on both lists. To join (or quit) the IETF-Announce list send a
message to ietf-request@ietf.org. To join (or quit) the RFC-DIST
list send a message to rfc-dist-request@isi.edu.
RFC readers should be aware that the many mirrors of RFCs and RFC
indexes that appear on other sites vary a great deal in reliability.
Consulting the official RFC-Editor site is recommended.
6. Acknowledgments
This memo includes wording taken from a draft written by Robert W.
Shirey of GTE/BBN Technologies, 29 December 1999, with permission.
Shirey's deconstruction of the formatting rules was very helpful in
writing Sections 3 and 4 of the present memo.
RFC Editor Informational [Page 23]
Internet-Draft Instructions to RFC Authors 20 February 2002
APPENDIX A: RFC Boilerplate
This Appendix defines standard wording required in every RFC.
Standards Track
"This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol. Distribution
of this memo is unlimited."
Best Current Practice
"This document specifies an Internet Best Current Practices for
the Internet Community, and requests discussion and suggestions
for improvements. Distribution of this memo is unlimited."
Experimental
"This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited."
Informational
"This memo provides information for the Internet community. This
memo does not specify an Internet standard of any kind.
Distribution of this memo is unlimited."
RFC Editor Informational [Page 24]
Internet-Draft Instructions to RFC Authors 20 February 2002
APPENDIX B: RFC Preparation Tools
As indicated earlier, the primary submission format for RFCs is ASCII
text. Authors have found various tools to be useful for preparing
this text in the format required by RFCs and Internet-Drafts.
This Appendix surveys some of the possibilities.
nroff, groff
The nroff program is widely available for Unix systems, while
its freeware equivalent groff is available for an even wider
range of platforms, including Windows. These programs use
directives in the text to control the formatting. The RFC
Editor, in particular, uses nroff for final RFC formatting. A
template is available as 2-nroff.template.
XML
An XML DTD for RFCs has been developed [7]. There is also an
XML-to-nroff translator suitable for creating RFC text. RFC
Editor experience with this procedure is limited, but it has
worked very well.
Microsoft Word
Microsoft Word is an important example of a WYSIWYG editor. RFC
xxxx [Hain] describes in detail how to configure Word to produce
an ASCII text file in RFC format. A version of this document as
a Word file (2-Word.Template.doc) can be used as a template file
to initialize this configuration for entering and displaying
RFCs. There is also a DOS executable (crlf.exe) for a post-
processor to establish RFC end-of-line conventions in the Word
output file.
Latex
Latex is widely used for text preparation in many academic
environments. A convenient Latex template is available as 2-
latex.template.
Latex in general does not produce plain ASCII text in the RFC
format, but several people have written their own Latex-to-nroff
translators for creating the RFC format. None of these are
publicly available at this time.
RFC Editor Informational [Page 25]
Internet-Draft Instructions to RFC Authors 20 February 2002
APPENDIX C. ASCII Character Set
The set of 128 ASCII codes includes the 33 control characters shown
in Table 1 and the 95 graphic characters shown in Table 2. Decimal
values are given.
Table 1. ASCII Control Characters
Dec Chr Meaning Dec Chr Meaning
--- --- --------------- --- ---- ---------------
000 NUL null 016 DLE dev link esc
001 SOH start header 017 DC1 dev ctrl 1
002 STX start text 018 DC2 dev ctrl 2
003 ETX end text 019 DC3 dev ctrl 3
004 EOT end of transmit 020 DC4 dev ctrl 4
005 ENQ enquiry 021 NAK negative ack
006 ACK acknowledge 022 SYN sync idle
007 BEL bell (beep) 023 ETB end trans block
008 BS back space 024 CAN cancel
009 HT horiz tab 025 EM end medium
010 LF line feed 026 SUB substitute
011 VT vert tab 027 ESC escape
012 FF form feed 028 FS cursor right
013 CR carriage ret 029 GS cursor left
014 SO shift out 030 RS cursor up
015 SI shift in 031 US cursor down
127 DEL delete
Table 2. ASCII Graphic Characters
Dec Char Dec Char Dec Char Dec Char Dec Char Dec Char
--- ------- --- ------ --- ------ --- ------ --- ------ --- ----
032 [space] 0 0 064 @ 080 P 096 ` 112 p
033 ! 049 1 065 A 081 Q 097 a 113 q
034 " 050 2 066 B 082 R 098 b 114 r
035 # 051 3 067 C 083 S 099 c 115 s
036 $ 052 4 068 D 084 T 100 d 116 t
037 % 053 5 069 E 085 U 101 e 117 u
038 & 054 6 070 F 086 V 102 f 118 v
039 ' 055 7 071 G 087 W 103 g 119 w
040 ( 056 8 072 H 088 X 104 h 120 x
041 ) 057 9 073 I 089 Y 105 i 121 y
042 * 058 : 074 J 090 Z 106 j 122 z
043 + 059 ; 075 K 091 [ 107 k 123 {
044 , 060 < 076 L 092 \ 108 l 124 |
045 - 061 = 077 M 093 ] 109 m 125 }
046 . 062 > 078 N 094 ^ 110 n 126 ~
047 / 063 ? 079 O 095 _ 111 o
RFC Editor Informational [Page 26]
Internet-Draft Instructions to RFC Authors 20 February 2002
APPENDIX D: Changes from RFC 2223
Section 1: Introduction
This section was completely rewritten, using material from several
sections of RFC 2223 and bringing the discussion into conformance
with RFC 2026.
Section 2: RFC Editorial and Publication Policies
This section combines material from several sections of RFC 2223.
New material is included about the RFC Editor errata page,
normative references, URLs, titles, RFC number pre-assignment,
author lists, and IANA Considerations.
There are two changes of procedure: (1) publication of an RFC in
both ASCII and Postscript versions now requires that both be
published simultaneously, and (2) all listed authors must give
approval during the "Authors' 48 Hour" process.
Section 3: General Format Rules
This section is expanded with much additional explanatory
material. For example:
(1) The requirement for printable ASCII characters is
stated, and the use of CR, LF, and FF is clarified.
(2) A table of ASCII character codes in included in an
Appendix.
(3) The requirement for page numbers in specified.
(4) The requirement for running headers and footers is
specified.
Section 4: Required Sections in an RFC
This section is reorganized to cover all the required sections of
an RFC in order. It adds the current conventions for formatting
multiple author names and organizations.
This section describes four major changes in RFC formatting.
(1) The style and contents of the Abstract section are more
completely specified in order to make an RFC abstract
more useful for searching and indexing RFCs.
RFC Editor Informational [Page 27]
Internet-Draft Instructions to RFC Authors 20 February 2002
(2) A Table of Contents section is required or recommended
in all but very short RFCs.
(3) Separate lists are now required for normative references
and informative references.
Appendixes
Former Appendix A, which contained the source for the fix.pl
post-processor Perl script and an nroff RFC template, has been
removed. These files are available at the RFC Editor web site.
Appendix B, RFC Preparation Tools, and Appendix C, defining the
ASCII character set, are new.
Normative References
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Informative References
[1] RFC Editor et al., "30 Years of RFCs", RFC 2555, 7 April 1999.
[4] Malkin, G. and J. Reynolds, "F.Y.I. on F.Y.I Introduction to the
F.Y.I. Notes", FYI 1, RFC 1150, March 1990.
[5] Postel, J., Li, T. and Y. Rekhter, "Best Current Practices", BCP
1, RFC 1818, August 1995.
[6] Postel, J., Editor, "Introduction to the STD Notes", RFC 1311,
March 1992.
[7] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999.
[8] Cohen, D., "On Holy Wars and a Plea for Peace", Internet
Experimental Note (IEN) 137, 1 April 1980.
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
RFC Editor Informational [Page 28]
Internet-Draft Instructions to RFC Authors 20 February 2002
Security Considerations
This RFC describes the Security Considerations sections of an RFC.
Authors' Addresses
Joyce K. Reynolds
RFC Editor
4676 Admiralty Way
Marina del Rey, CA 90292
EMail: rfc-editor@rfc-editor.org
Robert Braden
RFC Editor
4676 Admiralty Way
Marina del Rey, CA 90292
EMail: rfc-editor@rfc-editor.org
RFC Editor Informational [Page 29]
Internet-Draft Instructions to RFC Authors 20 February 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Acknowledgement:
Funding for the RFC Editor function is currently provided by the
Internet Society.
RFC Editor Informational [Page 30]
