### Grammar and Style Examples Source: https://www.rfc-editor.org/styleguide/tips Illustrates common grammar and style issues in technical writing, providing corrected examples for clarity and adherence to standards. ```en Subject and verb agreement: Ex: Using the mechanisms and procedures are important. (Incorrect.) Using the mechanisms and procedures is important. (Correct; the subject is “using”.) ``` ```en Misplaced modifiers: Ex: It should accept the packet sent to the node that has an invalid value. (Incorrect.) It should accept the packet that was sent to the node and has an invalid value. (Correct, assuming the intended meaning is that the packet, not the node, has the invalid value.) ``` ```en Restrictive (that) and non-restrictive (which) clauses: that (restrictive) – introduces information that is essential to the meaning of the sentence. Ex: RST attacks that rely on brute force are relatively easy to detect at the TCP layer (i.e., only some RST attacks rely on brute force). which (non-restrictive) – follows a comma and provides non-essential information. Ex: RST attacks, which rely on brute force, are relatively easy to detect at the TCP layer (i.e., all RST attacks rely on brute force). ``` ```en Ambiguous pronouns: Ex: For each broadcast network, a designated router describes it in its network-LSA (Note: The “it” and “its” need clarification). ``` ```en Abbreviations and apostrophes: Ex: the LSRs (plural) the LSR’s address (singular possessive) the LSRs’ addresses (plural possessive) ``` ```en Articles: Ex: the router (definite: a specific router) a router (indefinite: a non-specific router) routers (no article: refers to “routers” in a general sense or all routers) ``` ```en Terminology and notation: Ex: This document uses the terminology defined in [RFC6275]. Ex: “|” represents foo in this document. Ex: white space vs. whitespace vs. ‘whitespace’ vs. Whitespace ``` ```en Numbers: Ex: The field is set to 3. Ex: There are five options. ``` -------------------------------- ### RFC Style Guide Introduction Source: https://www.rfc-editor.org/styleguide/part2 Introduces the web portion of the RFC Style Guide, noting that it addresses issues raised since RFC 7322 and references a GitHub repository for revisions. ```html # Web Portion of the Style Guide The following style issues have been raised with the RFC Production Center since [RFC 7322, “RFC Style Guide”](https://www.rfc-editor.org/info/rfc7322), has been published. These will be considered for the greater Style Guide when it is revised. Note that a revision draft is in [GitHub](https://github.com/rfc-editor/draft-rfc-editor-7322bis). This page will be updated to reflect current usage. Note that the RFC Production Center follows these guidelines but will edit and ask questions as needed. ``` -------------------------------- ### Didactic Capitalization Example Source: https://www.rfc-editor.org/styleguide/part2 Illustrates the correct usage of capitalization for terms like XML, emphasizing avoiding unnecessary capitalization for didactic purposes. ```text Use of didactic capitalization is not needed. **Example:** Extensible Markup Language (XML) (not EXtensible Markup Language (XML) or eXtensible Markup Language (XML)) ``` -------------------------------- ### RFC Editor Style Guide and Resources Source: https://www.rfc-editor.org/styleguide/tips Links to essential resources for authors, including the official RFC Editor Style Guide, templates, and related IETF author resources. ```en RFC Editor Style Guide: https://www.rfc-editor.org/styleguide RFC 7322: https://www.rfc-editor.org/info/rfc7322 I-D Author Resources: https://authors.ietf.org Templates available: https://authors.ietf.org/en/templates-and-schemas ``` -------------------------------- ### RFC Style Guide Documents Source: https://www.rfc-editor.org/styleguide/index Provides links to the core documents that constitute the RFC Style Guide, including the main style guide, web portion, and specific statements. ```APIDOC RFC 7322: "RFC Style Guide" URL: https://www.rfc-editor.org/info/rfc7322 Description: The primary document defining the RFC Style Guide. Web Portion of the Style Guide URL: https://www.rfc-editor.org/styleguide/part2 Description: The web-based component of the RFC Style Guide. RFC Series Editor statement on authorship (May 2015) URL: https://mailarchive.ietf.org/arch/msg/rfc-interest/SHM7dHZd_S1a-CkW2JCBvxdKmcs/ Description: Statement from the RFC Series Editor regarding authorship practices. ``` -------------------------------- ### RFC Editor Style Guide Navigation Source: https://www.rfc-editor.org/styleguide/part2 Provides links to various sections of the RFC Editor website, including document retrieval, errata, FAQs, history, author resources, and the publication process. ```html

Search RFCs

[Advanced Search](https://www.rfc-editor.org/search/rfc_search.php) [RFC Editor](https://www.rfc-editor.org/) * ## The Series * [Document Retrieval](https://www.rfc-editor.org/retrieve/) * [Errata](https://www.rfc-editor.org/errata.php) * [FAQ](https://www.rfc-editor.org/faq/) * [Format Change FAQ](https://www.rfc-editor.org/rse/format-faq/) * [History](https://www.rfc-editor.org/history/) * [About Us](https://www.rfc-editor.org/about/) * [Other Information](https://www.rfc-editor.org/other/) * ## For Authors * [Publication Process](https://www.rfc-editor.org/pubprocess/) * [Publication Queue](https://www.rfc-editor.org/current_queue.php) * [Style Guide](https://www.rfc-editor.org/styleguide/) * [I-D Author Resources](https://authors.ietf.org) * [Independent Submissions](https://www.rfc-editor.org/about/independent/) * ## Sponsor [](https://www.internetsociety.org) ``` -------------------------------- ### RFC Author Resources and Lists Source: https://www.rfc-editor.org/styleguide/index Lists resources for RFC authors, including abbreviations, terms, and formatting guidelines. ```APIDOC Abbreviations List URL: https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list Description: A list of expansions for abbreviations and acronyms used in RFCs. Terms List URL: https://www.rfc-editor.org/rpc/wiki/doku.php?id=terms Description: A table of decisions regarding consistent terminology usage in RFCs. IAB Format URL: https://www.rfc-editor.org/materials/iab-format.txt Description: IAB-specific formatting requirements for RFCs in the IAB stream. Tips and Resources for Authors URL: https://www.rfc-editor.org/styleguide/tips Description: Writing tips and resources specifically curated for RFC authors. ``` -------------------------------- ### RFC Editor Website Utilities Source: https://www.rfc-editor.org/styleguide/index Provides links to website utilities and policy statements for the RFC Editor site. ```APIDOC Reports URL: https://www.rfc-editor.org/report-summary Description: Summary of RFC Editor reports. Privacy Statement URL: https://www.ietf.org/privacy-statement/ Description: Statement regarding the privacy policy of related organizations. Site Map URL: https://www.rfc-editor.org/sitemap Description: Sitemap for the RFC Editor website. Contact Us URL: https://www.rfc-editor.org/contact Description: Contact information for the RFC Editor. ``` -------------------------------- ### RFC Reference Entries Source: https://www.rfc-editor.org/styleguide/index Provides access to reference entries for RFCs, STDs, and BCPs in various formats. ```APIDOC Reference Entries for RFCs Formats: XML (via BibXML Service), TXT BibXML Service URL: https://bib.ietf.org TXT URL: https://www.rfc-editor.org/in-notes/rfc-ref.txt Description: Access to reference data for RFC documents. Reference Entries for STDs and BCPs Formats: XML, TXT XML URL: https://bib.ietf.org/indexed-sources/relaton-data-rfcsubseries/ TXT (STD Subseries) URL: https://www.rfc-editor.org/in-notes/std-ref.txt TXT (BCP Subseries) URL: https://www.rfc-editor.org/in-notes/bcp-ref.txt Description: Access to reference data for Standards Track (STD) and Best Current Practice (BCP) documents. ``` -------------------------------- ### Formatting Abbreviations Source: https://www.rfc-editor.org/styleguide/part2 Recommendations for handling abbreviations, including avoiding their use as verbs and affixing suffixes without punctuation. ```APIDOC Avoid using abbreviations as verbs when possible. If unavoidable, suffixes should be affixed without punctuation, for example, “XORed” (not XOR’ed) and “NATed” (not NAT-ed). ``` -------------------------------- ### Sponsor and Affiliated Organizations Source: https://www.rfc-editor.org/styleguide/index Links to the primary sponsor and key affiliated organizations within the internet standards ecosystem. ```APIDOC Internet Society URL: https://www.internetsociety.org Description: The primary sponsor of the RFC Editor. IAB URL: https://www.iab.org/ Description: Internet Architecture Board. IANA URL: https://www.iana.org/ Description: Internet Assigned Numbers Authority. IETF URL: https://www.ietf.org Description: Internet Engineering Task Force. IRTF URL: https://www.irtf.org Description: Internet Research Task Force. ISE URL: https://www.rfc-editor.org/about/independent Description: Independent Submissions Editor. ISOC URL: https://www.internetsociety.org Description: Internet Society. IETF Trust URL: https://trustee.ietf.org/ Description: The entity responsible for the IETF intellectual property. ``` -------------------------------- ### Referencing Web-Based Public Code Repositories Source: https://www.rfc-editor.org/styleguide/part2 Format for referencing code repositories like GitHub for Informative References only. Authors and commit hashes should be included where appropriate. ```APIDOC Format of reference entries: * authors — omit them * title — include if available (some judgement may be required on the part of the editors and authors to have a sensible title) * commit hash — include if exists, short form preferred if available ``` -------------------------------- ### Old RFC Editorial Materials Source: https://www.rfc-editor.org/styleguide/index Links to superseded documents related to RFC editorial policies and author instructions. ```APIDOC RFC Editorial Policies URL: https://www.rfc-editor.org/old/policy.html Description: A collection of past policies concerning RFC editorial matters. "Instructions to RFC Authors" URL: https://www.rfc-editor.org/old/instructions2authors.txt Description: A draft document that was intended as a replacement for RFC 2223. ``` -------------------------------- ### RFC Editor Navigation Links Source: https://www.rfc-editor.org/styleguide/index Provides essential navigation links for the RFC Editor website, covering search, document retrieval, and general information. ```APIDOC Advanced Search URL: https://www.rfc-editor.org/search/rfc_search.php Description: Access to the advanced search functionality for RFC documents. RFC Editor Home URL: https://www.rfc-editor.org/ Description: Link to the main page of the RFC Editor website. Document Retrieval URL: https://www.rfc-editor.org/retrieve/ Description: Service for retrieving RFC documents. Errata URL: https://www.rfc-editor.org/errata.php Description: Access to the errata list for published RFCs. FAQ URL: https://www.rfc-editor.org/faq/ Description: Frequently Asked Questions about the RFC process. Format Change FAQ URL: https://www.rfc-editor.org/rse/format-faq/ Description: FAQ specifically addressing changes in RFC formatting. History URL: https://www.rfc-editor.org/history/ Description: Information regarding the history of the RFC series. About Us URL: https://www.rfc-editor.org/about/ Description: Information about the organization and people behind the RFC Editor. Other Information URL: https://www.rfc-editor.org/other/ Description: Miscellaneous information related to the RFC process. Publication Process URL: https://www.rfc-editor.org/pubprocess/ Description: Details on the process for publishing RFCs. Publication Queue URL: https://www.rfc-editor.org/current_queue.php Description: Current status of documents in the RFC publication pipeline. Style Guide URL: https://www.rfc-editor.org/styleguide/ Description: Direct link to the main RFC Style Guide. I-D Author Resources URL: https://authors.ietf.org Description: Resources for authors of Internet-Drafts. Independent Submissions URL: https://www.rfc-editor.org/about/independent/ Description: Information regarding independent submissions to the RFC series. ``` -------------------------------- ### Sample RFC Title Page Header Source: https://www.rfc-editor.org/styleguide/headers-and-boilerplate Provides an example of an earlier RFC header, illustrating the placement of information like author, affiliation, obsoletes, and publication date. ```text Network Working Group T. Dierks Request for Comments: 4346 Independent Obsoletes: 2246 E. Rescorla Category: Standards Track RTFM, Inc. April 2006 ``` -------------------------------- ### Status of This Memo Boilerplate Source: https://www.rfc-editor.org/styleguide/index Details the 'Status of This Memo' text as defined by RFC 7841 and RFC 9280, with a link to all permutations. ```APIDOC Status of This Memo Boilerplate Defined by: RFC 7841, RFC 9280 URL: https://www.rfc-editor.org/styleguide/headers-and-boilerplate/ Permutations URL: https://www.rfc-editor.org/materials/status-memos.txt Description: Specifies the required 'Status of This Memo' text and provides access to all variations. ``` -------------------------------- ### Terminology Sections Recommendation Source: https://www.rfc-editor.org/styleguide/part2 Terminology sections are advised for documents heavy with terminology or abbreviations. Prioritize pointing to existing definitions when feasible. ```text Terminology sections are recommended for docs that are terminology/abbreviation heavy, but documents should point to existing definitions when possible. ``` -------------------------------- ### Formatting Terms Source: https://www.rfc-editor.org/styleguide/part2 Authors have flexibility in formatting terms (capitalization, quotes, emphasis) but consistency within the document and the series is strongly recommended. ```text You may format terms as you see fit by using capitalization, quotation marks, emphasis, etc. However, consistency within the document and within the Series is strongly recommended. ``` -------------------------------- ### Inclusive Language Guidance Source: https://www.rfc-editor.org/styleguide/part2 Recommendation to follow the IESG statement on Inclusive Language and apply guidance from NIST documents, referencing a table for potentially biased language. ```APIDOC Because each stream has chosen to follow the [IESG statement on Inclusive Language](https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/), the RFC Editor encourages authors to apply the guidance described in [“Guidance for NIST Staff on Using Inclusive Language in Documentary Standards”](https://web.archive.org/web/20250203031433/https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8366.pdf). See [Table 1 on the NIST website](https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1) for an expanded list of potentially biased language along with possible substitutions. ``` -------------------------------- ### Referencing IANA Registries Source: https://www.rfc-editor.org/styleguide/part2 Format for referencing IANA registries, using the top-level URL for registry groups or specific registries. ```APIDOC [NAME] IANA, "Registry Group or Registry Name", . **Example for a registry group:** [IANA-ANCP] IANA, "Access Node Control Protocol (ANCP)", <>. **Example for a specific registry within the group:** [IANA] IANA, "ANCP Message Types", <>. ``` -------------------------------- ### Document Linking Best Practices Source: https://www.rfc-editor.org/styleguide/part2 Guidelines for document linking in RFCs, emphasizing usefulness, avoiding self-referential links, minimizing distraction, and ensuring descriptive link text for accessibility. ```text There is no hard limit on the number and frequency of links in documents. However, links introduce noise for people who use screen readers, and this reduces accessibility. How frequently terms should be linked is circumstantial depending on context and (often) the length of a section and the document. We consider the following when thinking about links: * The information at other end of link should be useful to the reader. * Links should not be self-referential (i.e., links should not link back to its own section/definition) * Links should not be distracting. At most, link every few paragraphs; perhaps once per section depending the length of the section. Links to the same term should not appear more than once per sentence, bullet, or paragraph. Linking to the same term repetitively frustrates the reader. * It should be clear to the reader where the link goes (i.e., the link text should be descriptive). ``` -------------------------------- ### RFC Citation Formatting Source: https://www.rfc-editor.org/styleguide/part2 Guidance on how to cite RFCs to avoid forming compounds by hyphenating RFC numbers, suggesting rewording or using a Terminology section. ```APIDOC Avoid forming compounds by hyphenating RFC numbers; this can be accomplished by * rewording the sentence (e.g., “[RFC5011]-style rollover” –> “rollover as described in RFC 5011 [RFC5011]”). * 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”). ``` -------------------------------- ### Section Length Suggestion Source: https://www.rfc-editor.org/styleguide/part2 A suggestion to limit the length of sections and subsections to facilitate easier referencing of objects within the document. ```text We suggest that the length of a section or subsection be limited to allow for easily referenced objects. ``` -------------------------------- ### In-text Citations (RFCs) Source: https://www.rfc-editor.org/styleguide/part2 Guidelines for in-text citations of RFCs, recommending consistent use of either silent pointers or reading citations as part of the text. ```APIDOC a) 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]. **or** b) Note that SAVI raises a number of important privacy considerations that are discussed more fully in [RFC6959]. We recommend using a) and strongly recommend consistent use of one style throughout. ``` -------------------------------- ### Referencing RFCs with DOI Source: https://www.rfc-editor.org/styleguide/part2 Format for referencing RFCs, including the Digital Object Identifier (DOI). This format is updated from RFC 7322. ```APIDOC [RFCXXXX] Last name, First initial., Ed. (if applicable), "RFC Title", Sub-series number (if applicable), RFC number, DOI, Date of publication, . **Example:** [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, DOI 10.17487/RFC3080, March 2001, . ``` -------------------------------- ### Referencing STDs and BCPs Source: https://www.rfc-editor.org/styleguide/part2 Guidance for referencing Internet Standards (STDs) and Best Current Practices (BCPs), which may comprise multiple RFCs. This overrides RFC 7322. ```APIDOC **STD Reference Format:** [STDXXX] Internet Standard XXX, . At the time of writing, this STD comprises the following: Last name, First initial., Ed. (if applicable), "RFC Title", STD XXX, RFC number, DOI number, Date of publication, . **Example:** [STD80] Internet Standard 80, . At the time of writing, this STD comprises the following: Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, **BCP Reference Format:** [BCPXXX] Best Current Practice XXX, . At the time of writing, this BCP comprises the following: Last name, First initial., Ed. (if applicable) and First initial. Last name, Ed. (if applicable), "RFC Title", BCP XXX, RFC number, DOI number, Date of publication, . ``` -------------------------------- ### Referencing Internet-Drafts Source: https://www.rfc-editor.org/styleguide/part2 Updated format for referencing Internet-Drafts, including the day of posting, 'Internet-Draft' text, and the HTML file URL. This is an update to RFC 7322, Section 4.8.6.4. ```APIDOC [RFC7322bis] Levine, J., Ed., and S. Ginoza, "RFC Style Guide", Work in Progress, Internet-Draft, draft-flanagan-7322bis-07, 7 April 2021, <>. ``` -------------------------------- ### Referencing Emails on Mailing Lists Source: https://www.rfc-editor.org/styleguide/part2 Template for referencing emails sent to mailing lists. Includes placeholders for sender, subject, list name, date, and URL. ```APIDOC [reftag] Sender, A., "Subject: Subject line", message to the listname mailing list, DD Month YYYY, . ``` -------------------------------- ### Referencing Errata Source: https://www.rfc-editor.org/styleguide/part2 Updated format for referencing errata, as described in RFC 7322, Section 4.8.6.5. Errata in the 'Reported' state should not be referenced. ```APIDOC [ErrNumber] RFC Errata, Erratum ID number, RFC number, . **Example:** [Err3607] RFC Errata, Erratum ID 3607, RFC 4627, . ``` -------------------------------- ### RFC 2119 Keywords in Quoted Text Source: https://www.rfc-editor.org/styleguide/part2 Guidance on when a reference is not required for RFC 2119 keywords when they appear solely within quoted text. ```text A reference is not required if the keywords are only used in quoted text. ``` -------------------------------- ### Referencing NIST FIPS Publications Source: https://www.rfc-editor.org/styleguide/part2 Template for referencing NIST Federal Information Processing Standards (FIPS) Publications. Includes placeholders for title, number, DOI, date, and URL. ```APIDOC [NIST_FIPS] NIST, "Title of FIPS Publication", NIST FIPS Number, DOI, Date of Publication, . **Example:** [NIST_FIPS_180_4] NIST, "Secure Hash Standard", NIST FIPS 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <>. ``` -------------------------------- ### Referencing NIST Special Publications (SPs) Source: https://www.rfc-editor.org/styleguide/part2 Template for referencing NIST Special Publications (SPs). Includes placeholders for authors, title, number, DOI, date, and URL. ```APIDOC [NIST_SP] Author(s), "Title of SP", NIST SP Number, DOI, Date of Publication, . **Example:** [NIST_SP_800-233] Chandramouli, R., Butcher, Z., and J. Callaghan, "Service Mesh Proxy Models for Cloud-Native Applications", NIST SP 800-233, DOI 10.6028/NIST.SP.800-233, October 2024, <>. ``` -------------------------------- ### Use of Non-ASCII Characters in RFCs Source: https://www.rfc-editor.org/styleguide/part2 Per RFC 7997, non-ASCII characters are permitted in the document body. The element is mandatory for non-ASCII characters essential for protocol operation. ASCII equivalents should be used for punctuation. ```text Per RFC 7997, non-ASCII characters may appear within the body of the document. The element is required for cases where the non-ASCII characters are needed for correct protocol operation. This is in keeping with the following statement (where “escaping” refers to using U+ notation or otherwise defining each character) in [Section 3.1 of RFC 7997](https://www.rfc-editor.org/rfc/rfc7997.html#section-3.1): “Where the use of non-ASCII characters is purely part of an example and not otherwise required for correct protocol operation, escaping the non-ASCII character is not required.” Note that ASCII equivalents are to be used for punctuation (e.g., smart quotes and em dashes). ``` -------------------------------- ### RFC Document Stream Phrasing Source: https://www.rfc-editor.org/styleguide/headers-and-boilerplate Defines the standard introductory and consensus-related sentences for the second paragraph of RFC documents, categorized by their respective streams. ```APIDOC RFC_Styleguide: Second_Paragraph: Experimental: Intro: "This document defines an Experimental Protocol for the Internet community." Historic: Intro: "This document defines a Historic Document for the Internet community." IETF_Stream: Intro: "This document is a product of the Internet Engineering Task Force (IETF)." Consensus_Present: Statement: "It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG)." No_Consensus: Statement: "It has been approved for publication by the Internet Engineering Steering Group (IESG)." BCP_or_Standard_Track: Reference: "Further information on [BCPs or Internet Standards] is available in Section 2 of RFC 7841." Other_Categories: Reference: "Not all documents approved by the IESG are candidates for any level of Internet Standards; see Section 2 of RFC 7841." IAB_Stream: Intro: "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." IAB_Consensus: Statement: "It represents the consensus of the Internet Architecture Board (IAB)." IRTF_Stream: Intro: "This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment." Consensus_Base_Example1: "This RFC represents the consensus of the Research Group of the Internet Research Task Force (IRTF)." Consensus_Base_Example2: "This RFC represents the individual opinion(s) of one or more members of the Research Group of the Internet Research Task Force (IRTF)" Independent_Submission_Stream: Intro: "This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment." Editorial_Stream: Intro: "This document is a product of the RFC Series Policy Definition Process. It represents the consensus of the RFC Series Working Group approved by the RFC Series Approval Board. Such documents are not candidates for any level of Internet Standard; see Section 2 of RFC 7841." Non_IETF_Stream_Reference: Statement: "Documents approved for publication by the [stream approver — currently, one of: \"IAB\", \"IRSG\", or \"RFC Editor\"] are not candidates for any level of Internet Standard; see Section 2 of RFC 7841." ``` -------------------------------- ### Status of this Memo - Experimental Category Text Source: https://www.rfc-editor.org/styleguide/headers-and-boilerplate Provides the specific text for the 'Status of this Memo' section when the RFC category is Experimental. ```text it is published for examination, experimental implementation, and evaluation. ``` -------------------------------- ### Status of this Memo - First Paragraph for Best Current Practices Source: https://www.rfc-editor.org/styleguide/headers-and-boilerplate Specifies the mandated text for the first paragraph of the 'Status of this Memo' section for 'Best Current Practices' documents. ```text This memo documents an Internet Best Current Practice. ``` -------------------------------- ### RFC Title Page Header Structure Source: https://www.rfc-editor.org/styleguide/headers-and-boilerplate Defines the format for an RFC title page header, including document source, author, RFC number, affiliations, subseries, relations, and publication date. ```text Request for Comments: [] [ ] [more author info as appropriate] [:] Category: ``` -------------------------------- ### Status of this Memo - First Paragraph for Other Categories Source: https://www.rfc-editor.org/styleguide/headers-and-boilerplate Specifies the mandated text for the first paragraph of the 'Status of this Memo' section for categories other than Standards Track or BCP. ```text This document is not an Internet Standards Track specification; . ``` -------------------------------- ### Status of this Memo - Informational Category Text Source: https://www.rfc-editor.org/styleguide/headers-and-boilerplate Provides the specific text for the 'Status of this Memo' section when the RFC category is Informational. ```text it is published for informational purposes. ``` -------------------------------- ### Status of this Memo - First Paragraph for Standards Track Source: https://www.rfc-editor.org/styleguide/headers-and-boilerplate Specifies the mandated text for the first paragraph of the 'Status of this Memo' section for 'Standards Track' documents. ```text This is an Internet Standards Track document. ``` -------------------------------- ### Status of this Memo - Historic Category Text Source: https://www.rfc-editor.org/styleguide/headers-and-boilerplate Provides the specific text for the 'Status of this Memo' section when the RFC category is Historic. ```text it is published for the historical record. ``` === COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.