An RFC for Testing RFC Publication Using Purple RFC Production Center
jmahoney@staff.rfc-editor.org www.rfc-editor.org
General Internet Engineering Task Force Purple Red rfcpa technical debt This document is to test Purple and Red publication functionality. It updates RFC 9110 and obsoletes RFC 3261. It makes RFC 7991 historic. It is a Best Current Practice.
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 Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice Copyright (c) 2025 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 () 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents
  • .  Introduction
    • .  Requirements Language
  • .  Body [REPLACE]
  • .  IANA Considerations
  • .  Security Considerations
  • .  References
    • .  Normative References
    • .  Informative References
  • .  Appendix 1 [REPLACE/DELETE]
  • Acknowledgements
  • Contributors
  • Author's Address
Introduction Introductory text [REPLACE]
Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
Body [REPLACE] Body text [REPLACE] To use a cite tag, see and .
  1. Ordered list item [REPLACE/DELETE]
  • Bulleted list item [REPLACE/DELETE]
First term: [REPLACE/DELETE]
Definition of the first term [REPLACE/DELETE]
Second term: [REPLACE/DELETE]
Definition of the second term [REPLACE/DELETE]
Column 1 [REPLACE]
Cell [REPLACE]
Source [REPLACE] source code goes here [REPLACE]
Diagram [REPLACE] ------------- art -------------
IANA Considerations This memo includes no request to IANA. [CHECK]
Security Considerations This document should not affect the security of the Internet. [CHECK]
References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Title [REPLACE] Title [REPLACE] Organization [REPLACE]
Appendix 1 [REPLACE/DELETE] This becomes an Appendix [REPLACE]
Acknowledgements This template uses extracts from templates written by Pekka Savola, Elwyn Davies and Henrik Levkowetz. [REPLACE]
Contributors Thanks to all of the contributors. [REPLACE]
Author's Address RFC Production Center
jmahoney@staff.rfc-editor.org www.rfc-editor.org