Internet Architecture Board (IAB) J. Halpern, Ed.
+Request for Comments: 7841 L. Daigle, Ed.
+Obsoletes: 5741 O. Kolkman, Ed.
+Category: Informational May 2016
+ISSN: 2070-1721
+
+
+ RFC Streams, Headers, and Boilerplates
+
+Abstract
+
+ RFC documents contain a number of fixed elements such as the title
+ page header, standard boilerplates, and copyright/IPR statements.
+ This document describes them and introduces some updates to reflect
+ current usage and requirements of RFC publication. In particular,
+ this updated structure is intended to communicate clearly the source
+ of RFC creation and review. This document obsoletes RFC 5741, moving
+ detailed content to an IAB web page and preparing for more flexible
+ output formats.
+
+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/rfc7841.
+
+Copyright Notice
+
+ Copyright (c) 2016 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.
+
+
+
+
+Halpern, et al. Informational [Page 1]
+
+RFC 7841 RFC Streams, Headers, Boilerplates May 2016
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. RFC Streams and Internet Standards . . . . . . . . . . . . . 3
+ 3. RFC Structural Elements . . . . . . . . . . . . . . . . . . . 3
+ 3.1. The Title Page Header . . . . . . . . . . . . . . . . . . 4
+ 3.2. The Status of This Memo . . . . . . . . . . . . . . . . . 5
+ 3.3. Paragraph 1 . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.4. Paragraph 2 . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.5. Paragraph 3 . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.6. Noteworthy . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4. Additional Notes . . . . . . . . . . . . . . . . . . . . . . 6
+ 5. Other Structural Information in RFCs . . . . . . . . . . . . 6
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
+ 7. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 7
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 7
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 7
+ Appendix A. Initial Formatting Details . . . . . . . . . . . . . 10
+ A.1. RFC Title Page Header . . . . . . . . . . . . . . . . . . 10
+ A.2. Constructing a "Status of This Memo" Section . . . . . . 10
+ A.2.1. First Paragraph . . . . . . . . . . . . . . . . . . . 11
+ A.2.2. Second Paragraph . . . . . . . . . . . . . . . . . . 11
+ A.2.3. Third Paragraph . . . . . . . . . . . . . . . . . . . 13
+ IAB Members at Time of Approval . . . . . . . . . . . . . . . . . 13
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
+
+1. Introduction
+
+ Previously, RFCs (e.g., [RFC4844]) contained a number of elements
+ that were there for historical, practical, and legal reasons. They
+ also contained boilerplate material to clearly indicate the status of
+ the document and possibly contained "Notes" to indicate how the
+ document interacts with IETF Standards-Track documents.
+
+ As the RFC Series has evolved over the years, there has been
+ increasing concern over appropriate labeling of the publications to
+ make clear the status of each RFC and the status of the work it
+ describes. Chiefly, there is a requirement that RFCs published as
+ part of the IETF's review process not be easily confused with RFCs
+ that may have had a very different review and approval process.
+ Various adjustments have been made over the years, including evolving
+ text of "Notes" included in the published RFC.
+
+ With the definition of the different RFC streams [RFC4844], it is
+ appropriate to formalize the definition of the various pieces of
+ standard RFC boilerplate and introduce some adjustments to ensure
+
+
+
+Halpern, et al. Informational [Page 2]
+
+RFC 7841 RFC Streams, Headers, Boilerplates May 2016
+
+
+ better clarity of expression of document status, aligned with the
+ review and approval processes defined for each stream.
+
+ This memo identifies and describes the common elements of RFC
+ boilerplate structure. It describes the content required for each
+ kind of information. Details of the exact textual and layout
+ requirements are left to a web page maintained by the IAB, with due
+ consultation with the community, for ease of maintenance. This
+ document obsoletes [RFC5741].
+
+ The changes introduced by this memo should be implemented as soon as
+ practically possible after the document has been approved for
+ publication.
+
+2. RFC Streams and Internet Standards
+
+ Users of RFCs should be aware that while all Internet Standards-
+ related documents are published as RFCs, not all RFCs are Internet
+ Standards-related documents.
+
+ The IETF is responsible for maintaining the Internet Standards
+ Process, which includes the requirements for developing, reviewing,
+ and approving Standards Track and BCP RFCs. The IETF also produces
+ non-Standards-Track documents (Informational, Experimental, and
+ Historic). All documents published as part of the IETF Stream are
+ reviewed by the appropriate IETF bodies.
+
+ Documents published in streams other than the IETF stream are not
+ generally reviewed by the IETF for such things as security,
+ congestion control, or inappropriate interaction with deployed
+ protocols. They have also not been subject to approval by the
+ Internet Engineering Steering Group (IESG), including an IETF-wide
+ last call. Therefore, the IETF disclaims, for any of the non-IETF
+ stream documents, any knowledge of the fitness of those RFCs for any
+ purpose.
+
+ Refer to [RFC2026], [RFC5742], [RFC4844], [RFC6410], and [RFC7127]
+ and their successors for current details of the IETF process and RFC
+ streams.
+
+3. RFC Structural Elements
+
+ This section describes the elements that are commonly found in RFCs
+ published today. This document specifies information that is
+ required in these publications. Exact specification of the textual
+ values required therein are provided by an IAB web page
+ (https://www.iab.org/documents/headers-boilerplate).
+
+
+
+
+Halpern, et al. Informational [Page 3]
+
+RFC 7841 RFC Streams, Headers, Boilerplates May 2016
+
+
+ As noted above, this web page is maintained by the IAB with due
+ consultation with the community. Following such consultation, if the
+ IAB decides to make any changes to this material, the changes will be
+ announced in a similar fashion to other IAB statements. The initial
+ text to be used in that web page is included in Appendix A.
+
+3.1. The Title Page Header
+
+ The information at the front of the RFC includes the name and
+ affiliation of the authors as well as the RFC publication month and
+ year.
+
+ There is a set of additional information that is needed at the front
+ of the RFC. Historically, this has been presented with the
+ information below in a left hand column, and the author-related
+ information described above in the right.
+
+ <document source> This describes the area where the work originates.
+ Historically, all RFCs were labeled "Network Working Group".
+ Network Working Group refers to the original version of today's
+ IETF when people from the original set of ARPANET sites and
+ whomever else was interested -- the meetings were open -- got
+ together to discuss, design, and document proposed protocols
+ [RFC3]. Here, we obsolete the term "Network Working Group" in
+ order to indicate the originating stream.
+
+ The <document source> is the name of the RFC stream, as defined in
+ [RFC4844] and its successors. At the time of this publication,
+ the streams, and therefore the possible entries are:
+
+ * Internet Engineering Task Force
+ * Internet Architecture Board
+ * Internet Research Task Force
+ * Independent Submission
+
+ Request for Comments: <RFC number> This indicates the RFC number,
+ assigned by the RFC Editor upon publication of the document. This
+ element is unchanged.
+
+ <subseries ID> <subseries number> Some document categories are also
+ labeled as a subseries of RFCs. These elements appear as
+ appropriate for such categories, indicating the subseries and the
+ documents number within that series. Currently, there are
+ subseries for BCPs [RFC2026] and STDs [RFC1311]. These subseries
+ numbers may appear in several RFCs. For example, when a new RFC
+ obsoletes or updates an old one, the same subseries number is
+ used. Also, several RFCs may be assigned the same subseries
+ number: a single STD, for example, may be composed of several
+
+
+
+Halpern, et al. Informational [Page 4]
+
+RFC 7841 RFC Streams, Headers, Boilerplates May 2016
+
+
+ RFCs, each of which will bear the same STD number. This element
+ is unchanged.
+
+ [<RFC relation>:<RFC number[s]>] Some relations between RFCs in the
+ series are explicitly noted in the RFC header. For example, a new
+ RFC may update one or more earlier RFCs. Currently two
+ relationships are defined: "Updates" and "Obsoletes" [RFC7322].
+ Variants like "Obsoleted by" are also used (e.g, in [RFC5143]).
+ Other types of relationships may be defined by the RFC Editor and
+ may appear in future RFCs.
+
+ Category: <category> This indicates the initial RFC document
+ category of the publication. These are defined in [RFC2026].
+ Currently, this is always one of: Standards Track, Best Current
+ Practice, Experimental, Informational, or Historic. This element
+ is unchanged.
+
+3.2. The Status of This Memo
+
+ The "Status of This Memo" describes the category of the RFC,
+ including the distribution statement.
+
+ The "Status of This Memo" will start with a single sentence
+ describing the status. It will also include a statement describing
+ the stream-specific review of the material (which is stream
+ dependent). This is an important component of status, insofar as it
+ clarifies the breadth and depth of review, and gives the reader an
+ understanding of how to consider its content.
+
+3.3. Paragraph 1
+
+ The first paragraph of the "Status of This Memo" section contains a
+ single sentence, clearly standing out. The sentence will clearly
+ identify the stream-specific status of the document. The text to be
+ used is defined by the stream, with a review for clarity by the IAB
+ and RFC Series Editor.
+
+3.4. Paragraph 2
+
+ The second paragraph of the "Status of This Memo" will include a
+ paragraph describing the type of review and exposure the document has
+ received. This is defined on a per-stream basis, subject to general
+ review and oversight by the RFC Editor and IAB. The IAB defines a
+ specific structure defined to ensure there is clarity about review
+ processes and document types.
+
+
+
+
+
+
+Halpern, et al. Informational [Page 5]
+
+RFC 7841 RFC Streams, Headers, Boilerplates May 2016
+
+
+3.5. Paragraph 3
+
+ The boilerplate ends with a reference to where further relevant
+ information can be found. This information may include, subject to
+ the RFC Editor's discretion, information about whether the RFC has
+ been updated or obsoleted, the RFC's origin, a listing of possible
+ errata, information about how to provide feedback and suggestion, and
+ information on how to submit errata as described in [ERRATA]. The
+ exact wording and URL is subject to change (at the RFC Editor's
+ discretion), but the current text is:
+
+ 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/<static-path>/rfc<rfc-no>.
+
+3.6. Noteworthy
+
+ Note that the text in paragraph 1 and 2 of the boilerplate indicate
+ the initial status of a document. During their lifetime, documents
+ can change status to, for example, Historic. This cannot be
+ reflected in the document itself and will need be reflected in the
+ information referred to in Section 5.
+
+4. Additional Notes
+
+ Exceptionally, a review and publication process may prescribe
+ additional notes that will appear as labeled notes after the
+ "Abstract".
+
+ This is no longer a common feature of recent RFCs. It is the goal of
+ this document to continue to ensure that the overall RFC structure is
+ adequately clear so that such notes are unnecessary or (at least)
+ truly exceptional.
+
+5. Other Structural Information in RFCs
+
+ RFCs contain other structural informational elements. The RFC Editor
+ is responsible for the positioning and layout of these structural
+ elements. Note also that new elements may be introduced or obsoleted
+ using a process consistent with [RFC4844]. These additions may or
+ may not require documentation in an RFC.
+
+ Currently, the following structural information is available in RFCs:
+
+ Copyright Notice: A copyright notice with a reference to BCP 78
+ [BCP78] and an Intellectual Property statement referring to BCP 78
+ and BCP 79 [BCP79]. The content of these statements are defined
+ by those BCPs.
+
+
+
+Halpern, et al. Informational [Page 6]
+
+RFC 7841 RFC Streams, Headers, Boilerplates May 2016
+
+
+ ISSN: The International Standard Serial Number [ISO.3297.2007]:
+ ISSN 2070-1721. The ISSN uniquely identifies the RFC series as
+ title regardless of language or country in which it is published.
+ The ISSN itself has no significance other than the unique
+ identification of a serial publication.
+
+6. Security Considerations
+
+ This document tries to clarify the descriptions of the status of an
+ RFC. Misunderstanding the status of a memo could cause
+ interoperability problems, hence security and stability problems.
+
+7. RFC Editor Considerations
+
+ The RFC Editor is responsible for maintaining the consistency of the
+ RFC series. To that end, the RFC Editor maintains an "RFC Style
+ Guide" [RFC7322]. In this memo, we mention a few explicit structural
+ elements that the RFC Editor needs to maintain. The conventions for
+ the content and use of all current and future elements are documented
+ in the style guide.
+
+ Adding a reference to the stream in the header of RFCs is only one
+ method for clarifying from which stream an RFC originated. The RFC
+ Editor is encouraged to add such indication in, for example, indices
+ and interfaces.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
+ <http://www.rfc-editor.org/info/rfc2026>.
+
+ [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for
+ Handling of Independent and IRTF Stream Submissions",
+ BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009,
+ <http://www.rfc-editor.org/info/rfc5742>.
+
+8.2. Informative References
+
+ [ISO.3297.2007]
+ Technical Committee ISO/TC 46, Information and
+ documentation, Subcommittee SC 9, Identification and
+ description., "Information and documentation -
+ International standard serial number (ISSN)", ISO Standard
+ 3297, 09 2007.
+
+
+
+
+Halpern, et al. Informational [Page 7]
+
+RFC 7841 RFC Streams, Headers, Boilerplates May 2016
+
+
+ [RFC3] Crocker, S., "Documentation conventions", RFC 3,
+ DOI 10.17487/RFC0003, April 1969,
+ <http://www.rfc-editor.org/info/rfc3>.
+
+ [RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311,
+ DOI 10.17487/RFC1311, March 1992,
+ <http://www.rfc-editor.org/info/rfc1311>.
+
+ [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC
+ Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
+ July 2007, <http://www.rfc-editor.org/info/rfc4844>.
+
+ [RFC5143] Malis, A., Brayley, J., Shirron, J., Martini, L., and S.
+ Vogelsang, "Synchronous Optical Network/Synchronous
+ Digital Hierarchy (SONET/SDH) Circuit Emulation Service
+ over MPLS (CEM) Encapsulation", RFC 5143,
+ DOI 10.17487/RFC5143, February 2008,
+ <http://www.rfc-editor.org/info/rfc5143>.
+
+ [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams,
+ Headers, and Boilerplates", RFC 5741,
+ DOI 10.17487/RFC5741, December 2009,
+ <http://www.rfc-editor.org/info/rfc5741>.
+
+ [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the
+ Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
+ DOI 10.17487/RFC6410, October 2011,
+ <http://www.rfc-editor.org/info/rfc6410>.
+
+ [RFC7127] Kolkman, O., Bradner, S., and S. Turner, "Characterization
+ of Proposed Standards", BCP 9, RFC 7127,
+ DOI 10.17487/RFC7127, January 2014,
+ <http://www.rfc-editor.org/info/rfc7127>.
+
+ [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
+ DOI 10.17487/RFC7322, September 2014,
+ <http://www.rfc-editor.org/info/rfc7322>.
+
+ [ERRATA] Hagens, A., Ginoza, S., and R. Braden, "RFC Editor
+ Proposal for Handling RFC Errata", Work in Progress,
+ draft-rfc-editor-errata-process-02, May 2008.
+
+ [BCP78] Bradner, S., Ed. and J. Contreras, Ed., "Rights
+ Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
+ November 2008, <http://www.rfc-editor.org/info/bcp78>.
+
+
+
+
+
+
+Halpern, et al. Informational [Page 8]
+
+RFC 7841 RFC Streams, Headers, Boilerplates May 2016
+
+
+ [BCP79] Bradner, S., Ed., "Intellectual Property Rights in IETF
+ Technology", BCP 79, RFC 3979, DOI 10.17487/RFC3979, March
+ 2005.
+
+ Narten, T., "Clarification of the Third Party Disclosure
+ Procedure in RFC 3979", BCP 79, RFC 4879,
+ DOI 10.17487/RFC4879, April 2007.
+
+ <http://www.rfc-editor.org/info/bcp79>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Halpern, et al. Informational [Page 9]
+
+RFC 7841 RFC Streams, Headers, Boilerplates May 2016
+
+
+Appendix A. Initial Formatting Details
+
+ This section contains the text the IAB used to initially populate the
+ web page used to maintain the list of required verbiage.
+
+A.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, the header for RFC 6410 appears as follows:
+
+------------------------------------------------------------------------
+
+Internet Engineering Task Force (IETF) R. Housley
+Request for Comments: 6410 Vigil Security
+BCP: 9 D. Crocker
+Updates: 2026 Brandenburg InternetWorking
+Category: Best Current Practice E. Burger
+ISSN: 2070-1721 Georgetown University
+ October 2011
+
+------------------------------------------------------------------------
+
+A.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, the following sections are
+ authoritative.
+
+
+
+
+
+
+
+
+
+Halpern, et al. Informational [Page 10]
+
+RFC 7841 RFC Streams, Headers, Boilerplates May 2016
+
+
+A.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 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."
+
+A.2.2. Second Paragraph
+
+ See Section 3.4 of RFC 7841.
+
+ The second paragraph may include some text that is specific to the
+ initial document category. 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."
+
+
+
+
+
+
+
+
+
+
+
+
+Halpern, et al. Informational [Page 11]
+
+RFC 7841 RFC Streams, Headers, Boilerplates May 2016
+
+
+ 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 the web 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 a candidate for any level of
+ Internet Standard; see Section 2 of RFC 7841."
+
+
+
+
+
+
+Halpern, et al. Informational [Page 12]
+
+RFC 7841 RFC Streams, Headers, Boilerplates May 2016
+
+
+ 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 a candidate for any level of
+ Internet Standards; see Section 2 of RFC 7841." for all other
+ categories.
+
+A.2.3. Third Paragraph
+
+ See Section 3.5 of RFC 7841.
+
+IAB Members at Time of Approval
+
+ The IAB members at the time this memo was approved were (in
+ alphabetical order):
+
+ Jari Arkko
+ Mary Barnes
+ Marc Blanchet
+ Ralph Droms
+ Ted Hardie
+ Joe Hildebrand
+ Russ Housley
+ Erik Nordmark
+ Robert Sparks
+ Andrew Sullivan
+ Dave Thaler
+ Brian Trammell
+ Suzanne Woolf
+
+Acknowledgements
+
+ Thanks to Bob Braden, Brian Carpenter, Steve Crocker, Sandy Ginoza,
+ and John Klensin who provided background information and inspiration.
+
+ Thanks to the members of the RFC Series Oversight Committee (RSOC)
+ for assistance and review: Alexey Melnikov, Nevil Brownlee, Bob
+ Hinden, Sarah Banks, Robert Sparks, Tony Hansen, and Joe Hildebrand.
+
+ Various people have made suggestions that improved the document.
+ Among them are: Lars Eggert, Alfred Hoenes, and Joe Touch.
+
+
+
+
+
+
+
+
+
+
+Halpern, et al. Informational [Page 13]
+
+RFC 7841 RFC Streams, Headers, Boilerplates May 2016
+
+
+Authors' Addresses
+
+ Joel M. Halpern (editor)
+
+ Email: jmh@joelhalpern.com
+
+
+ Leslie Daigle (editor)
+
+ Email: ldaigle@thinkingcat.com
+
+
+ Olaf M. Kolkman (editor)
+
+ Email: kolkman@isoc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Halpern, et al. Informational [Page 14]
+
+ 
+
+
+
+
+
+