RFC 8174

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words

📅 published May 2017, from ietf

RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 💖

Okay bestie, here's the title block tea ☕

  • Stream: Internet Engineering Task Force (IETF) 🌸
  • Who wrote it: Barry Leiba, from Huawei Technologies 🧚
  • Date: May 2017 📅
  • Category: Best Current Practice (it's also BCP 14, so it's a big deal 👑)
  • Updates: RFC 2119 🔧
  • ISSN: 2070-1721

Abstract

RFC 2119 gives us a set of common key words for protocol specs. This doc clears up the confusion by making it super clear that only UPPERCASE usage of those key words gets the 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 💜

Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc8174 🦋

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) as in effect on the date of publication of this document. Please review these documents carefully, because 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 they 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 gives us common key words, like "MUST", "SHOULD", and "MAY", that you can use in protocol specs. It says the key words "are often capitalized," and that caused a lot of confusion about how to read non-capitalized words like "must" and "should" 🙈

So this document updates RFC 2119 by making it crystal clear that only UPPERCASE usage of the key words has the defined special meanings. This document is part of BCP 14 💖

2. Clarifying Capitalization of Key Words 🎀

Here's the tweak being 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 ===

3. IANA Considerations 🧚

This document does not require any IANA actions 🌈

4. Security Considerations 💀

Plot twist: this one is purely procedural, so there are no related security considerations. Nothing to panic about 😌🫶

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,
           <http://www.rfc-editor.org/info/rfc2119>.

Author's Address 🖋️

Barry Leiba
Huawei Technologies

Phone: +1 646 827 0648
Email: barryleiba@computer.org
URI:   http://internetmessagingtechnology.org/
📦 where this page comes from