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 []

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 []


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 []


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 []


* 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 []


* 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 []


* 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 []


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 []


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 []


"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 []


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.

RFC Editor []


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".

RFC Editor []


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.

RFC Editor []


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.

RFC Editor []


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

RFC Editor []


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 Contributors section.

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 Contributors section.

RFC Editor []


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.

RFC Editor []


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

RFC Editor []


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].

RFC Editor []


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.

RFC Editor []


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]."

RFC Editor []


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.

RFC Editor []


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.

RFC Editor []


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.

RFC Editor []


[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/>.

RFC Editor []


Authors' Addresses

Robert Braden RFC Editor 4676 Admiralty Way Marina del Rey, CA 90292

EMail: [email protected]

Sandy Ginoza RFC Editor 4676 Admiralty Way Marina del Rey, CA 90292


Alice Hagens RFC Editor 4676 Admiralty Way Marina del Rey, CA 90292


RFC Editor []

rfc-style

Documents

Transcript of rfc-style