summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7322.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7322.txt')
-rw-r--r--doc/rfc/rfc7322.txt1347
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc7322.txt b/doc/rfc/rfc7322.txt
new file mode 100644
index 0000000..4139db0
--- /dev/null
+++ b/doc/rfc/rfc7322.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Internet Architecture Board (IAB) H. Flanagan
+Request for Comments: 7322 S. Ginoza
+Obsoletes: 2223 RFC Editor
+Category: Informational September 2014
+ISSN: 2070-1721
+
+
+ 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 2223, "Instructions to RFC Authors".
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Architecture Board (IAB)
+ and represents information that the IAB has deemed valuable to
+ provide for permanent record. It represents the consensus of the
+ Internet Architecture Board (IAB). Documents approved for
+ publication by the IAB are not a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7322.
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document.
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 1]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. RFC Editor's Philosophy .........................................4
+ 3. RFC Style Conventions ...........................................5
+ 3.1. Language ...................................................5
+ 3.2. Punctuation ................................................5
+ 3.3. DNS Names and URIs .........................................6
+ 3.4. Capitalization .............................................6
+ 3.5. Citations ..................................................6
+ 3.6. Abbreviation Rules .........................................7
+ 4. Structure of an RFC .............................................8
+ 4.1. First-Page Header ..........................................9
+ 4.1.1. Author/Editor .......................................9
+ 4.1.2. Organization ........................................9
+ 4.1.3. "ISSN: 2070-1721" ..................................10
+ 4.1.4. Updates and Obsoletes ..............................10
+ 4.2. Full Title ................................................10
+ 4.3. Abstract Section ..........................................11
+ 4.4. RFC Editor or Stream Notes Section ........................11
+ 4.5. Status of This Memo Section ...............................11
+ 4.6. Copyright, Licenses, and IPR Boilerplate Section ..........11
+ 4.7. Table of Contents Section .................................11
+ 4.8. Body of the Memo .........................................12
+ 4.8.1. Introduction Section ...............................12
+ 4.8.2. Requirement Language Section .......................12
+ 4.8.3. IANA Considerations Section ........................13
+ 4.8.4. Internationalization Considerations Section ........13
+ 4.8.5. Security Considerations Section ....................13
+ 4.8.6. References Section .................................14
+ 4.8.6.1. URIs in RFCs ..............................15
+ 4.8.6.2. Referencing RFCs ..........................15
+ 4.8.6.3. Referencing STDs and BCPs .................16
+ 4.8.6.4. Referencing Internet-Drafts ...............17
+ 4.8.6.5. Referencing Errata ........................18
+ 4.8.6.6. Referencing Other Standards Development
+ Organizations (SDOs) ......................18
+ 4.9. Appendices Section ........................................19
+ 4.10. Acknowledgements Section .................................19
+ 4.11. Contributors Section .....................................19
+ 4.12. "Author's Address" or "Authors' Addresses" Section .......20
+ 5. Security Considerations ........................................20
+ 6. References .....................................................20
+ 6.1. Normative References ......................................20
+ 6.2. Informative References ....................................20
+
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 2]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+ Appendix A. Related Procedures ....................................23
+ A.1. Dispute Resolution .........................................23
+ A.2. Returning an I-D to the Document Stream ....................23
+ A.3. Revising This Document and Associated Web Pages ............23
+ IAB Members at the Time of Approval ...............................24
+ Acknowledgements ..................................................24
+ Contributors ......................................................24
+ Authors' Addresses ................................................24
+
+1. Introduction
+
+ The ultimate goal of the RFC publication process is to produce
+ documents that are readable, clear, consistent, and reasonably
+ uniform. 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]. It 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 technical publishing has generally accepted rules for
+ grammar, punctuation, capitalization, sentence length and complexity,
+ parallelism, 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.
+
+
+
+
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 3]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+2. RFC Editor's Philosophy
+
+ Authors may find it helpful to understand the RFC Editor's goals
+ during the publication process, namely to:
+
+ - Prepare the document according to RFC style and format.
+
+ - Make the document as clear, consistent, and readable as
+ possible.
+
+ - Correct larger content/clarity issues; flag any unclear passages
+ for author review.
+
+ - Fix inconsistencies (e.g., terms that appear in various forms,
+ text that appears multiple times, or inconsistent
+ capitalization).
+
+ 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.
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 4]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+3. RFC Style Conventions
+
+ This Style Guide does not use terminology as defined in RFC 2119
+ [BCP14]. 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
+
+ * No overstriking (or underlining) is allowed.
+
+ * When a sentence ended by a period is immediately followed by
+ another sentence, there must be two blank spaces after the period.
+
+ * A comma is used before the last item of a series, e.g.,
+
+ "TCP service is reliable, ordered, and full duplex"
+
+ * 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.
+
+
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 5]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+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.,
+
+ <http://example.com/>
+
+3.4. Capitalization
+
+ * 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].
+
+ * 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.
+
+ * Section titles that are in sentence form will follow typical
+ sentence capitalization.
+
+ * Titles of figures may be in sentence form or use title case.
+
+3.5. Citations
+
+ * References and citations must match. That is, there must be a
+ reference for each citation used, and vice versa.
+
+ * Citations must be enclosed in square brackets (e.g., "[CITE1]").
+
+ * A citation/reference tag must not contain spaces.
+
+ Example: "[RFC2119]" rather than "[RFC 2119]"
+
+ However, the proper textual naming of an RFC contains a space.
+
+ Example: "See RFC 2119 [BCP14] for more information."
+
+ * 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.
+
+
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 6]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+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".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 7]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+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. Sections are allowed to contain
+ nothing but subsections. 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 in I-D]
+ 8. Internationalization Considerations
+ 9. Security Considerations [Required]
+ 10. References
+ 10.1. Normative References
+ 10.2. Informative References
+ Appendix A.
+ Appendix B.
+ Acknowledgements
+ Contributors
+ 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).
+
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 8]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+4.1. First-Page Header
+
+ Headers will follow the format described in "RFC Streams, Headers,
+ and Boilerplates" [RFC5741] and its successors. In addition, the
+ following conventions will apply.
+
+4.1.1. Author/Editor
+
+ The determination of who should be listed as an author or editor on
+ an RFC is made by the stream.
+
+ 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.
+
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 9]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+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. 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. Full 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.
+
+
+
+
+
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 10]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+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.
+
+ 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.
+
+ 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.
+
+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 5741 [RFC5741] and "Format for RFCs in the IAB Stream"
+ [IAB-FORM].
+
+4.6. Copyright, Licenses, and IPR Boilerplate Section
+
+ The full copyright and license notices are available on the IETF
+ Trust Legal Provisions documents website [IETF-TRUST].
+
+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.
+
+
+
+Flanagan & Ginoza Informational [Page 11]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+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.
+ RFC 2119 [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 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
+
+
+
+Flanagan & Ginoza Informational [Page 12]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+ 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.
+
+ 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).
+
+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.
+
+
+
+
+Flanagan & Ginoza Informational [Page 13]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+4.8.6. References Section
+
+ The reference list is solely for recording reference entries.
+ Introductory text is 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 examples in this document.
+
+ The RFC Editor ensures that references to other RFCs refer to the
+ most current RFC available on that topic (unless provided with a
+ reason not to do so). When referring to an obsoleted document, it is
+ common practice to also refer to the most recent version.
+
+ A reference to an RFC that has been assigned an STD [RFC1311], BCP
+ [RFC1818], or FYI [FYI90] sub-series number must include the
+ sub-series number of the document. Note that 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.
+
+ 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:
+
+ s. References
+
+ s.1. Normative References
+
+ xxx
+ ...
+ xxx
+
+ s.2. Informative References
+
+ xxx
+ ...
+ xxx
+
+
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 14]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+ 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. URIs in RFCs
+
+ The use of URIs in references is acceptable, as long as the URI is
+ the most stable (i.e., unlikely to change and expected to be
+ continuously available) and direct reference possible. The URI 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 URIs may not be the sole information provided for a
+ reference entry.
+
+4.8.6.2. Referencing RFCs
+
+ The following format is required for referencing RFCs. 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", Sub-series number (if applicable),
+ RFC number, Date of publication,
+ <http://www.rfc-editor.org/info/rfc#>.
+
+ Example:
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange
+ Protocol Core", RFC 3080, March 2001,
+ <http://www.rfc-editor.org/info/rfc3080>.
+
+
+
+
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 15]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+ For two authors or editors:
+
+ [RFCXXXX] Last name, First initial., Ed. (if applicable)
+ and First initial. Last name, Ed. (if applicable),
+ "RFC Title", Sub-series number (if applicable),
+ RFC number, Date of publication,
+ <http://www.rfc-editor.org/info/rfc#>.
+
+ Example:
+
+ [RFC6323] Renker, G. and G. Fairhurst, "Sender RTT
+ Estimate Option for the Datagram Congestion
+ Control Protocol (DCCP)", RFC 6323, July 2011,
+ <http://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", Sub-series number (if applicable),
+ RFC number, Date of publication,
+ <http://www.rfc-editor.org/info/rfc#>.
+
+ Example:
+
+ [RFC6429] Bashyam, M., Jethanandani, M., and A. Ramaiah,
+ "TCP Sender Clarification for Persist
+ Condition", RFC 6429, December 2011,
+ <http://www.rfc-editor.org/info/rfc6429>.
+
+4.8.6.3. Referencing STDs and BCPs
+
+ Internet Standards (STDs) and Best Current Practices (BCPs) may
+ consist of a single RFC or multiple RFCs. When an STD or BCP that
+ contains multiple RFCs is referenced, the reference entry should
+ include ALL of the RFCs comprising that sub-series. The authors
+ should refer to specific RFC numbers as part of the text (not as
+ citations) and cite the sub-series number. 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].
+
+
+
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 16]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+ For an STD or BCP that contains one RFC:
+
+ [STDXXX] Last name, First initial., Ed. (if applicable),
+ "RFC Title", Sub-series number, RFC number, Date of
+ publication, <http://www.rfc-editor.org/info/std#>.
+
+ Example:
+
+ [STD72] Gellens, R. and J. Klensin, "Message Submission
+ for Mail", STD 72, RFC 6409, November 2011,
+ <http://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", Sub-series number, RFC number, Date of
+ publication.
+
+ Last name, First initial., Ed. (if applicable)
+ and First initial. Last name, Ed. (if applicable),
+ "RFC Title", Sub-series number, RFC number, Date of
+ publication.
+
+ <http://www.rfc-editor.org/info/std#>
+
+ Example:
+
+ [STD13] Mockapetris, P., "Domain names - concepts and
+ facilities", STD 13, RFC 1034, November 1987.
+
+ Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ <http://www.rfc-editor.org/info/std13>
+
+4.8.6.4. 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 "Work in Progress". 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.
+
+
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 17]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+ [SYMBOLIC-TAG] Last name, First initial., Ed. (if applicable)
+ and First initial. Last name, Ed. (if
+ applicable), "I-D Title", Work in Progress,
+ draft-string-NN, Month Year.
+
+ Example:
+
+ [RFC-STYLE] Flanagan, H. and S. Ginoza, "RFC Style Guide",
+ Work in Progress, draft-flanagan-style-01,
+ June 2013.
+
+4.8.6.5. Referencing Errata
+
+ The following format is required when a reference to an erratum
+ report is necessary:
+
+ [ErrNumber] RFC Errata, Erratum ID number, RFC number.
+
+ [Err1912] RFC Errata, Erratum ID 1912, RFC 2978.
+
+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,
+ <http://www.w3.org/TR/2006/REC-xml11-20060816>.
+
+ Note that 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.
+
+
+
+
+
+
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 18]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+ 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:
+
+ [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,
+ <http://standards.ieee.org/findstds/standard/
+ 802.1Q-2011.html>.
+
+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 ("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.
+
+
+
+
+Flanagan & Ginoza Informational [Page 19]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+4.12. "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. References
+
+6.1. Normative References
+
+ [STYLE-WEB]
+ RFC Editor, "Web Portion of the Style Guide",
+ <http://www.rfc-editor.org/rfc-style-guide/part2.html>.
+
+6.2. 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,
+ <http://www.rfc-editor.org/info/bcp14>.
+
+ [BCP18] Alvestrand, H., "IETF Policy on Character Sets and
+ Languages", BCP 18, RFC 2277, January 1998,
+ <http://www.rfc-editor.org/info/bcp18>.
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 20]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+ [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008, <http://www.rfc-editor.org/info/bcp26>.
+
+ [BCP32] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
+ Names", BCP 32, RFC 2606, June 1999,
+ <http://www.rfc-editor.org/info/bcp32>.
+
+ [BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
+ Text on Security Considerations", BCP 72, RFC 3552,
+ July 2003, <http://www.rfc-editor.org/info/bcp72>.
+
+ [CLUSTER] RFC Editor, "Clusters in the RFC Editor Queue",
+ <http://www.rfc-editor.org/cluster_def.html>.
+
+ [CMOS] Chicago Manual of Style, 16th ed. Chicago: University of
+ Chicago Press, 2010.
+
+ [FYI90] Malkin, G. and J. Reynolds, "FYI on FYI: Introduction to
+ the FYI Notes", FYI Notes, RFC 1150, March 1990.
+
+ Housley, R., "Conclusion of FYI RFC Sub-Series", RFC 6360,
+ August 2011.
+
+ [IAB-FORM] IAB, "Format for RFCs in the IAB Stream",
+ <http://www.rfc-editor.org/rfc-style-guide/
+ iab-format.txt>.
+
+ [ID-GUIDE] IETF, "Guidelines to Authors of Internet Drafts",
+ <http://www.ietf.org/ietf-ftp/1id-guidelines.txt>.
+
+ [IETF-TRUST]
+ IETF Trust, "Trust Legal Provisions (TLP)",
+ <http://trustee.ietf.org/license-info/>.
+
+ [ISO_OBP] ISO, "Online Browsing Platform (OBP)",
+ <https://www.iso.org/obp/ui/>.
+
+ [ISO3297] Technical Committee ISO/TC 46, Information and
+ documentation, Subcommittee SC 9, Identification and
+ description, "Information and documentation -
+ International standard serial number (ISSN)",
+ September 2007.
+
+ [MIB-BOILER]
+ IETF OPS Area, "Boilerplate for IETF MIB Documents",
+ <http://www.ops.ietf.org/mib-boilerplate.html>.
+
+
+
+
+Flanagan & Ginoza Informational [Page 21]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+ [MIB-SEC] IETF OPS Area, "Security Guidelines for IETF MIB Modules",
+ <http://trac.tools.ietf.org/area/ops/trac/wiki/
+ mib-security>.
+
+ [REFS] IESG, "IESG Statement: Normative and Informative
+ References", <http://www.ietf.org/iesg/statement/
+ normative-informative.html>.
+
+ [RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311,
+ March 1992, <http://www.rfc-editor.org/info/rfc1311>.
+
+ [RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best Current
+ Practices", RFC 1818, August 1995,
+ <http://www.rfc-editor.org/info/rfc1818>.
+
+ [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
+ RFC 2223, October 1997, <http://www.rfc-editor.org/
+ info/rfc2223>.
+
+ [RFC2223bis]
+ Reynolds, J., Ed. and B. Braden, Ed. "Instructions to
+ Request for Comments (RFC) Authors", Work in Progress,
+ draft-rfc-editor-rfc2223bis-08, August 2004.
+
+ [RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC
+ Series and RFC Editor", RFC 4844, July 2007,
+ <http://www.rfc-editor.org/info/rfc4844>.
+
+ [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams,
+ Headers, and Boilerplates", RFC 5741, December 2009,
+ <http://www.rfc-editor.org/info/rfc5741>.
+
+ [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor
+ Model (Version 2)", RFC 6635, June 2012,
+ <http://www.rfc-editor.org/info/rfc6635>.
+
+ [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66,
+ RFC 3986, January 2005, <http://www.rfc-editor.org/
+ info/std66>.
+
+ [TERMS] RFC Editor, "Terms List",
+ <http://www.rfc-editor.org/styleguide.html>.
+
+ [YANG-SEC] IETF OPS Area, "yang module security considerations",
+ <http://trac.tools.ietf.org/area/ops/trac/wiki/
+ yang-security-guidelines>.
+
+
+
+
+Flanagan & Ginoza Informational [Page 22]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+Appendix A. Related Procedures
+
+ 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.
+
+
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 23]
+
+RFC 7322 RFC Style Guide September 2014
+
+
+IAB Members at the Time of Approval
+
+ Jari Arkko (IETF Chair)
+ Mary Barnes
+ Marc Blanchet
+ Joel Halpern
+ Ted Hardie
+ Joe Hildebrand
+ Russ Housley
+ Eliot Lear
+ Xing Li
+ Erik Nordmark
+ Andrew Sullivan
+ Dave Thaler
+ Brian Trammell
+
+Acknowledgements
+
+ This document refers heavily to RFC 2223 [RFC2223] and
+ [RFC2223bis]; as such, we are grateful to the authors of those
+ documents for putting their time and effort into the RFC Series.
+
+ Robert T. Braden
+ USC Information Sciences Institute
+
+ Joyce Reynolds
+
+ Jon Postel
+
+Contributors
+
+ Alice Russo
+ RFC Production Center
+
+Authors' Addresses
+
+ Heather Flanagan
+ RFC Series Editor
+
+ EMail: rse@rfc-editor.org
+
+
+ Sandy Ginoza
+ RFC Production Center
+
+ EMail: rfc-editor@rfc-editor.org
+
+
+
+
+
+Flanagan & Ginoza Informational [Page 24]
+