Internet-Draft RFC Style Guide (rfc7322bis) May 2023
Ginoza, et al. Expires 2 November 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-rpc-rfc7322bis-00
Obsoletes:
7322 (if approved)
Published:
Intended Status:
Informational
Expires:
Authors:
S. Ginoza
RFC Production Center
J. Mahoney
RFC Production Center
A. Russo
RFC Production Center

RFC Style Guide

Abstract

This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 7322, "RFC Style Guide".

Note: This draft is being developed and discussed in the GitHub repo <https://github.com/rfc-editor/draft-rpc-rfc7322bis>, but any substantive change should be discussed on <rfc-interest@rfc-interest.org>.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on 2 November 2023.

▲

Table of Contents

1. Introduction

The ultimate goal of the RFC publication process is to produce documents that are readable, clear, and consistent. The basic formatting conventions for RFCs were established in the 1970s by the original RFC Editor, Jon Postel. This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series [RFC4844] and is intended as a stable, infrequently updated reference for authors, editors, and reviewers.

The RFC Editor also maintains a web portion of the Style Guide (see Appendix A.3) that describes issues as they are raised and indicates how the RFC Editor intends to address them. As new style issues arise, the RFC Editor will first address them on the web portion of the Style Guide [STYLE-WEB]. These topics may become part of the RFC Style Guide when it is revised.

The world of publishing has generally accepted rules for grammar, punctuation, capitalization, sentence length and complexity, etc. The RFC Editor generally follows these accepted rules as defined by the Chicago Manual of Style (CMOS) [CMOS], with a few important exceptions to avoid ambiguity in complex technical prose and to handle mixtures of text and computer languages, or to preserve historical formatting rules. This document presents these exceptions as applied or recommended by the RFC Editor.

All RFCs begin as Internet-Drafts (also referred to as I-Ds), and a well-written and properly constructed Internet-Draft [ID-GUIDE] provides a strong basis for a good RFC. The RFC Editor accepts Internet-Drafts from specified streams for publication [RFC4844] and applies the rules and guidelines for the RFC Series during the editorial process.

2. RFC Editor's Philosophy

Authors may find it helpful to understand the RFC Editor's goals during the publication process, namely to:

We strive for consistency within:

a. the document,

b. a cluster of documents [CLUSTER], and

c. the series of RFCs on the subject matter.

The editorial process of the RFC Editor is not an additional technical review of the document. Where the RFC Editor may suggest changes in wording for clarity and readability, it is up to the author, working group, or stream-approving body to determine whether the changes have an impact on the technical meaning of the document [RFC4844]. If the original wording is a more accurate representation of the technical content being described in the document, it takes precedence over editorial conventions.

The activity of editing sometimes creates a tension between author and editor. The RFC Editor attempts to minimize this conflict for RFC publication while continually striving to produce a uniformly excellent document series. The RFC Editor refers to this fundamental tension as "editorial balance," and maintaining this balance is a continuing concern for the RFC Editor. There is a prime directive that must rule over grammatical conventions: do not change the intended meaning of the text.

If the RFC Editor cannot edit a document without serious risk of altering the meaning, it may be returned to the stream-approving body for review. See Appendix A.2 for more information.

3. RFC Style Conventions

This Style Guide does not use terminology as defined in [RFC2119] and [RFC8174]. In this document, lowercase use of "must" and "should" indicates changes the RFC Editor will make automatically to conform with this Style Guide versus those that may be questioned if not applied. The lowercase "must" indicates those changes that will be applied automatically and are not at the discretion of the authors. The lowercase "should" indicates the RFC Editor's recommended use, but conformance with the recommendations is not required; the RFC Editor may question whether the guidance may be applied.

3.1. Language

The RFC publication language is English. Spelling may be either American or British, as long as an individual document is internally consistent. Where both American and British English spelling are used within a document or cluster of documents, the text will be modified to be consistent with American English spelling.

3.2. Punctuation

  1. A comma is used before the last item of a series, e.g.,

    "TCP service is reliable, ordered, and full duplex"

  2. When quoting literal text, punctuation is placed outside quotation marks, e.g.,

    Search for the string "Error Found".

    When quoting general text, such as general text from another RFC, punctuation may be included within the quotation marks, e.g.,

    RFC 4844 indicates that "RFCs are available free of charge to anyone via the Internet."

    Quotation marks are not necessary when text is formatted as a block quotation.

3.2.1. RFCs as Compounds

Whenever possible:

  • Hyphenated compounds formed with RFC numbers should be avoided; this can be accomplished by: rewording the sentence (e.g., change "[RFC5011]-style rollover" to "rollover as described in RFC 5011").
  • adding a note in either the Terminology or Conventions section mentioning the RFC so that other occurrences throughout the text will be understood by the reader to be in the style of said RFC (e.g., This document uses the term "rollover" as defined in RFC 5011.).

If use of an RFC number in attributive position is unavoidable, the preferred form should appear as in the example "RFC 5011-style rollover". That is:

  • no hyphen between "RFC" and the number (don't use RFC-5011-style rollover)
  • avoid hyphenating citations with text (don't use [RFC5011]-style rollover)

3.3. DNS Names and URIs

DNS names, whether or not in URIs, that are used as generic examples in RFCs should use the particular examples defined in "Reserved Top Level DNS Names" [BCP32], to avoid accidental conflicts.

Angle brackets are strongly recommended around URIs [STD66], e.g.,

<https://example.com/>

The use of HTTPS rather than HTTP is strongly encouraged.

3.4. Capitalization

  1. Capitalization must be consistent within the document and ideally should be consistent with related RFCs. Refer to the online table of decisions on consistent usage of terms in RFCs [TERMS].
  2. Per CMOS guidelines, the major words in RFC titles and section titles should be capitalized (this is sometimes called "title case"). Typically, all words in a title will be capitalized, except for internal articles, prepositions, and conjunctions.
  3. Section titles that are in sentence form will follow typical sentence capitalization.
  4. Titles of figures may be in sentence form or use title case.
  5. Some terms related to the various roles or parts of the streams authoring RFCs should be used consistently. For example, when the term 'working group' or 'research group' is used as part of a specific group name, it will be capitalized (e.g., kitten Working Group, Crypto Forum Research Group). When used to generally refer to groups, it will be downcased.

3.5. Citations

The most important function of a citation is to point to a reference so that a reader may follow up on additional material that is important in some way to understanding or implementing the content in an RFC. This section offers guidance on the requirements and recommendations for citation format within an RFC.

  1. References and citations must match. That is, there must be a reference for each citation used, and vice versa.
  2. Citations must be enclosed in square brackets (e.g., "[CITE1]").
  3. Citations are restricted to ASCII-only characters, as described in "The Use of Non-ASCII Characters in RFCs" [RFC7997].

  4. Citations must begin with a number or a letter, and may contain digits, letters, colons, hyphens, underscores, or dots.

    • Example: "[IEEE.802.15.4]" rather than "[.802.15.4]"
    • Example: "[RFC2119]" rather than "[RFC 2119]"

  5. Citations may not include spaces, commas, quotation marks, or other punctuation (!, ?, etc.), and should be in-line with the normal line of type.

    • Example: "See RFC 2119 [RFC2119] for more information."
  6. Cross-references within the body of the memo and to other RFCs must use section numbers rather than page numbers, as pagination may change per format and device.

  7. A citation may A) follow the subject to which the citation applies or B) be read as part of the text. For example:

    1. As part of the transition to IPv6, NAT64 [RFC6146] and DNS64 [RFC6147] technologies will be utilized by some access networks to provide IPv4 connectivity for IPv6-only nodes [RFC6144].
    2. Note that SAVI raises a number of important privacy considerations that are discussed more fully in [RFC6959].
  8. For a document referenced multiple times in running text, the citation anchor must be at first use outside the abstract. Additional citations are allowed at the author's discretion.

We recommend using A) and strongly recommend consistent use of one style throughout.

3.6. Abbreviation Rules

Abbreviations should be expanded in document titles and upon first use in the document. The full expansion of the text should be followed by the abbreviation itself in parentheses. The exception is an abbreviation that is so common that the readership of RFCs can be expected to recognize it immediately; examples include (but are not limited to) TCP, IP, SNMP, and HTTP. The online list of abbreviations [ABBR] provides guidance. Some cases are marginal, and the RFC Editor will make the final judgment, weighing obscurity against complexity.

Note: The online list of abbreviations is not exhaustive or definitive. It is a list of abbreviations appearing in RFCs and sometimes reflects discussions with authors, Working Group Chairs, and/or Area Directors (ADs). Note that some abbreviations have multiple expansions. Additionally, this list includes some terms that look like abbreviations but that are actually fixed names for things and hence cannot and should not be expanded. These are noted as "No Expansion".

3.7. Images and Figures

The goal of having images within an RFC is to convey information. A good diagram or image expresses information quickly, clearly, and with low chance of misunderstanding. Technically correct but confusing images get in the way of understanding and implementation.

  1. Images should be legible when displayed on a standard screen (1920x1080) and printable on either A4 or US Letter paper. Any text within the diagram should be readable at that resolution.
  2. Authors should use black on white, not white on black. No color or greyscale [RFC7990][RFC7996]
  3. Keep your diagrams as simple as possible. If an object in the diagram is not immediately relevant, leave it out. If you have several ideas you want to convey, consider using more than one diagram.
  4. San-serif fonts are generally considered more readable for digital material. [citation needed]
  5. The style of diagrams within an RFC should be consistent both within a single RFC and within a cluster of RFCs (fonts, shapes, lines). For example, if you you use a dashed line to indicate a certain type of packet flow, then continue to use that style of line consistently.
  6. Line styles, including thickness, color, and arrow types, are easy methods to convey a particular meaning to the reader. Consistently use the same line styles to convey a particular meaning throughout all diagrams within an RFC in order to avoid confusing the reader.
  7. Flowcharts: avoid crossing the lines if possible.
  8. Captions or alternative text are encouraged for all figures, diagrams, and other artwork. [ALTTEXT] [RFC7991]

4. Structure of an RFC

A published RFC will largely 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 in more detail below.

First-page header                      * [Required]
Title                                    [Required]
Abstract                                 [Required]
RFC Editor or Stream Note              * [Upon request]
Status of This Memo                    * [Required]
Copyright Notice                       * [Required]
Table of Contents                      * [Required]
Body of the Memo                         [Required]

  1.  Introduction                       [Required]
  2.  Requirements Language (RFC 2119)
  3.  ...
       MAIN BODY OF THE TEXT
  6.  ...
  7.  IANA Considerations                [Required]
  8.  Internationalization Considerations
  9.  Security Considerations            [Required]
  10.  References
  10.1.  Normative References
  10.2.  Informative References
  Appendix A.
  Appendix B.

Acknowledgements
Contributors
Index
Author's Address                         [Required]

Within the body of the memo, the order shown above is strongly recommended. Exceptions may be questioned. Outside the body of the memo, the order above is required. The section numbers above are for illustrative purposes; they are not intended to correspond to required numbering in an RFC.

The elements preceding the body of the memo should not be numbered. Typically, the body of the memo will have numbered sections and the appendices will be labeled with letters. Any sections that appear after the appendices should not be numbered or labeled (e.g., see "Contributors" above).

4.1. First-Page Header

Headers will follow the format described in "RFC Streams, Headers, and Boilerplates" [RFC7841] and its successors. In addition, the following conventions will apply.

4.1.1. Author/Editor

The final determination of who should be listed as an author or editor on an RFC is made by the stream, as is whether or not including author affiliation is required.

The author's name (initial followed by family name) appears on the first line of the heading. Some variation, such as additional initials or capitalization of family name, is acceptable. Once the author has selected how their name should appear, they should use that display consistently in all of their documents.

The total number of authors or editors on the first page is generally limited to five individuals and their affiliations. If there is a request for more than five authors, the stream-approving body needs to consider if one or two editors should have primary responsibility for this document, with the other individuals listed in the Contributors or Acknowledgements section. There must be a direct correlation of authors and editors in the document header and the Authors' Addresses section. These are the individuals that must sign off on the document during the AUTH48 process and respond to inquiries, such as errata.

4.1.2. Organization

The author's organization is indicated on the line following the author's name.

For multiple authors, each author name appears on its own line, followed by that author's organization. When more than one author is affiliated with the same organization, the organization can be "factored out," appearing only once following the corresponding Author lines. However, such factoring is inappropriate when it would force an unacceptable reordering of author names.

If an author cannot or will not provide an affiliation for any reason, "Independent", "Individual Contributor", "Retired", or some other term that appropriately describes the author's affiliation may be used. Alternatively, a blank line may be included in the document header when no affiliation is provided.

4.1.3. ISSN: 2070-1721

The RFC Series has been assigned an International Standard Serial Number of 2070-1721 [ISO3297]. It will be included by the RFC Editor.

4.1.4. Digital Object Identifier 10.17487

The RFC Series has been assigned a Digital Object Identifier prefix of 10.17487 [RFC7669]. A DOI will be assigned and included by the RFC Editor.

4.1.5. Updates and Obsoletes

When an RFC obsoletes or updates a previously published RFC or RFCs, this information is included in the document header. For example:

"Updates: nnnn" or "Updates: nnnn, ..., nnnn"

"Obsoletes: nnnn" or "Obsoletes: nnnn, ..., nnnn"

If the document updates or obsoletes more than one document, numbers will be listed in ascending order.

4.2. Document Title

The title must be centered below the rest of the heading, preceded by two blank lines and followed by 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 and lengthy.

Abbreviations in a title must generally be expanded when first encountered (see Section 3.6 for additional guidance on abbreviations).

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)

The RFC Editor recommends that documents describing a particular company's private protocol should bear a title of the form "Foo's ... Protocol" (where Foo is a company name), to clearly differentiate it from a protocol of more general applicability.

4.3. Abstract Section

Every RFC must have an Abstract that provides 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 and some context with regards to its relationship (in particular, whether it updates or obsoletes) any other RFCs. In addition to its function in the RFC 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 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 overly long, incomplete, and redundant.

An Abstract is not a substitute for an Introduction; the RFC should be self-contained as if there were no Abstract. Similarly, the Abstract should be complete in itself. Given that the Abstract will appear independently in announcements and indices, mentions of other RFCs within the Abstract should include both an RFC number and either the full or short title. Any documents that are Updated or Obsoleted by the RFC must be mentioned in the Abstract if those documents offer important provisions of, or reasons for, the RFC. These may be presented in a list format if that improves readability.

4.4. RFC Editor or Stream Notes Section

A stream-approving body may approve the inclusion of an editorial note to explain anything unusual about the process that led to the document's publication or to note a correction. In this case, a stream note section will contain such a note.

Additionally, an RFC Editor Note section may contain a note inserted by the RFC Editor to highlight special circumstances surrounding an RFC.

4.5. Status of This Memo Section

The RFC Editor will supply an appropriate "Status of This Memo" as defined in RFC [RFC7841] and "Format for RFCs in the IAB Stream" [IAB-FORM].

4.7. Table of Contents Section

A Table of Contents (TOC) is required in all RFCs. It must be positioned after the Copyright Notice and before the Introduction.

4.8. Body of the Memo

Following the TOC is the body of the memo.

Each RFC must include 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.

4.8.1. Introduction Section

The Introduction section should always be the first section following the TOC (except in the case of MIB module documents). While "Introduction" is recommended, authors may choose alternate titles such as "Overview" or "Background". These alternates are acceptable.

For MIB module documents, common practice has been for "The Internet-Standard Management Framework" [MIB-BOILER] text to appear as Section 1.

4.8.2. Requirements Language Section

Some documents use certain capitalized words ("MUST", "SHOULD", etc.) to specify precise requirement levels for technical features. [RFC2119] and [RFC8174] define a default interpretation of these capitalized words in IETF documents. If this interpretation is used, RFCs 2119 and 8174 must be cited (as specified in RFCs 2119 and 8174) 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 memo (as defined by this document). It must appear as part of, or subsequent to, the Introduction section.

These words are considered part of the technical content of the document and 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 retransmisssions) For example, they must not be used to try to impose a particular method on implementers where the method is not required for interoperability.

4.8.3. IANA Considerations Section

For guidance on how to register IANA-related values or create new registries to be managed by IANA, see "Guidelines for Writing an IANA Considerations Section in RFCs" [BCP26].

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, the use of "TBD1", "TBD2", etc., is recommended in the IANA Considerations section and in the body of the memo.

If the authors have provided values to be assigned by IANA, the RFC Editor will verify that the values inserted by the authors match those that have actually been registered on the IANA site. When writing a given value, consistent use of decimal or hexadecimal is recommended.

If any of the IANA-related information is not clear, the RFC Editor will work with IANA to send queries to the authors to ensure that assignments and values are properly inserted.

4.8.4. Internationalization Considerations Section

All RFCs that deal with internationalization issues should have a section describing those issues; see "IETF Policy on Character Sets and Languages" [BCP18], Section 6, for more information.

4.8.5. Security Considerations Section

All RFCs must contain a section that discusses the security considerations relevant to the specification; see "Guidelines for Writing RFC Text on Security Considerations" [BCP72] for more information.

Note that additional boilerplate material for RFCs containing MIB and YANG modules also exists. See "Security Guidelines for IETF MIB Modules" [MIB-SEC] and "yang module security considerations" [YANG-SEC] for details.

4.8.6. References Section

The reference list is solely for recording reference entries. Introductory text or annotations beyond necessary translations [RFC7997] are not allowed.

The RFC style allows the use of any of a variety of reference styles, as long as they are used consistently within a document. However, where necessary, some reference styles have been described for use within the Series. See the following subsections as well as the References section of this document.

Reference lists must indicate whether each reference is normative or informative, where normative references are essential to implementing or understanding the content of the RFC and informative references provide additional information. More information about normative and informative references may be found in the IESG's statement "Normative and Informative References" [REFS]. When both normative and informative references exist, the references section should be split into two subsections:

Templates are available on the RFC Editor website for the XML format of certain references [REFEXAMPLE].

s. References

s.1. Normative References

        xxx
        ...
        xxx

s.2. Informative References

        xxx
        ...
        xxx

References will generally appear in alphanumeric order by citation tag. Where there are only normative or informative references, no subsection is required; the top-level section should say "Normative References" or "Informative References".

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 update the entry to refer to the RFC and publish both documents simultaneously.

4.8.6.1. Referencing RFCs

The following format is required for referencing RFCs. The Stream abbreviation should be used; when no stream is available, as with legacy RFCs, this may be left blank.

Note the ordering for multiple authors: the format of the name of the last author listed is different than that of all previous authors in the list.

For one author or editor:

[RFCXXXX] Last name, First initial., Ed. (if applicable), "RFC Title", Stream, Sub-series number (if applicable), RFC number, RFC DOI, Date of publication, <https://www.rfc-editor.org/info/rfc#>.

Example:

[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core," IETF, RFC 3080, DOI 10.17487/RFC3080, March 2001, <https://www.rfc-editor.org/info/rfc3080>.

[RFC8157] Leymann, N., Heidemann, C., Zhang, M., Sarikaya, B., and M. Cullen, "Huawei's GRE Tunnel Bonding Protocol", independent, RFC 8157, DOI 10.17487/RFC8157, May 2017, <https://www.rfc-editor.org/info/rfc8157>.

For two authors or editors:

[RFCXXXX] Last name, First initial., Ed. (if applicable) and First initial. Last name, Ed. (if applicable), "RFC Title", Stream, Sub-series number (if applicable), RFC number, RFC DOI, Date of publication, <https://www.rfc-editor.org/info/rfc#>.

Example:

[RFC6323] Renker, G. and G. Fairhurst, "Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP)", IETF, RFC 6323, DOI 10.17487/RFC6323, July 2011, <https://www.rfc-editor.org/info/rfc6323>.

For three or more authors or editors:

[RFCXXXX] Last name, First initial., Ed. (if applicable), Last name, First initial., Ed. (if applicable), and First initial. Last name, Ed. (if applicable), "RFC Title", Stream, Sub-series number (if applicable), RFC number, RFC DOI, Date of publication, <https://www.rfc-editor.org/info/rfc#>.

Example:

[RFC6429] Bashyam, M., Jethanandani, M., and A. Ramaiah, "TCP Sender Clarification for Persist Condition", IETF, RFC 6429, DOI 10.17487/RFC6429, December 2011, >https://www.rfc-editor.org/info/rfc6429 <.

4.8.6.2. Referencing RFC(s) in a Subseries (STDs, BCPs, and FYIs

Internet Standards (STDs) and Best Current Practices (BCPs) may consist of a single RFC or multiple RFCs. Authors should carefully consider whether they want to point the reader to the specific RFC or the sub series group. In the former case, references should appear as described in Section 4.8.6.2. In the latter case, the sub series number should take precedence as, for example, the citation tag, even in cases where the sub series currently contains only one RFC.

When an STD or BCP that contains multiple RFCs is referenced as a sub series group, the reference entry should include ALL of the RFCs comprising that sub-series in a reference grouping under a single citation tag [is it helpful to point them to 7991 or the like on how to do this here?]. The authors should refer to the specific RFC numbers as part of the text in the body of the document and cite the sub series number (for example, "see RFC 2026 of [BCP9]"). Inclusion of the URI to the STD or BCP info page (see Section 3.2.3 of [RFC5741]) is recommended. The text should appear as follows:

See RFC 1034 [STD13].

For an STD or BCP that contains one RFC:

[STDXXX] Last name, First initial., Ed. (if applicable), "RFC Title", Stream, Sub-series number, RFC number, RFC DOI, Date of publication, <https://www.rfc-editor.org/info/std#>.

Example:

[STD72] Gellens, R. and J. Klensin, "Message Submission for Mail", IETF, STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, <https://www.rfc-editor.org/info/std72>.

For an STD or BCP that contains two or more RFCs:

[STDXXX] Last name, First initial., Ed. (if applicable), "RFC Title", Stream, Sub-series number, RFC number, RFC DOI, Date of publication.

         Last name, First initial., Ed. (if applicable)
         and First initial. Last name, Ed. (if applicable),
         "RFC Title", Stream, Sub-series number, RFC number, RFC DOI,
         Date of publication.

         <https://www.rfc-editor.org/info/std#>

Example:

[STD13] Mockapetris, P., "Domain names - concepts and facilities", IETF, STD 13, RFC 1034, November 1987.

  Mockapetris, P., "Domain names - implementation and
  specification", IETF, STD 13, RFC 1035, DOI 10.17487/RFC1035,
  November 1987.

         <https://www.rfc-editor.org/info/std13>

Note - some RFCs contain an FYI sub-series number [FYI90] however, the FYI series was ended by RFC 6360. RFCs that were published with an FYI sub-series number and still maintain the FYI number must include the sub-series number in the reference and may otherwise be treated in the same manner as STDs and BCPs.

Grouping references to RFCs or other materials that are not part of a sub-series is discouraged.

4.8.6.3. Referencing Internet-Drafts

References to Internet Drafts may only appear as informative references. Given that several revisions of an I-D may be produced in a short time frame, references must include the posting date (month and year), the full Internet-Draft file name (including the version number), and the phrase "Internet Draft". Authors may reference multiple versions of an I-D. If the referenced I-D was also later published as an RFC, then that RFC must also be listed. The reference should include a stable URL for the draft, if available.

[SYMBOLIC-TAG] Last name, First initial., Ed. (if applicable) and First initial. Last name, Ed. (if applicable), "I-D Title", Work in Progress, Internet-Draft, draft-string-NN, Day Month Year, https://datatracker.ietf.org/doc/html/draft-something.

Example:

[RFC-STYLE] Flanagan, H. and S. Ginoza, "RFC Style Guide", Work in Progress, Internet-Draft, draft-flanagan-style-04, 27 September 2019, https://datatracker.ietf.org/doc/html/draft-flanagan-style-04.

4.8.6.4. Referencing Errata

The following format is required when a reference to an erratum report is necessary:

[ErrNumber] RFC Errata, Erratum ID number, RFC number, <https://www.rfc-editor.org/errata/eid#>.

[Err1912] RFC Errata, Erratum ID 1912, RFC 2978, <https://www.rfc-editor.org/errata/eid1912>.

4.8.6.5. Referencing IANA Registries

IANA registries may appear in normative or informative reference sections.

[IANA-SYMBOLIC-TAG]

  • IANA, "Registry Name", <URL>.
4.8.6.6. Referencing Other Standards Development Organizations (SDOs)

The following format is suggested when referencing a document or standard from another SDO in which authors are listed:

[SYMBOLIC-TAG]

  • Last name, First initial. and First initial. Last name,
  • "Document Title", Document reference number, Date of
  • publication, <URI if available>.

[W3C.REC-xml11]

  • Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E.,
  • Yergeau, F., and J. Cowan, "Extensible Markup Language
  • (XML) 1.1 (Second Edition)", W3C Recommendation
  • REC-xml11-20060816, August 2006,
  • <https://www.w3.org/TR/2006/REC-xml11-20060816>.

The order of authors in the list is the same as the order shown on the actual document and that the common, abbreviated form of the SDO is used.

Alternatively, when no list of authors is available, the following format is recommended:

[SYMBOLIC-TAG]  Organization, "Document Title", Document
                   reference number, Date of publication,
                   <URI if available>.

Example (undated; see note below):

[IEEE.802.15.4]
           IEEE, "IEEE Standard for Low-Rate Wireless Networks",
           IEEE 802.15.4,
           <https://ieeexplore.ieee.org/document/7460875/>.

Example (dated; see note below):

[IEEE802.1Q]  IEEE, "Local and Metropolitan Area
                 Networks -- Media Access Control (MAC)
                 Bridges and Virtual Bridged Local Area
                 Networks", IEEE Std 802.1Q-2011, August 2011,
                 <https://standards.ieee.org/findstds/standard/
                 802.1Q-2011.html>

Per the IEEE coordination team, listing dates for IEEE standards is not recommended unless there is a need to cite a particular section, in which case the dated reference is appropriate. An RFC with a dated IEEE reference suggests that the RFC only applies to that specific IEEE specification.

4.8.6.7. Referencing Webpages

References to webpages acceptable in either the normative or informative sections, as long as the URL provided is the most stable (i.e., unlikely to change and expected to be continuously available) and direct reference possible. The URL will be verified as valid during the RFC editorial process.

If a dated URI (one that includes a timestamp for the page) is available for a referenced web page, its use is required.

Note that the URL may not be the sole information provided for a reference entry.

The use of HTTPS rather than HTTP is strongly encouraged.

Example:

[SYMBOLIC-TAG] Author (if available), "Page Title (if available)", <URL>.

[ISOC-MANRS]  Internet Society, "Mutually Agreed
                 Norms for Routing Security",
                 <https://www.internetsociety.org/issues/manrs>
4.8.6.8. Referencing Email on Mailing Lists

When referencing emails to mailing lists, the template provided here should be used:

  • [reftag] Sender, A., "Subject: Subject line", message to the
  • listname mailing list, DD Month YYYY, <URL>.
4.8.6.9. Referencing Code Repositories

References to online code repositories such as GitHub or SourceForge should be used as informative references only. The reference entry should include the repository title, commit hash or similar release marker if available, date of last commit, and URL.

Examples:

[pysaml] "Python implementation of SAML2", commit 7135d53,
      6 March 2018, <https://github.com/IdentityPython/pysaml2>.

      [linuxlite] "Linux Lite", 9 March 2018,
                  <https://sourceforge.net/projects/linuxlite/>.

4.9. Appendices Section

The RFC Editor recommends placing references before the Appendices. Appendices should be labeled as "Appendix A. Title", "A.1. Title", "Appendix B. Title", etc.

4.10. Acknowledgements Section

This optional section may be used instead of, or in addition to, a Contributors section. It is often used by authors to publicly thank those who have provided feedback regarding a document and to note any documents from which text was borrowed.

4.11. Contributors Section

This optional section acknowledges those who have made significant contributions to the document.

In a similar fashion to the Author's Address section, the RFC Editor does not make the determination as to who should be listed as a contributor to an RFC. The determination of who should be listed as a contributor is made by the stream.

The Contributors section may include brief statements about the nature of particular contributions (e.g., "Sam contributed Section 3"), and it may also include affiliations of listed contributors. 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. The format of any contact information should be similar to the format of information in the Author's Address section.

4.12. Index

If included, an index appears at the end of the document, immediately before Author's Address section.

4.13. Author's Address or Authors' Addresses Section

This required section gives contact information for the author(s) listed in the first-page header.

Contact information must include a long-lived email address and optionally may include a postal address and/or telephone number. If the postal address is included, it should include the country name, using the English short name listed by the ISO 3166 Maintenance Agency [ISO_OBP]. The purpose of this section is to (1) unambiguously define author identity (e.g., the John Smith who works for FooBar Systems) and (2) provide contact information for future readers who have questions or comments.

The practice of munged email addresses (i.e., altering an email address to make it less readable to bots and web crawlers to avoid spam) is not appropriate in an archival document series. Author contact information is provided so that readers can easily contact the author with questions and/or comments. Address munging is not allowed in RFCs.

5. Security Considerations

This document has no security considerations.

6. IANA Considerations

This document has no IANA considerations.

7. Change Log

This section to be removed before publication.

8. References

8.1. Normative References

[STYLE-WEB]
RFC Editor, "Web Portion of the Style Guide", <https://www.rfc-editor.org/rfc-style-guide/part2.html>.

8.2. Informative References

[ABBR]
RFC Editor, "RFC Editor Abbreviations List", <https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt>.
[ALTTEXT]
W3C, "Understanding Success Criterion 1.3.1: Info and Relationships", <https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships>.
[BCP18]
Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, , <https://www.rfc-editor.org/info/bcp18>.
[BCP26]
Alvestrand, H. and T. Narten, "Guidelines for Writing an ANA Considerations Section in RFCs", BCP 26, RFC 5226, , <https://www.rfc-editor.org/info/bcp26>.
[BCP32]
Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, , <https://www.rfc-editor.org/info/bcp32>.
[BCP72]
Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, , <https://www.rfc-editor.org/info/bcp72>.
[BCP9]
Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, .
Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, .
Dusseault, L. and R. Sparks, "Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", BCP 9, RFC 5657, .
Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, .
Resnick, P., "Retirement of the "Internet Official Protocol Standards" Summary Document", BCP 9, RFC 7100, .
Kolkman, O., Bradner, S., and S. Turner, "Characterization of Proposed Standards", BCP 9, RFC 7127, .
Dawkins, S., "Increasing the Number of Area Directors in an IETF Area", BCP 9, RFC 7475, .
Halpern, J., Ed. and E. Rescorla, Ed., "IETF Stream Documents Require IETF Rough Consensus", BCP 9, RFC 8789, .
Rosen, B., "Responsibility Change for the RFC Series", BCP 9, RFC 9282, .
<https://www.rfc-editor.org/info/bcp9>
[CLUSTER]
RFC Editor, "Clusters in the RFC Editor Queue", <https://www.rfc-editor.org/cluster_def.html>.
[CMOS]
University of Chicago Press, 2010, "Chicago Manual of Style, 16th ed.", .
[FYI90]
Malkin, G. and J. Reynolds, "FYI on FYI: Introduction to the FYI Notes", FYI 90, RFC 1150, , <https://www.rfc-editor.org/info/fyi90>. Housley, R., "Conclusion of FYI RFC Sub-Series", RFC 6360, August 2011.
[IAB-FORM]
IAB, "Format for RFCs in the IAB Stream", <https://www.rfc-editor.org/rfc-style-guide/iab-format.txt>.
[ID-GUIDE]
IETF, "Guidelines to Authors of Internet Drafts", <https://www.ietf.org/ietf-ftp/1id-guidelines.txt>.
[IETF-TRUST]
IETF Trust, "Trust Legal Provisions (TLP)", <https://trustee.ietf.org/license-info/>.
[ISO3297]
Technical Committee ISO/TC 46, Information and documentation, Subcommittee SC 9, "Identification and description, Information and documentation - International standard serial number (ISSN)", .
[ISO_OBP]
ISO, "Online Browsing Platform (OBP)", <https://www.iso.org/obp/ui/>.
[MIB-BOILER]
IETF OPS Area, "Boilerplate for IETF MIB Documents", <https://www.ops.ietf.org/mib-boilerplate.html>.
[MIB-SEC]
IETF OPS Area, "Security Guidelines for IETF MIB Modules", <https://trac.tools.ietf.org/area/ops/trac/wiki/mib-security>.
[REFEXAMPLE]
RFC Editor, "Reference Examples", <https://www.rfc-editor.org/ref-example/>.
[REFS]
IESG, "IESG Statement: Normative and Informative", <https://www.ietf.org/iesg/statement/normative-informative.html>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC2223bis]
Reynolds, J., Ed. and R. Braden, Ed., "Instructions to Request for Comments (RFC) Authors", Work in Progress, Internet-Draft, draft-rfc-editor-rfc2223bis-08, , <https://datatracker.ietf.org/doc/html/draft-rfc-editor-rfc2223bis-08>.
[RFC4844]
Daigle, L., Ed. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, , <https://www.rfc-editor.org/info/rfc4844>.
[RFC6635]
Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, , <https://www.rfc-editor.org/info/rfc6635>.
[RFC7669]
Levine, J., "Assigning Digital Object Identifiers to RFCs", RFC 7669, DOI 10.17487/RFC7669, , <https://www.rfc-editor.org/info/rfc7669>.
[RFC7841]
Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed., "RFC Streams, Headers, and Boilerplates", RFC 7841, DOI 10.17487/RFC7841, , <https://www.rfc-editor.org/info/rfc7841>.
[RFC7990]
Flanagan, H., "RFC Format Framework", RFC 7990, DOI 10.17487/RFC7990, , <https://www.rfc-editor.org/info/rfc7990>.
[RFC7991]
Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI 10.17487/RFC7991, , <https://www.rfc-editor.org/info/rfc7991>.
[RFC7996]
Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", RFC 7996, DOI 10.17487/RFC7996, , <https://www.rfc-editor.org/info/rfc7996>.
[RFC7997]
Flanagan, H., Ed., "The Use of Non-ASCII Characters in RFCs", RFC 7997, DOI 10.17487/RFC7997, , <https://www.rfc-editor.org/info/rfc7997>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[STD66]
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, , <https://www.rfc-editor.org/info/std66>.
[TERMS]
RFC Editor, "Terms List", <https://www.rfc-editor.org/styleguide.html>.
[YANG-SEC]
IETF Ops Area, "yang module security considerations", <https://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines>.

The following procedures are related to the application and updating of the RFC Style Guide.

A.1. Dispute Resolution

There are competing rationales for some of the rules described in this Guide, and the RFC Editor has selected the ones that work best for the Series. However, at times, an author may have a disagreement with the RFC Production Center (RPC) over the application of Style Guide conventions. In such cases, the authors should discuss their concerns with the RPC. If no agreement can be reached between the RPC and the authors, the RFC Series Editor will, with input from the appropriate stream-approving body, make a final determination. If further resolution is required, the dispute resolution process as described in the RFC Editor Model [RFC6635] will be followed.

A.2. Returning an I-D to the Document Stream

For a given document, if the RFC Editor determines that it cannot be edited without serious risk of altering the meaning of the technical content or if the RFC Editor does not have the resources to provide the level of editing it needs, it may be sent back to the stream- approving body with a request to improve the clarity, consistency, and/or readability of the document. This is not to be considered a dispute with the author.

A.3. Revising This Document and Associated Web Pages

The RFC Series is continually evolving as a document series. This document focuses on the fundamental and stable requirements that must be met by an RFC. From time to time, the RFC Editor may offer less formal recommendations that authors may apply at their discretion; these recommendations may be found on the RFC Editor website "Guidelines for RFC Style" [STYLE-WEB].

When a new recommendation is made regarding the overall structure and formatting of RFCs, it will be published on that page and accepted for a period of time before the RFC Editor determines whether it should become part of the fundamental requirements in the RFC Style Guide or remain as a less formal recommendation. That period of time will vary, in part depending on the frequency with which authors encounter and apply the guidance.

Appendix B. Acknowledgements

This document refers heavily to RFC2223 and [RFC2223bis]; as such, we are grateful to the authors of those documents for putting their time and effort into the RFC Series.

Much of this document was written by Heather Flanagan during her term as the RFC Series Editor (RSE).

Authors' Addresses

Sandy Ginoza
RFC Production Center
Jean Mahoney
RFC Production Center
Alice Russo
RFC Production Center