INTERNET-DRAFT J. Reynolds, Editor
draft-rfc-editor-rfc2223bis-05.txt R. Braden, Editor
Obsoletes: 2223 RFC Editor
Category: Best Current Practice 5 June 2003
Expires: December 2003
Instructions to Request for Comments (RFC) Authors
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 (2003). All Rights Reserved.
Abstract
This memo provides information for authors of Request for Comments
(RFC) documents. It summarizes RFC editorial policies and formatting
requirements, addresses frequently-asked questions, and serves as a
model for constructing a properly formatted RFC.
RFC Editor Informational [Page 1]
Internet-Draft Instructions to RFC Authors 5 June 2003
Table of Contents
1. Introduction .................................................. 4
1.1 Background on the RFC Document Series ..................... 4
1.2 Introduction to the RFC Publication Process ............... 4
2. General RFC Editorial Policies ............................... 8
2.1 Immutability .............................................. 8
2.2 Not all RFCs are Standards ................................ 8
2.3 Publication Language ...................................... 8
2.4 Publication Format(s) ..................................... 9
2.5 Consistent Document Style ................................. 10
2.6 Assignment of RFC Numbers ................................. 10
2.7 References and Citations .................................. 10
2.8 URLs in RFCs .............................................. 11
2.9 Titles .................................................... 11
2.10 IANA Considerations ...................................... 12
2.11 Relation to Other RFCs ................................... 12
2.12 Authors Listed on RFCs ................................... 13
2.13 April 1 RFCs ............................................. 14
2.14 Requirement-Level Words .................................. 14
2.15 Formal Languages in RFCs ................................. 15
3. General Format Rules for RFCs ................................. 15
3.1 General Formatting Rules .................................. 15
3.2 PostScript Format Rules ................................... 18
3.3 Header and Footer Formats ................................. 19
3.4 Protocol Data Definitions ................................. 19
4. Required Sections in an RFC .................................. 21
5. RFC Information and Contacts .................................. 28
Security Considerations .......................................... 28
Acknowledgments .................................................. 28
Appendix A - RFC Boilerplate ..................................... 29
Appendix B - RFC Preparation Tools ............................... 30
Appendix C - Checklist ........................................... 31
Appendix D - Changes ............................................. 33
Normative References ............................................. 36
Informative References ........................................... 37
Authors' Addresses ............................................... 37
Full Copyright Statement ......................................... 38
RFC Editor Informational [Page 2]
Internet-Draft Instructions to RFC Authors 5 June 2003
1. Introduction
This memo provides information for authors of Request for Comments
(RFC) documents. It summarizes RFC editorial policies and formatting
requirements, addresses frequently-asked questions, and serves as a
model for constructing a properly formatted RFC.
1.1 Background on the RFC Document Series
The Requests for Comments documents, commonly known as RFCs, form
an archival series of more than 3500 memos about computer
communication and packet switching networks. Included prominently
in the RFC series are the official technical specifications of the
Internet protocol suite; these are defined by the Internet
Engineering Task Force (IETF) under the direction of the Internet
Engineering Steering Group (IESG). As a result, RFC publication
plays a significant role in the Internet standards process
[RFC2026].
The RFC series was begun in 1969 as a set of technical and
organizational notes by the ARPAnet research community. 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"
[Hist99].
RFCs are numbered (roughly) consecutively, and these numbers
numbers provide a single unique label space for all RFCs. RFCs
are published on-line through a number of repositories (see
[RFCed]), and there is an online index of RFCs.
Each RFC is labeled with a category: Standards Track, Best Current
Practice, Experimental, Informational, or Historic.
Note on terminology: The Category attribute of an RFC has
sometimes been called its status, but the term "status" has
been overloaded. In the early years, it was used to mean the
"requirement level" of a specification, e.g., "Required" or
"Elective". (See STD 1, RFC 2400 or earlier.) Later this
single status attribute proved too simplistic, so it was
replaced by more general Applicability Statements [RFC2026].
Still later, we began to refer to the "category" as the
"status" (see e.g., the wording for the Standards Track
Status of this Memo, shown in Appendix A). However, this
attribute has always appeared on RFCs as the Category (see
RFC Editor Informational [Page 3]
Internet-Draft Instructions to RFC Authors 5 June 2003
Section 4.1.)
RFCs in the Standards Track category are published on behalf of
the IESG. The IESG assigns a maturity level -- Proposed Standard,
Draft Standard, or Standard -- to each Standards Track RFC. The
current maturity levels of all Standards Track RFCs are specified
in STD 1, "Official Internet Protocol Standards" [STD1] and in the
RFC index; they are not specified on the RFCs themselves.
In addition to the master RFC index, there are secondary indexes
for useful subsets or "sub-series" of the RFCs. Three sub-series
are in use:
o STD document -- Category is Standards Track, maturity level
is Standard [STD92].
o BCP document -- Category is Best Current Practice [BCP95]
o FYI document (For Your Information) -- Category is
Informational [FYI90]
An RFC in a sub-series is labeled with its sub-series number as
well as its RFC number.
The RFC series is published by the RFC Editor, under funding
provided by the Internet Society (ISOC) and under the supervision
of the Internet Architecture Board (IAB). The RFC Editor is
responsible for the final editorial review and the on-line
publication of RFCs. The RFC Editor also maintains the official
RFC archive and the index files and makes these accessible via the
Web, FTP, and email [RFCed]. The RFC Editor also maintains a list
of errata for previously-published RFCs.
In performing these functions, the RFC Editor works closely with
the IESG and with the Internet Assigned Numbers Authority (IANA).
Since 1977, the RFC Editor function has been performed by staff at
the Information Sciences Institute of the University of Southern
California (USC/ISI).
1.2 Introduction to the RFC Publication Process
This section contains a brief overview of the submission, review,
and publication process for RFCs. More details, especially for
standards-track RFCs, will be found in RFC 2026, "The Internet
Standards Process -- Revision 3" [RFC2026]. RFC 2026 or its
successor takes precedence in the case of any apparent conflict
with this overview.
RFC Editor Informational [Page 4]
Internet-Draft Instructions to RFC Authors 5 June 2003
1.2.1 RFC Submission and Review
To be considered for publication as an RFC, a document must
first be submitted as an Internet-Draft (I-D) [RFC2026]. This
ensures an opportunity for feedback from members of the
Internet community and from the IESG. The Internet Draft must
include boilerplate that allows RFC publication (see
"Guidelines to Authors of Internet-Drafts" [IDnits]).
The submission and review procedures for RFCs depend upon the
document's source. RFC submissions may come from the IETF,
from the IAB, from the Internet Research Task Force (IRTF), or
from an individual.
o Submission from the IETF
RFCs originating in the IETF are submitted to the RFC Editor
via the IESG, which reviews them for technical quality and
procedural conformance. These IESG submissions are
transmitted to the RFC Editor via official "Protocol Action"
messages that are recorded at the IETF web site.
Submissions through the IESG may be in any of the categories
(Standards Track, Best Current Practice, Experimental,
Informational, or Historic.) All submissions in the
Standards Track or Best Current Practice category must first
be submitted to the IESG for approval; the IESG will submit
them to the RFC Editor.
At IESG request, the RFC Editor will add an "IESG Note" to a
published RFC, to provide clarification or guidance to
readers.
o Submission from the IAB
The IAB may submit documents directly to the RFC Editor for
publication as RFCs in the Informational or Experimental
category, without IESG approval or review.
o Individual Submission
Individuals may submit documents directly to the RFC Editor
for publication as RFCs in the Experimental or Informational
category.
The RFC Editor reviews each such individual submission for
relevancy and appropriateness as well as general compliance
with the rules in Sections 2, 3 and 4 of this document.
Updates are requested as necessary, sometimes through
RFC Editor Informational [Page 5]
Internet-Draft Instructions to RFC Authors 5 June 2003
several iterations, until an acceptable submission document
is achieved.
To maintain the integrity of the RFC document series and to
avoid wasting scarce publication resources, the RFC Editor
may occasionally determine that a submission is not
publishable because of its content or its form. In such a
case, the RFC Editor will attempt to explain as clearly and
completely as possible the reasons for rejection. The RFC
Editor is always hopeful of a miracle -- that a bad document
will re-emerge as a good document -- and occasionally it
happens!
Once the document is clearly publishable, the RFC Editor
passes the document to the IESG for review for conflicts
with works in progress in the IETF [RFC2026]. 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 that working group. This may result
in the production of a revised memo that eventually emerges
from the IETF process as an IETF submission. The IESG may
also suggest improvements to the author of the document
prior to publication.
If the IESG feels that the submitted document is
inappropriate material for publication as an RFC, they will
make a "Do Not Publish" recommendation to the RFC Editor.
The RFC Editor may then reject the document, or publish it
with an "IESG Position" statement that defines their
objections to the document or narrows its scope of
applicability. The IESG may also ask for deferred
publication, in a maximum of two six-month increments. The
RFC Editor makes the final decision about publication of
individual submissions.
o Submission from the IRTF
RFC submissions from IRTF members are treated as individual
submissions.
1.2.2 RFC Publication
A document that is submitted to the RFC Editor enters the
RFC Editor's queue, which is publicly accessible at the RFC
Editor Web site [RFCed]. The RFC remains in the queue until
it is published or until the IESG or the author requests
that it be removed.
RFC Editor Informational [Page 6]
Internet-Draft Instructions to RFC Authors 5 June 2003
The RFC Editor ensures that the document follows the
editorial rules described later in this document. The RFC
Editor may make editorial changes to clarify readability and
to provide a uniform style and format. If excessive work is
required to satisfy the rules and/or to bring the RFC up to
publication quality, the memo may be returned to the author
or to the IESG for additional work.
When editing of the document is complete, the RFC Editor
sends the result to the authors for careful proof-reading.
This quality control step is critical to maintaining the
quality of RFCs. Although this process is traditionally
called the "Authors' 48 Hours" period, the RFC Editor is
always willing to give authors reasonable additional time to
review the document, and a document will not be published
until all its listed authors agree. While it is helpful to
have one principal author during the editing process, all
listed authors will be considered 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.
Sometimes problems are found that require 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 IANA
assignments, or in order to synchronize the publication of
related RFCs.
2. General RFC Editorial Policies
This section summarizes some general editorial and publication
policies for RFCs. Individual policies may be modified or new
policies added by the RFC Editor and the IESG, before the present
document is revised. RFC authors should obtain the latest policy
statements (see "News") from the RFC Editor web page [RFCed].
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.)
RFC Editor Informational [Page 7]
Internet-Draft Instructions to RFC Authors 5 June 2003
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 strongly urges the authors to
thoroughly review the document during the "Authors' 48 hours"
period.
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 [RFCed]. If
the bug is not listed, please send email to the authors of the
document and to the RFC Editor.
2.2 Not all RFCs are Standards
Eager salesmen have been known to imply that all RFCs represent
official Internet standards. This is false and misleading. While
some RFCs are Standards Track documents, many have other
categories and do not represent a standard of any kind.
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 plain text files in the [US-]ASCII character
set, with the file name extension ".txt".
The continued use of ASCII plain text for RFCs, despite the
spread of "more modern" formats, is intermittently debated by
the Internet community. The consensus continues to be that
RFC Editor Informational [Page 8]
Internet-Draft Instructions to RFC Authors 5 June 2003
the great advantages of ASCII plain text -- the ability to
readily edit, cut-and-paste, and search documents, the
ubiquitous availability of tools for these functions, and the
longevity of US-ASCII as a character standard -- make ASCII
plain text the clear winner.
For the convenience of those whose operating systems have
difficulty supporting plain ASCII text, the RFC Editor also
maintains PDF files that are exact facsimiles of the plain text
versions. These PDF files, with suffix .txt.pdf, are equally
authoritative with the .txt versions.
The ASCII plain text version (and its .txt.pdf facsimile) 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 PostScript (.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.
However, secondary or alternative versions in PostScript and/or
PDF are provided for some RFCs, to allow the inclusion of fancy
diagrams, graphs, or characters that cannot possibly be rendered
in ASCII plain text. If there is a PostScript or PDF version of
the document, the author should inform the RFC Editor at the time
of submission of 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 can make
the editorial process for .ps and .pdf versions somewhat painful
for both the author and editor. The following procedure is
followed. 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 are published
simultaneously with the .txt version.
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.
RFC Editor Informational [Page 9]
Internet-Draft Instructions to RFC Authors 5 June 2003
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
B). 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 to the RFC Editor when the document is submitted.
When a .ps version is published, the RFC Editor will also publish
a matching .pdf version. When a .txt version is published, the
RFC Editor will also publish a matching .txt.pdf version.
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 are generally denied unless they
originate from the IAB or the IESG.
2.7 References and Citations
An RFC will generally contain bibliographic references to other
documents, and the body will contain citations to these
references. Section 4.7f specifies the format for the references
listed at the end of the RFC body, but there is no required format
for a citation.
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.
An RFC must include separate lists of normative and informative
references (see Section 4.7f below.) 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. A
standards-track 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
RFC Editor Informational [Page 10]
Internet-Draft Instructions to RFC Authors 5 June 2003
group of inter-related RFCs.
We recommend enclosing citations in square brackets ("[ ]").
Simple numeric citations ("[53]") can cause confusing gaps when
the list of references is split between normative and informative.
A good alternative is to have two separate series, "[n1]", "[n2]",
... "[i1]", "[i2]" for citations to normative and informative
referenes. Other choices include author abbreviations, possibly a
year ("[Smith93]") ], and some brief encoding of the title and
year ("[MPLS99a]").
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. References to long-lived files on
ietf.org and rfc-editor.org are also acceptable.
RFCs that include URLs as generic examples must be careful to use
the particular example URLs defined in RFC 2606, "Reserved Top-
Level DNS Names" [TLD99], to avoid accidental conflicts with real
URLs.
2.9 Titles
Choosing a good title for an RFC can be a challenge. A good title
should fairly represent the scope and purpose of the document
without being either too general or too specific.
Abbreviations (e.g., acronyms) in a title (as well as the Abstract
and the body; see Sections 4.5 and 4.7) must generally be expanded
when first encountered. The exception is abbreviations that are
so common that every participant in the IETF can be expected to
recognize them immediately; examples include (but are not limited
to) TCP, IP, SNMP, and FTP. Some cases are marginal and the
decision on expansion may depend upon the specific title. The RFC
Editor will make the final judgment, weighing obscurity against
complexity.
It is often helpful to follow the expansion with the parenthesized
abbreviation, as in the following example:
Encoding Rules for the
Common Routing Encapsulation Extension Protocol (CREEP)
RFC Editor Informational [Page 11]
Internet-Draft Instructions to RFC Authors 5 June 2003
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 "XXX's ... Protocol" (where XXX is a
company name), 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" 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" [IANA98] 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
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
RFC Editor Informational [Page 12]
Internet-Draft Instructions to RFC Authors 5 June 2003
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 Authors Listed on RFC
The IESG and IETF have ratified a policy of limiting the number of
authors listed in the first page header of an RFC. The specific
policy is as follows:
(1) A small set of author names, with affiliations, may appear on
the front page header. These should be the lead author(s)
who are most responsible for the actual text. When there are
many contributors, the best choice will be to list the person
or (few) persons who acted as document editor(s) (e.g.,"Tom
Smith, Editor").
There is no rigid limit on the size of this set, but there is
likely to be a discussion if the set exceeds five authors, in
which case the right answer is probably to list one editor.
The RFC Editor will hold all the people listed on the front
page equally responsible for the final form and content of
the published RFC. In particular, the "Author's 48 Hours"
final approval period will require signoff from all listed
authors.
(2) An RFC may include a Contributors section, listing those
contributors who deserve significant credit for the document
contents. The Contributors section is intended to provide a
level of recognition greater than an acknowledgment and
nearly equal to listing on the front page. The choice of
either, both, or none of Contributor and Acknowledgment
sections in a particular RFC depends upon the circumstance.
RFC Editor Informational [Page 13]
Internet-Draft Instructions to RFC Authors 5 June 2003
(3) The body of an RFC may include an Acknowledgements section,
in addition to or instead of a Contributors section. An
Acknowledgments section may be lengthy, and it may explain
scope and nature of contributions. It may also specify
affiliations.
(4) The Author's Address section at the end of the RFC must
include the authors listed in the front page header. The
purpose of this section is to (1) unambiguously define
author/contributor identity (e.g., the John Smith who works
for FooBar Systems) and to (2) provide contact information
for future readers who have questions or comments.
At the discretion of the author(s), contact addresses may
also be included in the Contributors section for those
contributors whose knowledge makes them useful future
contacts for information about the RFC.
(5) The RFC Editor may grant exceptions to these guidelines upon
specific IESG request or in other exceptional circumstances.
2.13 April 1 RFCs
Many years ago the RFC Editor established the practice of
publishing one or more satirical documents on April 1 of each
year. 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.
Note that in past years the RFC Editor has sometimes published
serious documents with April 1 dates. Readers who cannot
distinguish satire by reading the text may have a future in
marketing.
2.14 Requirement-Level Words
Some standards-track documents use certain capitalized words
("MUST", "SHOULD", etc.) to specify precise requirement-levels for
technical points. RFC 2119 (BCP 14) [BCP14] defines a default
interpretation of these capitalized words in IETF documents. If
this interpretation is used, RFC 2119 must be cited (as specified
in RFC 2119) and included as a normative reference. Otherwise,
the correct interpretation must be specified in the document.
RFC Editor Informational [Page 14]
Internet-Draft Instructions to RFC Authors 5 June 2003
Avoid abuse of requirement-level words. They are intended to
provide guidance to implementors about specific technical
features, generally governed by considerations of
interoperability. RFC 2119 says, "Imperatives of the type defined
in this memo must be used with care and sparingly. In particular,
they MUST only be used where it is actually required for
interoperation or to limit behavior which has potential for
causing harm (e.g., limiting retransmisssions) For example, they
must not be used to try to impose a particular method on
implementors where the method is not required for
interoperability." To simply specify a necessary logical
relationship; the normal lower-case words should be used. On the
other hand, if the capitalized words are used in a document, they
must be used consistently throughout the document.
2.15 Formal Languages in RFCs
See [Lang01] for IESG guidance on the use of formal languages in
RFCs. The RFC Editor will run every MIB through a MIB checker
before publication, and machine verification of other formal
languages included in RFCs may be required.
3. General Format Rules for RFCs
This section defines the general rules governing the format of a
published RFC (as opposed to requirements on submitted documents).
Authors are requested to come as close to these rules as reasonable,
but in any case the RFC Editor will ensure they are met before
publication. For example, the RFC Editor will supply headers and
footers, adjust pagination to avoid "widows", and adjust a Table of
Contents accordingly.
However, author attention to these rules will streamline the
publication process and reduce the average publication time. If
reaching the final format requires excessive effort by the RFC
Editor, the author will be asked to assist in the reformatting.
Authors are admonished to proof-read the final publication form
carefully, to ensure that no errors accidentally crept in.
These 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.
RFC Editor Informational [Page 15]
Internet-Draft Instructions to RFC Authors 5 June 2003
Note that these rules govern an RFC as published. During the
publication process the RFC Editor will verify compliance and will
repair minor infractions.
3.1 General Formatting Rules
(1) Character code
The character code is US-ASCII [ASCII69] (also known as ISO
646.IRV). 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: A plain-text RFC is expected to be stored on a
disk file 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
protocol (e.g., FTP, Telnet, HTTP, SMTP, ...) must make
the appropriate EOL transformation at each line end.
Note that binary transmission of plain-text 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.
RFC Editor Informational [Page 16]
Internet-Draft Instructions to RFC Authors 5 June 2003
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
recommended page formatting parameters (see Appendix B)
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.
(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
RFC Editor Informational [Page 17]
Internet-Draft Instructions to RFC Authors 5 June 2003
Do not use hyphenation at the right margin to split existing
words. However, hyphenated word sequences (e.g., "Internet-
Draft") may be split at the hyphen across successive lines.
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.
(11) Headers and Footers
RFCs must have running headers and footers, as defined below
in Section 3.3. 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
RFC Editor Informational [Page 18]
Internet-Draft Instructions to RFC Authors 5 June 2003
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 (216 by 279 mm).
(2p) Leave a margin of 1 inch (25 mm) 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.
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.
RFC Editor Informational [Page 19]
Internet-Draft Instructions to RFC Authors 5 June 2003
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 [IEN137].
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.
Any alternative style must meet the same level of clarity,
readability, and lack of ambiguity. An author wishing to use an
alternative style should discuss it with the RFC Editor.
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
RFC Editor Informational [Page 20]
Internet-Draft Instructions to RFC Authors 5 June 2003
4. Required Sections in an RFC
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. Appendices
7f. References
8. Authors' Addresses [Required]
9. Full Copyright Statement [Required*]
Those sections marked with * will be supplied by the RFC Editor
during the editorial process.
The rules for each of these sections are described below in
corresponding subsections.
The Body of the Memo will normally contain section numbers (or
Appendix labels). Sections listed as 1-6 and 8-9 are to be
unnumbered.
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.
RFC Editor Informational [Page 21]
Internet-Draft Instructions to RFC Authors 5 June 2003
"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 2.11.
"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 2.11.
"Category: xxxxxxxxx"
Required left-justified field specifying the category of this
RFC. Here xxxxxxxx may be one of: Standards Track, Best
Current Practice, Informational, or Experimental.
The following information appears right-justified in the header:
Author
The author's name (initial of first given name followed by
family name), 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
RFC Editor Informational [Page 22]
Internet-Draft Instructions to RFC Authors 5 June 2003
factoring is not necessary if it results in an unacceptable
reordering of author lines.
The total number of authors is generally limited; see Section
2.12.
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 A.
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.
4.4 IESG Note
This optional section will appear when the IESG requires a warning
or clarifying message 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. An Abstract of
more than 20 lines is generally 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 knowledgeable reader a general overview of the
function of the document. In addition to its function in the RFC
RFC Editor Informational [Page 23]
Internet-Draft Instructions to RFC Authors 5 June 2003
itself, the Abstract section text will appear in publication
announcements and in the online index of RFCs.
Composing a useful Abstract generally requires thought and care.
Usually an Abstract should begin with a phrase like "This memo
..." or "This document ...". 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 it may result in an Abstract that is both 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.
Abbreviations appearing in the Abstract should generally be
expanded in parentheses. There is a small set of reasonable
exceptions to this rule; see the discussion under Titles, Section
2.9.
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.)
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
RFC Editor Informational [Page 24]
Internet-Draft Instructions to RFC Authors 5 June 2003
4.7 Body of the 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.
All abbreviations that are used in the body must be expanded the
first time they occur. A few exceptions will be made for very
well-known abbreviations; see the discussion under Titles in
Section 2.9.
Abbreviation overload is an increasingly common problem in RFCs.
We recommend that complex RFCs include a brief glossary at the
end. On the other hand, a glossary is never a substitute for an
explanation.
4.7a Contributors Section
This optional section lists those contributors who deserve
significant credit for the document. When a long author list
is replaced by a single Editor in the front page header, the
displaced authors can be properly and fully acknowledged in the
Contributors section.
The Contributors section may include brief statements about the
nature of particular contributions ("Sam contributed section
3") and it may also include affiliations of listed
contributors. At the discretion of the author(s), contact
addresses (see Authors' Address section below) may also be
included in the Contributors section, for those contributors
whose knowledge makes them useful future contacts for
information about the RFC.
4.7b Acknowledgment Section
This optional section may be used instead of, or in addition
to, a Contributors section, when appropriate.
RFC Editor Informational [Page 25]
Internet-Draft Instructions to RFC Authors 5 June 2003
4.7c Security Considerations Section
All RFCs must contain a section that discusses the security
considerations relevant to the specification in the RFC; see
[Secur03] for more information.
4.7d IANA Considerations Section
See Section 2.10 above and [IANA98].
4.7e Appendixes
Many RFC documents have appendices, some of which may be very
extensive. Common practice is to position Appendixes at the
very end of a document, after the references. However, a
significant set of RFCs have large and dense Appendix sections
for technical details, which are actually an integral part of
the document. In this case, it can be difficult to locate the
references. We therefore recommend that, in general,
references follow the Appendixes in an RFC.
4.7f References Section
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. (Note: the ordering of multiple authors is
intended to be as shown.) On the other hand, there is no
required format for a citation; see the discussion in Section
4.7.
A reference to an RFC that has been assigned an STD, BCP, or
FYI subseries number must include the subseries number of the
document.
Reference lists must indicate whether each reference is
normative or informative. For example, the reference section
might be split into two sections, e.g.:
s. Normative References
xxx
...
xxx
RFC Editor Informational [Page 26]
Internet-Draft Instructions to RFC Authors 5 June 2003
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, the phrase "Work in Progress", and the date; for
example:
[doe13] Doe, J., "The Deployment of IPv6",
Work in Progress, May 2013.
Normative references to Internet Drafts will cause publication
of the RFC to be suspended until the referenced draft is also
ready for publication; the RFC Editor will then replace the
reference by an RFC reference and publish both simultaneously.
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.8 Authors' Address Section
This required section gives the name(s) and contact information
for the author(s) listed in the first-page header. Contact
information must include at least one, and ideally would include
all, of a postal address, a telephone number and/or FAX number,
and a long-lived email address. The purpose of this section is to
(1) unambiguously define author/contributor identity (e.g., the
John Smith who works for FooBar Systems) and to (2) provide
contact information for future readers who have questions or
comments. Note that some professional societies offer long-lived
email addresses for their members.
4.9 Full Copyright Statement
Per Section 10.4(C) of BCP 9, RFC 2026, "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.
RFC Editor Informational [Page 27]
Internet-Draft Instructions to RFC Authors 5 June 2003
5. RFC Information and Contacts
************************************************************
* *
* RFC Editor Email: rfc-editor@rfc-editor.org *
* *
* *
* RFC Editor URL: http://www.rfc-editor.org *
* *
* *
************************************************************
In particular, authors should look for the latest version of this
document at the URL listed above.
RFC publication announcements are distributed via two mailing lists:
the "IETF-Announce" list and the "RFC-DIST" list. The IETF-Announce
list announces publication of both Internet Drafts and RFCs;
instructions for subscription and unsubscription to this list are
available on the IETF web site www.ietf.org. The RFC-DIST list
announces only RFC publication; subscription information is available
at the RFC Editor URL listed above.
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 listed above is recommended.
Security Considerations
This RFC describes the Security Considerations sections of an RFC.
It raises no new security issues itself.
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.
We are grateful for the many thoughtful and helpful suggestions made
by IETF participants during the Last Call on a previous version of
this document. We especially acknowledge the thorough analysis by
John Klensin.
RFC Editor Informational [Page 28]
Internet-Draft Instructions to RFC Authors 5 June 2003
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 29]
Internet-Draft Instructions to RFC Authors 5 June 2003
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. For
more complete and uptodate information, see the RFC Editor Web page.
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 [XMLrf99] and a tool to
format RFCs from XML source. There is also an XML-to-nroff
translator suitable for creating RFC text. Authors have had a
generally good experience with these tools.
Microsoft Word
Microsoft Word is an important example of a WYSIWYG editor. RFC
3285 [14] 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.rtf) 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.
Note that these template files are suitable only for fairly
simple text formatting; they may be incompatible with the more
advanced features of Word.
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 there are tools that translate LaTex
to nroff; see the RFC Editor web page.
RFC Editor Informational [Page 30]
Internet-Draft Instructions to RFC Authors 5 June 2003
APPENDIX C: Checklist
Topic | Section of
| this doc.
___________________________________________________________|___________
A. Editorial/Content Issues |
|
1. Reasonably clear and correct English | 2.3
> Also, run spell checker |
|
2. All abbreviations (with a few exceptions) are | 4.7
expanded when they first appear. |
|
3. References: | 2.7, 4.7f
> Complete and current |
> Normative and Informative listed separately | 2.7
> Internet Drafts correctly referenced | 4.7f
|
4. All URLs are suspect: they must be stable. | 2.8
|
5. Title: | 2.9
> Descriptive and not misleading. |
> No suspect words, e.g., Proposed, Standard, |
Requirements, Policy. |
> Abbreviations expanded |
|
6. Author list not too long | 2.12
|
7. Category field correct | 4.1
|
B. Basic Formatting | 3.1
|
1. Only printable ASCII characters | 3.1(1),
| 3.1(4)
2. No lines exceeding 72 characters | 3.1(2)
[This is especially important for "as is" tables |
and figures, which cannot be easily reformatted by|
the RFC Editor.] |
|
3. Maximum page size is 58 lines. [RFC Editor may | 3.1(3)
re-paginate, but this limit may be an issue for |
large "as is" tables and figures. |
|
4. Must be ragged-right | 3.1(5)
|
5. No hyphenation at end of line | 3.1(6)
|
6. Two blanks after periods ending sentences | 3.1(7)
RFC Editor Informational [Page 31]
Internet-Draft Instructions to RFC Authors 5 June 2003
|
7. No footnotes (end notes OK) | 3.1(8)
|
8. Line spacing OK | 3.1(9)
|
9. Pages numbered | 3.1(10)
|
10. Running headers and footers OK | 3.3
|
11. Formatted for easy reading; consistent spacing and |
indentation | 3.1(12)
|
12. "Big-Endian" data definitions | 3.4
|
C. Required Sections | 4
|
1. Status of Memo | 4.2
> Choose text appropriate to Category | App. A
|
2. Copyright Notice | 4.3
|
3. Abstract | 4.5
> Clarity and content OK |
> Reasonable length |
> All abbreviations expanded |
> No references |
> Unnumbered section |
|
4. Security Considerations | 4.7c
|
5. Authors' Addresses | 4.8
|
B. Optional Sections | 4
|
1. IESG Note, if requested. | 4.4
|
2. Table of Contents | 4.6
> Must be present in large document |
|
3. IANA Considerations, if needed | 4.7d
4. Contributors and/or Acknowledgments | 4.7a, b
RFC Editor Informational [Page 32]
Internet-Draft Instructions to RFC Authors 5 June 2003
APPENDIX D: Changes
Changes from -04 version (with section references)
1. Replace overloaded "Status" attribute name with "Category"
[1.1].
2. Clarify the relation of this document to RFC 2026 [1.2].
3. Clarify the submission rules, including rules for IAB and
IRTF documents and for BCPs [1.2]
4. Specify that RFC Editor reviews individual submissions for
content as well as format [1.2.1].
5. Document "Do Not Publish Now" recommendation from the IESG
[1.2.1].
6. Distinguish between the plain text format and the US-ASCII
character set [2.4, 3.1].
7. Clarify the distinction between citation format and reference
format, and use a more appropriate format for citations in
this document [2.7].
8. State that RFC 2119 is not required, but some meaning must be
defined for capitalized applicability words [2.14].
9. Checking of MIBs and other formal languages [2.15]
10. Clarify that Section 3 defines published format, not
submission format [3.].
11. Reorganize the sections in section 4 to clarify and simplify
the section ordering rules, and move appendixes to match our
recommendation [4].
12. Suggest Glossary [4.7].
13. Fix many typos reported by ever-vigilant IETF members.
Changes from -03 version
1. Combine sections 1.3.1 and 1.3.2 into one section 1.3.1.
RFC Editor Informational [Page 33]
Internet-Draft Instructions to RFC Authors 5 June 2003
2 Clarify the section ordering rules in section 4.
Changes from -02 version
1. Removed old Appendix C (definition of ASCII) and replace it
with a reference to RFC 20 [USASC69].
2 Added new Appendix C, a Checklist.
3 Made a few editorial changes and typo fixes.
4 Clarified that .txt.pdf versions are equally authoritative
with .txt versions of RFCs.
5 Stated policy that (nearly) all abbreviations in body of the
document must be expanded when first encountered.
Changes from -01 version
1. Incorporated new author list guidelines.
2. Clarified rules for hyphenation (Section 3.1 (6)).
3. Added guideline on example URLs (Section 2.8).
4. Clarified that dangling normative references are strictly
prohibited only for standards-track documents (Section 2.7).
In general, this document contains the following major changes
from RFC 2223.
o Section 1: Introduction
This section was completely rewritten, using material from several
sections of RFC 2223, bringing the discussion into conformance
with RFC 2026 and adding additional clarification.
o Section 2: General RFC Editorial 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.
RFC Editor Informational [Page 34]
Internet-Draft Instructions to RFC Authors 5 June 2003
Major procedural changes include: (1) publication of an RFC in
both ASCII and PostScript versions now requires that both be
published simultaneously, (2) all listed authors must give
approval during the "Authors' 48 Hour" process, (3) long author
lists are generally prohibited, and (4) a Contributors section is
defined as an alternative to long author lists.
o 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) The requirement for page numbers in specified.
(3) The requirement for running headers and footers is
specified.
o 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, and it defines section
ordering more precisely.
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 RFC abstracts
useful for searching and indexing.
(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.
(4) A new optional section, Contributors, is defined.
o 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.
RFC Editor Informational [Page 35]
Internet-Draft Instructions to RFC Authors 5 June 2003
Appendix B, RFC Preparation Tools, and Appendix C, Checklist, are
new.
Normative References
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP95] Postel, J., Li, T. and Y. Rekhter, "Best Current
Practices", BCP 1, RFC 1818, August 1995.
[FYI90] 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.
[IANA98] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[IDnits] IETF, "Guidelines to Authors of Internet Drafts".
Available as 1id-guidelines.txt at http://www.ietf.org.
[IPR03] Bradner, S., "IETF Rights in Submissions", Work in
Progress, April 2003. [[This will hold up publication of
RFC2223bis]]
[Lang01] IESG, "Guidance for the use of formal languages in IETF
specifications", http://www.ietf.org/IESG/STATEMENTS,
October 2001.
[RFCed] RFC Editor web page, "http://www.rfc-editor.org".
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[Secur03] Rescorla, E., Korver, B., and Internet Architecture Board,
"Guidelines for Writing RFC Text on Security
Considerations", Work in Progress, January 2003.
[STD1] Internet Engineering Task Force, Reynolds, J., Braden, R.,
Ginoza, S., and A. De La Cruz, Ed., "Official Internet
Protocol Standards", STD 1. Latest version RFC 3300,
November 2002.
[STD92] Postel, J., Editor, "Introduction to the STD Notes", RFC
1311, March 1992.
RFC Editor Informational [Page 36]
Internet-Draft Instructions to RFC Authors 5 June 2003
Informative References
[Hist99] RFC Editor et al., "30 Years of RFCs", RFC 2555, April
1999.
[IEN137] Cohen, D., "On Holy Wars and a Plea for Peace", Internet
Experimental Note (IEN) 137, 1 April 1980. A longer
version is published in IEEE Computer Magazine, pp 48-54,
October 1981.
[TLD99] Eastlake, D. and E. Panitz, "Reserved Top Level DNS Names",
RFC 2606, June 1999.
[ASCII69] Cerf, V., "ASCII Format for Network Interchange", RFC 20,
October 1969.
[Word02] Gahrns, M. and T. Hain, "Using Microsoft Word to create
Internet Drafts and RFCs", RFC 3285, May 2002.
[XMLrf99] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999.
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 37]
Internet-Draft Instructions to RFC Authors 5 June 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 38]
