RFC Style

RFC Document Style
(draft 09)
R. Braden, S. Ginoza, A. Hagens
22 September 2009
Abstract
This document is a comprehensive summary of the style conventions and
editorial policies that characterize the RFC document series, for the
guidance of RFC authors.
Table of Contents
1. Introduction ....................................................2
2. RFC Editorial Goals .............................................3
3. RFC Format Rules and Guidelines .................................3
3.1. General ....................................................4
3.2. Grammar Rules ..............................................5
3.3. Punctuation Rules ..........................................6
3.4. Capitalization Rules .......................................7
3.5. Reference and Citation Rules ...............................7
3.6. Other Rules ................................................7
4. Structure of an RFC Document ....................................9
4.1. First-Page Header ..........................................9
4.1.1. Updates and Obsoletes ...............................9
4.1.2. Author Organizations/Affiliations ..................10
4.2. Full Title ................................................10
4.3. Abstract ..................................................11
4.4. Status of This Memo .......................................11
4.5. IESG Note .................................................12
4.6. Copyright and License Notice ..............................12
4.7. Table of Contents .........................................12
4.8. Body of the Memo ..........................................12
4.9. "Author's Address" Section ................................16
4.10. Running Headers and Footers ..............................17
5. Suggestions to Authors .........................................17
5.1. Author Directives .........................................17
5.2. Protocol Data Definitions .................................18
Appendix A: Additional Data about the Contents of RFC Elements ....19
Appendix B: Postscript Format Rules ...............................22
Appendix C: End-of-Line and End-of-Page ...........................23
Informative References ............................................24
RFC Editor [Page 1]
RFC Editor RFC Style Guide v08 22 September 2009
1. Introduction
This document is a comprehensive summary of the current style
conventions and editorial policies for the RFC document series
[RFCs07]. It is intended as a reference for RFC authors.
The basic format conventions for RFCs were established in the 1970s
by the original RFC Editor, Jon Postel [Postel, Hist99]. Postel's
instructions to authors were quite simple: read a recent RFC and
emulate its style. More recently, it has been found necessary to
formalize and document the RFC style rules and give guidelines to
authors [RFC2223, RFC2223bis].
While editing and publishing RFCs, we have created a set of informal
style guidelines, with input from authors. These notes were
incorporated into this document.
The world of technical publishing has generally-accepted rules for
grammar, punctuation, capitalization, sentence length and complexity,
parallelism, etc. The RFC Editor at ISI generally follows these
accepted rules, with a few important exceptions to avoid ambiguity in
complex technical prose and to handle mixtures of text and computer
languages.. This document presents these exceptions.
Some style rules in this document are considered fundamental to the
RFC series; the RFC Editor will try to ensure these are met before
publication. For example, an RFC must have correctly formatted
headers and footers, it must have the necessary boilerplate, and it
must generally have the "appearance" of previous RFCs in the series.
Other style issues are more flexible; they represent "SHOULDs" rather
than "MUSTs", in the requirements language of the IETF. This
document specifies the preferred forms in such cases, but variations
are allowed as long as the result is clear and consistent.
The ultimate goal of the RFC publication process is to produce
documents that are readable, clear, consistent, and reasonably
uniform. The publication process will be much faster and more
effective in creating readable documents if authors follow the rules
and accept the guidelines contained in this document.
A good RFC starts with a well-written and properly structured
Internet Draft [IDguide]. We have therefore attempted to align
these RFC guidelines with the IETF's ID-nits too, to streamline
the process of editing a Draft into an RFC.
RFC Editor [Page 2]
2. RFC Editorial Goals
It may be helpful to an author to understand the goals of any editing
that will be performed on an RFC before publication. The RFC Editor
goals are to:
- Prepare document to RFC style and format.
- Make the document as correct, clear, and readable as possible.
- Look for larger content/clarity issues; flag any unclear passages
for author review.
- Point out inconsistencies (e.g., terms that appear in various
forms, text that appears multiple times, similar passages of text
that appear more than once, or inconsistent capitalization).
We strive for consistency within:
a. the document,
b. a set of documents, and
c. the series of RFCs on the subject matter.
3. RFC Format Rules and Guidelines
For more information on creating a document with the format and style
described below, please refer to the following in addition to this
document:
The Publication Process
http://www.rfc-editor.org/pubprocess.html
Formatting RFCs and Internet Drafts (author preparation tools)
http://www.rfc-editor.org/formatting.html
RFC Editor Abbreviations List
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
RFC Editor Terms List
http://www.rfc-editor.org/rfc-style-guide/terms-online-03.txt
RFC Editorial Guidelines and Procedures
http://www.rfc-editor.org/policy.html
RFC Editor [Page 3]
3.1. General
* The RFC publication language is English.
* RFCs are normally published as plain text files in the [US-]ASCII
[RFC20] character set (also known as ISO 646.IRV).
Only the printable ASCII characters and the three control
characters CR, LF, and FF are allowed. They must be used
only for end-of-line and end-of-page, as described in
Appendix C. Tab (HT) characters and Backspace (BS)
characters are never allowed (hence, there can be no
underlining).
In certain cases, a supplementary or equivalent Postscript/PDF
file may be published. See [RFCs07] for more information.
Formatting rules for such a Postscript file are given in Appendix
B.
* Each line of text is limited to 72 characters, followed by the
character sequence that denotes an end-of-line (EOL). See
Appendix C for more information.
The RFC Editor will adjust running text when necessary to fit
within the 72 character limit. However, pay particular attention
to this limit when creating tables, figures, and diagrams, as
these may not be easily truncated.
* Each page is limited to 58 lines followed by a Form Feed (FF)
character, followed by an EOL sequence. This 58 line limit
includes the headers and footers. See Appendix C for more
detailed information.
* All pages, except perhaps the first and last, must have the same
number of lines when headers and footers are included. That is,
footers should not "bounce" from page to page.
* Text should be single-spaced. There must be one blank line between
paragraphs.
* In general, readability will be much enhanced by treating each
bulleted item as a paragraph. That is, one blank line should be
placed between bulleted items.
* Pages must be numbered consecutively, starting from 1 on the first
page.
RFC Editor [Page 4]
* An RFC must not contain:
- overstriking or underlining
- "filling"
RFCs are formatted "ragged right", i.e., left-justified without
padding to a straight right margin.
- (added) hyphenation at right margin.
Do not use hyphenation at the right margin to split existing
words that do not "naturally" contain hyphens (e.g., "Inter-
net"). However, hyphenated words (e.g., "Internet-
Draft") may be split at the hyphen across successive lines.
NOTE: There are good reasons for the use of "ragged right"
without hyphenation. 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.
- Footnotes
Parenthetical notes may be placed at the end of a section or at
the end of the document, or inserted inline and indented.
These types of notes are often indented and marked as follows:
NOTE: Insert note here.
* 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 readability when an RFC is displayed
or printed with a fixed-width font.
3.2. Grammar Rules
* Sentences must be grammatically correct, e.g., they must include
subjects and verbs.
* A long, overly complex, or obscure sentence should be recast into
two or more simpler, clearer sentences.
* Parallel clauses should be parallel in syntax.
RFC Editor [Page 5]
* Bulleted lists:
o A bulleted list should be parallel, for example:
a) making ...,
b) creating ..., and
c) managing ...
o Items in bulletized lists may be sentence fragments.
* "which" and "that" should follow the rules:
o "which" is non-restrictive and is used parenthetically. It
follows a comma and provides non-essential information.
Example:
"The XYZ Protocol, which is proprietary, may be vulnerable
to session hijacking"
o "that" is restrictive and introduces information that is
essential to the meaning of the sentence. Example:
"A protocol that is less robust may be more vulnerable to
session hijacking"
* The first person ("I" or "we") is allowed but generally
discouraged.
* If "the user" is the antecedent, the pronouns "it", "he", "she",
or "they" are allowed.
* Passive voice (e.g., "The dog was kicked by you") may be used but
is frowned upon. Text should be written in active voice (e.g.,
"You kicked the dog").
3.3. Punctuation Rules
* The RFC style places a comma before the last item of a series,
e.g.,
"TCP service is reliable, ordered, and full-duplex"
^
^
This is to avoid ambiguity; see the title of [Panda04].
RFC Editor [Page 6]
* The RFC style places punctuation outside quotation marks, e.g.,
'Search for the string "Error Found"'.
* Angle brackets are allowed around URLs.
* The RFC style generally follows the author's choice on hyphenation
of compound words (e.g., "on-line" vs. "online"), as long as it is
consistent and does not appear in the dictionary [WEBSTERS]
unhyphenated. However, in some cases preferred forms have been
chosen in consultation with authors; see the online "Table of
decisions on consistent usage of terms in RFCs" [PubProcess].
3.4. Capitalization Rules
* The author may choose how to capitalize terms, but capitalization
must be consistent within the document and should be consistent
with related RFCs. Refer to the online "Table of decisions on
consistent usage of terms in RFCs" [PubProcess].
* The major words in RFC titles and section titles should be
capitalized (this is sometimes called "title case"). Minor words
such as articles or prepositions should be lower-cased (e.g.,
"and", "of"). Typically, all words in a title will be
capitalized, except for internal articles, prepositions, and
conjunctions.
* Titles of figures may be in sentence form or use title case.
3.5. Reference and Citation Rules
* References and citations must match. That is, there must be a
reference for each citation used, and vice versa.
* Citations must be enclosed square brackets ("[CITE1]").
* A citation/reference tag must not contain spaces.
Example: "[RFC2119]", not "[RFC 2119]".
However, the proper textual naming of an RFC contains a space.
Example: "See RFC 2119 [BCP14] for more information".
3.6. Other Rules
* Careful indentation of text can be very important for clarity and
readability of an RFC.
RFC Editor [Page 7]
Successive indentation of sub-subsections may be used. Experience
has shown that indentation by multiples of 3 columns works well.
(For an example of this style, see RFC 1122).
* Abbreviations must be expanded upon first use, except those that
are "well-known". Refer to the online "Table of Definitions of
abbreviations (acronyms) in RFCs" [PubProcess].
NOTE: there is room for some judgment in expanding acronyms
in titles, to avoid absurdly long and awkward titles.
* The RFC Editor uses the accepted forms of some common terms, but
defers to the author's use for other terms. The preferred choice
has sometimes resulted from negotiation among authors and ADs.
Refer to the online "Table of decisions on consistent usage of
terms in RFCs" [PubProcess].
* Cross references within the body of the text should use section
numbers rather than page numbers, as the RFC Editor generally
adjusts pagination during final editing. The only exception is
the Table of Contents, which necessarily shows page numbers.
* When emphasis is (absolutely) required, a term may be surrounded
by underscores or asterisks. Examples:
"_This_ is really, *really* important!"
(But don't mix them, as in the example above.)
* Some styles restrict the use of "i.e." and "e.g.", but the RFC
style has only one general restriction on their use: a sentence
must not start with "I.e." or "E.g.".
* The word "draft" should not appear in the text as a reference to
the document itself, since it is becoming an RFC.
It should also not appear in reference to other IDs, as IDs change
and expire, while RFCs are permanent publications.
* If URLs are used, they should be reasonably stable; see Section
4.8(x). All URLs in an RFC must be valid at the time of
publication, at least.
RFC Editor [Page 8]
4. Structure of an RFC Document
A published RFC will contain the elements in the following list.
Some of these sections are required, as noted. Those sections marked
with "*" will be supplied by the RFC Editor during the editorial
process when necessary.
The rules for each of these elements are described below. The
elements 3, 4, and 9 will be provided by the RFC Editor during the
editorial process.
1. First-page header * [Required]
2. Title * [Required]
3. Abstract [Required]
4. Status of this Memo [Required]
5. IESG Note * [As requested by IESG]
6. Copyright and License Notice * [Required]
7. Table of Contents [Required for docs with 30+ pgs]
8. Body of the Memo [Required]
8a. Introduction [Required]
or equivalent
8b. Requirement Words (RFC 2119)
8c. ...
MAIN BODY OF THE TEXT
8t. ...
8u. Security Considerations [Required]
8v. IANA Considerations
8w. Appendixes
8x. References
8y. Contributors
8z. Acknowledgments
9. Author's Address [Required]
The order shown is required, except that the order shown within the
body of the memo is generally recommended but not required.
The body of the memo will normally have numbered sections; appendixes
may be numbered or labeled. However, if the author chooses to label
appendixes, subsequent sections should not be numbered. The elements
preceding and following the body of the memo should be unnumbered.
4.1. First-Page Header
4.1.1. Updates and Obsoletes
When authors produce a document that obsoletes or updates a
previously published RFC(s), this information should be indicated
clearly, preferably in the header. For example:
RFC Editor [Page 9]
"Updates: nnnn" or "Updates: nnnn, ..., nnnn"
"Obsoletes: nnnn" or "Obsoletes: nnnn, ... , nnnn"
Clearly stating this information helps call attention to the RFC
Editor that other actions are necessary (e.g., insert additional
fields in the RFC header and update the corresponding database
entries).
Authors often also include a statement in the Abstract and/or
Introduction sections that read similarly to the following:
This document obsoletes RFC XXXX.
This helps clarify the status of the document and its relation to the
updated/obsoleted RFC to the reader.
See Section A.1 for more detailed information on the first-page
header of an RFC.
4.1.2. Author Organizations/Affiliations
If authors provide their affiliations in the header of the Internet
Draft, the RFC will follow suit, and vice versa.
4.2. Full Title
The RFC title must be centered, preceded by, and followed by at least
one blank line.
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) [ABBR] in a title (as well as the
Abstract and the body) 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 [Page 10]
The RFC title 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,
for various reasons.
An RFC that documents a particular company's private protocol should
bear a title of the form "XXX's ... Protocol" (where XXX is a company
name), to clearly differentiate it from an IETF product.
4.3. Abstract
Every RFC must have an Abstract section, a maximum of 20 lines.
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.
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 an effective abstract may be shorter, less detailed, and perhaps
broader in scope than the Introduction. Simply copying and pasting
the first few paragraphs of the Introduction is allowed, 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.
Similarly, the Abstract should be complete in itself. It will appear
in isolation in publication announcements and in the online index of
RFCs. Therefore, the Abstract must not contain citations.
Abbreviations appearing in the Abstract should generally be expanded
in parentheses, with the exceptions noted above. When in doubt,
expand an abbreviation (refer to the online "Table of decisions on
consistent usage of terms in RFCs" [PubProcess]).
4.4. Status of This Memo
This text will be provided by the RFC Editor. See Section A.2 for
more information.
4.5. IESG Note
This text will be provided to the RFC Editor by the IESG and will be
inserted into the RFC text. See Section A.4 for more information.
4.6. Copyright and License Notice
This text will be provided by the RFC Editor. See Section A.3 for
more information.
4.7. 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. It must be
positioned after the Abstract and before the Introduction section.
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 granularity probably needs to be coarser.
The RFC Editor uses a program to generate and format the TOC at the
final stage of editing an RFC.
4.8. 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 before
the body can improve readability.
Each RFC should start with 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. The body of the memo and the
Abstract must be self-contained and separable. This may result in
some duplication of text between the Abstract and the Introduction;
this is acceptable.
a) Introduction
The introduction section should always be the first section
following the Table of Contents (except in the case of MIBs).
While we recommend "Introduction" as the title for this section,
authors sometimes choose alternate titles such as "Overview" or
"Background".
For MIB documents, common practice has been for "The Internet-
Standard Management Framework" [SNMP] text to appear as Section 1.
However, absent "The Internet-Standard Management Framework", the
Introduction section should appear as the first numbered section
of an RFC.
b) Requirement Words (RFC 2119)
Some standards-track documents use certain capitalized words
("MUST", "SHOULD", etc.) to specify precise requirement-levels for
technical features. 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.
This section must appear as part of the body of the text (as
defined by this document). It must appear as part of, or
subsequent to the Introduction section.
Avoid abuse of requirement-level words. They are intended to
provide guidance to implementers 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 retransmissions). 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, choose and use them
carefully and consistently.
c) - t) ... MAIN BODY OF THE TEXT ...
u) 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.
v) IANA Considerations Section
See [BCP26] and [RFCs07].
The RFC Editor will update text accordingly after the IANA
assignments have been made. It is helpful for authors to clearly
identify where text should be updated to reflect the newly
assigned values. For example, we recommend the use of TBD, TBA,
and XXX.
The RFC Editor will also verify that the assignments inserted by
authors match those that have actually been registered on the IANA
site.
Please note that authors may receive queries if any of this
information is not clear to the RFC Editor to ensure that
assignments and values are properly inserted.
The RFC Editor will remove an IANA Considerations section that
says there are no IANA considerations (although such a section is
required in the Internet Draft preceding the RFC.)
w) Appendixes
Many RFC documents have appendixes, which may be very extensive.
In non-RFC documents, authors often position Appendixes at the
very end, after the references. However, RFCs that have large and
dense technical Appendix sections make it difficult for a reader
to find references that precede the appendixes. In such cases,
putting the references later may be advisable.
x) References
The RFC style uses one of the many variants on reference styles.
See the examples in this document, and note the ordering for
multiple authors: the last author listed is treated differently.
For author convenience, there is a table of "Preformatted
bibliographic entries for RFCs" online at [PubProcess].
References to RFCs can be simply copied and pasted from this
table. It also shows when an RFC has been obsoleted by a later
RFC. Normally, an author will want to reference the latest
version.
Additionally, authors can make use of the citation library
available from http://xml.resource.org/. There is a library for
RFCs and Internet Drafts, as well as documentation from other
standards organizations.
The RFC Editor ensures that references to other RFCs refer to the
most current RFC available on that topic (unless provided with
reason not to do so). It is okay for an obsoleted document to be
listed as long as the most recent document is referenced also.
A reference to an RFC that has been assigned an STD [RFC1311], BCP
[RFC1818], or FYI [FYI90] sub-series 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. References
s.1. Normative References
xxx
...
xxx
s.2. 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 generally discouraged,
because URLs are often not stable. On the other hand, there are
cases where a URL is demonstrably the most stable reference
available for some reference.
The RFC Editor strongly recommends against the use of simple
numeric citations ("[53]"). Using numeric citations often creates
a burden on the Authors and/or RFC Editor (except when an XML
source file is provided) when citations/references need to be
added or deleted, or when they need to be moved from informative
to normative (and vice versa).
We recommend using citations that are symbolic of the subject
matter (e.g., [IKEv2]), a unique name affiliated with the document
(e.g., [RFC2119], [IEEE.802]), or possibly the academic convention
of some brief encoding of the title and year (e.g., [MPLS99a]).
URLs and DNS names 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 generally acceptable.
DNS names, whether or not in URLs, that are used as generic
examples in RFCs should use the particular examples defined in RFC
2606 [RFC2606], "Reserved Top-Level DNS Names", to avoid
accidental conflicts.
y) 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 Author's
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.
z) Acknowledgments Section
This optional section may be used instead of, or in addition to, a
4.9. "Author's Address" Section
This required section gives contact information for the author(s)
listed in the first-page header, and perhaps those listed in a
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.10. Running Headers and Footers
RFCs always include running headers and footers (except that the
first page has no running header).
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 as "[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."
The headers and footers must be separated from the body by at
least one and preferably two blank lines.
5. Suggestions to Authors
5.1. Author Directives
It is OK to provide the RFC Editor with explicit directives in your
document. If particular terms/phrases must appear a certain way
(e.g., spelling, hyphenation, capitalization), please let us know, so
we can ensure correct use of such terms and phrases throughout the
document.
5.2. Protocol Data Definitions
The RFC series adopted a pictorial approach to representing data
structures such as protocol headers. Furthermore, the research
community adopted the "big-endian" [IEN137] 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. This is also known as "network byte order".
For example, RFC 791 contains the following definition of the IP
header format.
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
Appendix A. Additional Data about the Contents of RFC Elements
A.1. First-Page Header
The first page contains no running header. The top of the first page
has the following items left justified:
"Network Working Group"
This traditional title is left-justified on the first line of the
heading. It originally denoted the ARPAnet research group that
founded the RFC series [RFCs07]. There are proposals to change
it, but none have been adopted.
"Request for Comments: nnnn"
Identifies this as an RFC and specifies the RFC number, left-
justified on the second line. The actual number is assigned and
filled in just prior to publication by the RFC Editor.
The RFC Editor sometimes exercises some judgment in assigning RFC
numbers. In particular, updates to fundamental protocol
specifications are given numbers congruent modulo 100 to the
original RFC number, when this is possible. For example, RFC 821
was obsoleted by RFC 2821.
"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 [RFCs07].
"Category: xxxxxxxxx"
Required left-justified field specifying the category of this RFC.
The category may be one of: "Standards Track", "Best Current
Practice", "Informational", "Experimental", or "Historical". The
category is determined by the party submitting the RFC (e.g., the
IESG for IETF documents) and rules in [RFC2026] and [IABrfc07].
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.
The total number of authors on the first page is generally
limited; see "Author Overload" and "Author Responsibility"
[POLICY, RFCs07]
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", appearing only once following the corresponding
Author lines. However, such factoring will be inappropriate when
it would force an unacceptable reordering of author names.
Date
The month and year of RFC Publication, right-justified on the line
after the last organization.
The title must be centered below the rest of the heading, preceded
and followed by at least one blank line.
The title should be carefully chosen to fairly represent the scope
and purpose of the document without being either too general or too
lengthy. See: Section 4.3 "Choosing an RFC Title".
A.2. "Status of this Memo"
A.2.1. RFC Publications
The RFC Editor will supply an appropriate "Status of this Memo"
section that contains two elements: (1) a paragraph describing the
category of the RFC, and (2) the distribution statement. The actual
text supplied will be one of the following:
Status of Memo Text
The RFC Editor supplies the appropriate one of the following
boilerplate paragraphs in the Status of the Memo section.
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."
Historic
"This memo defines a Historic Document for the Internet
community. It does not specify an Internet standard of any
kind. Distribution of this memo is unlimited."
A.2.2. Republications
An RFC that is (re-)publishing a specification produced by another
(non-IETF) standards organization or is publishing a proprietary
protocol may include the following paragraph in the Status of the
Memo section [IPC04]:
"This document may not be modified, and derivative works of it
may not be created, except to publish it as an RFC and to
translate it into languages other than English [other than to
extract section XX as-is for separate use]."
The IETF does not have change control over such documents, which are
published as Informational RFCs. Here the optional clause delimited
by [ ] is for programmatic material that is meant to be extracted,
e.g., MIB or PIB modules.
A.3. IPR Boilerplate
The IPR boilerplate is dictated by BCP 78 (RFC 5378) [IPC04] and BCP
79 (RFCs 3979 and 4879) [IPT04]. However, the full copyright and
license notices are available at http://trustee.ietf.org/license-
info/. It includes a full notice of copyright by the Trust, and an
IETF disclaimer on intellectual property rights over the contents.
It also contains the BSD license that appiles to code components
within an RFC.
APPENDIX B. PostScript Format Rules
(1p) Document should match .txt file as closely as possible in
structure, format, and content.
(2p) Standard page size is 8 1/2 by 11 inches (216 by 279 mm).
(3p) Leave a margin of 1 inch (25 mm) on all sides (top, bottom,
left, and right).
(4p) Main text should have a point size of no less than 10 points
with a line spacing of 12 points.
(5p) Notes and graph notations no smaller than 8 points with a line
spacing of 9.6 points.
(6p) 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.
(7p) Prepare diagrams and images based on lowest common denominator
PostScript. Consider common PostScript printer functionality
and memory requirements.
(8p) The following PostScript commands should not be used:
initgraphics, erasepage, copypage, grestoreall, initmatrix,
initclip, banddevice, framedevice, nulldevice or renderbands.
APPENDIX C. End-of-Line and End-of-Page
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.
The maximum line count of 58 lines 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 that 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.
The effect of the Height rule is that the following ASCII character
sequence will be used:
<Last non-blank line of page p> <EOL> FF <EOL>
<First line of page p+1> <EOL> ...
When 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.
Informative References
[ABBR] RFC Editor Abbreviations List, <http://www.rfc-
editor.org/rfc-style-guide/abbrev.expansion.txt>.
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
5226, May 2008.
[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.
[Hist99] RFC Editor, et al., "30 Years of RFCs", RFC 2555, April
1999.
[PubProcess] RFC Editor, "Publication Process",
<http://www.rfc-editor.org/pubprocess.html>.
[IABrfc07] Daigle, L., Ed., and Internet Architecture Board, "The
RFC Series and RFC Editor", RFC 4844, July 2007.
[IDguide] IETF, "Guidelines to Authors of Internet Drafts".
Available as 1id-guidelines.txt at
<http://www.ietf.org>.
[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.
[IPC04] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
[IPT04] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
Narten, T., "Clarification of the Third Party
Disclosure Procedure in RFC 3979", BCP 79, RFC 4879,
April 2007.
[Panda04] Truss, L., "Eats, Shoots and Leaves", Gotham Books, New
York, 2004.
[POLICY] RFC Editor, "RFC Editorial Guidelines and Procedures",
<http://www.rfc-editor.org/policy.html>.
[Postel] Jon Postel, original RFC Editor: see
<http://www.isoc.org/postel>.
[RFC20] Cerf, V., "ASCII format for network interchange", RFC
20, October 1969.
[RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311,
March 1992.
[RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best Current
Practices", RFC 1818, August 1995.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC
Authors", RFC 2223, October 1997.
[RFC2223bis] See "Instructions to RFC Authors" on web page [RFCed]
for more recent version.
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999.
[RFCed] RFC Editor web site, <http://www.rfc-editor.org>.
[RFCs07] RFC Editor, "Introduction to the RFC Series". In
preparation. July 2007.
[Secur03] Rescorla, E., Korver, B., and Internet Architecture
Board, "Guidelines for Writing RFC Text on Security
Considerations", Work in Progress, January 2003.
[SNMP] IETF OPS Area, "Boilerplate for IETF MIB Documents",
<http://www.ops.ietf.org/mib-boilerplate.html>.
[WEBSTERS] Merriam-Webster Online, <http://www.m-w.com/>.
Authors' Addresses
Robert Braden
RFC Editor
4676 Admiralty Way
Marina del Rey, CA 90292
EMail: rfc-editor@rfc-editor.org
Sandy Ginoza
RFC Editor
4676 Admiralty Way
Alice Hagens
RFC Editor
4676 Admiralty Way

RFC Style

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

RFC Style

Enviado por

Direitos autorais:

Formatos disponíveis

RFC Document Style

Você também pode gostar