This page holds the current IAB approved instructions for constructing header and boilerplate text for RFCs, as specified by RFC 7841.
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]>] Category: <category> <month year>
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, the RFC Editor maintains example expansions of all permutations of the paragraphs described in this document (at the time of publication, at http://www.rfc-editor.org/materials/status-memos.txt). When in conflict, these following sections are authoritative.
2.1. First Paragraph
The following are the approved texts for use in the first paragraph of the “Status of this Memo” portion of an RFC. See RFC 7841 section 3.3.
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
See RFC 7841 section 3.4.
The second paragraph may include some text that is specific to the initial document category, as follows: 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 — these are initial values and may be updated by stream definition document updates and recorded by the IAB 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.
For non-IETF stream documents a reference to Section 2 of this RFC 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
See RFC 7841 section 3.5.