RFC Headers and Boilerplate

Per RFC 9280, the RFC Production Center (RPC) is now maintaining the RFC boilerplates as part of the RFC Style Guide. Therefore, this page provides instructions for constructing header and boilerplate text for RFCs, as specified by RFC 7841. The boilerplate may be updated per the process described in RFC 9280.

1. RFC Title Page Header

An RFC title page header can be described as follows:

    <document source>                                          <author name>
    Request for Comments: <RFC number>                [<author affiliation>]
    [<subseries ID> <subseries number>]    [more author info as appropriate]
    [<RFC relation>:<RFC number[s]>]                            <month year>
    Category: <category>

For example, a sample earlier RFC header is as follows:

    Network Working Group                                          T. Dierks
    Request for Comments: 4346                                   Independent
    Obsoletes: 2246                                              E. Rescorla
    Category: Standards Track                                     RTFM, Inc.
                                                                  April 2006

2. Constructing a “Status of this Memo” Section

The following sections describe mandated text for use in specific parts of the “Status of this Memo” portion of an RFC. For convenience, expansions of all permutations of the paragraphs described in this document and RFC 9280 are available; see status memos. When in conflict, these following sections are authoritative.

2.1. First Paragraph

The following is the approved text for use in the first paragraph of the “Status of this Memo” portion of an RFC (see Section 3.3 of RFC 7841):

For ‘Standards Track’ documents: “This is an Internet Standards Track document.”

For ‘Best Current Practices’ documents: “This memo documents an Internet Best Current Practice.”

For other categories: “This document is not an Internet Standards Track specification; <it is published for other purposes>.”

For Informational, Experimental, Historic and future categories of RFCs, the RFC editor will maintain an appropriate text for <it is published for other purposes>. Initial values are:

Informational: “it is published for informational purposes.”

Historic: “it is published for the historical record.”

Experimental: “it is published for examination, experimental implementation, and evaluation.”

2.2. Second Paragraph

The second paragraph may include some text that is specific to the initial document category (see Section 3.4 of RFC 7841).

When a document is Experimental or Historic, the second paragraph opens with:

Experimental: “This document defines an Experimental Protocol for the Internet community.”

Historic: “This document defines a Historic Document for the Internet community.”

The text that follows is stream dependent. Initial values are listed below and may be amended by updates to stream-definition documents. Updates will be recorded on this page.

IETF Stream: “This document is a product of the Internet Engineering Task Force (IETF).”

If there has been an IETF consensus call per IETF process, this additional text should be added:

“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).”

If there has not been such a consensus call, then this simply reads:

“It has been approved for publication by the Internet Engineering Steering Group (IESG).”

IAB Stream: “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.”

If the document represents IAB consensus, this additional text should be added:

“It represents the consensus of the Internet Architecture Board (IAB).”

IRTF Stream: “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.”

In addition, a sentence indicating the consensus base within the IRTF may be added:

“This RFC represents the consensus of the <insert_name> Research Group of the Internet Research Task Force (IRTF).”

or alternatively:

“This RFC represents the individual opinion(s) of one or more members of the <insert_name> Research Group of the Internet Research Task Force (IRTF)”.

Independent Submission Stream: “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 (as defined by Section 6.3 of RFC 9280): “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.”

For non-IETF stream documents a reference to Section 2 of RFC 7841 is added with the following sentence:

“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.”

For IETF stream documents a similar reference is added:

“Further information on [BCPs or Internet Standards] is available in Section 2 of RFC 7841.” for BCP and Standard Track documents; “Not all documents approved by the IESG are candidates for any level of Internet Standards; see Section 2 of RFC 7841.” for all other categories.

2.3. Third Paragraph

As defined in Section 3.5 of RFC 7841, the third paragraph includes a reference to where further relevant information can be found. The current text is as follows:

“Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfcXXXX.


Advanced Search