From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8174.txt | 227 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 doc/rfc/rfc8174.txt (limited to 'doc/rfc/rfc8174.txt') diff --git a/doc/rfc/rfc8174.txt b/doc/rfc/rfc8174.txt new file mode 100644 index 0000000..b7f2036 --- /dev/null +++ b/doc/rfc/rfc8174.txt @@ -0,0 +1,227 @@ + + + + + + +Internet Engineering Task Force (IETF) B. Leiba +Request for Comments: 8174 Huawei Technologies +BCP: 14 May 2017 +Updates: 2119 +Category: Best Current Practice +ISSN: 2070-1721 + + + Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words + +Abstract + + 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. + +Status of This Memo + + This memo documents an Internet Best Current Practice. + + This document is a product of the Internet Engineering Task Force + (IETF). 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). Further information on + BCPs is available in 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 + http://www.rfc-editor.org/info/rfc8174. + + + + + + + + + + + + + + + + + + + + + +Leiba Best Current Practice [Page 1] + +RFC 8174 RFC 2119 Clarification May 2017 + + +Copyright Notice + + Copyright (c) 2017 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. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Clarifying Capitalization of Key Words . . . . . . . . . . . 3 + 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 + 5. Normative References . . . . . . . . . . . . . . . . . . . . 4 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 + +1. Introduction + + RFC 2119 specifies common key words, such as "MUST", "SHOULD", and + "MAY", that may be used in protocol specifications. It says that the + key words "are often capitalized," which has caused confusion about + how to interpret non-capitalized words such as "must" and "should". + + This document updates RFC 2119 by clarifying that only UPPERCASE + usage of the key words have the defined special meanings. This + document is part of BCP 14. + + + + + + + + + + + + + + + + + +Leiba Best Current Practice [Page 2] + +RFC 8174 RFC 2119 Clarification May 2017 + + +2. Clarifying Capitalization of Key Words + + The following change is made to [RFC2119]: + + === OLD === + 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. Authors who follow these guidelines + should incorporate this phrase near the beginning of their document: + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. + + + === NEW === + In many IETF documents, several words, when they are in all capitals + as shown below, are used to signify the requirements in the + specification. These capitalized words can bring significant clarity + and consistency to documents because their meanings are well defined. + This document defines how those words are interpreted in IETF + documents when the words are in all capitals. + + o These words can be used as defined here, but using them is not + required. Specifically, normative text does not require the use + of these key words. They are used for clarity and consistency + when that is what's wanted, but a lot of normative text does not + use them and is still normative. + + o The words have the meanings specified herein only when they are in + all capitals. + + o When these words are not capitalized, they have their normal + English meanings and are not affected by this document. + + Authors who follow these guidelines should incorporate this phrase + near the beginning of their document: + + 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 [RFC2119] [RFC8174] when, and only when, they + appear in all capitals, as shown here. + + === END === + + + + + +Leiba Best Current Practice [Page 3] + +RFC 8174 RFC 2119 Clarification May 2017 + + +3. IANA Considerations + + This document does not require any IANA actions. + +4. Security Considerations + + This document is purely procedural; there are no related security + considerations. + +5. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + +Author's Address + + Barry Leiba + Huawei Technologies + + Phone: +1 646 827 0648 + Email: barryleiba@computer.org + URI: http://internetmessagingtechnology.org/ + + + + + + + + + + + + + + + + + + + + + + + + + + + +Leiba Best Current Practice [Page 4] + -- cgit v1.2.3