RFC 2119

Key words for use in RFCs to Indicate Requirement Levels 🎀

okay so before we get into it, here's the lineup 🫶

• RFC number: 2119
• Title: Key words for use in RFCs to Indicate Requirement Levels
• Author: S. Bradner, Harvard University
• Date: March 1997
• Category: Best Current Practice (BCP: 14) 🦋
• Obsoletes / Updates: nothing listed in the title block, so it doesn't obsolete or update anything 💅

---

Status of this Memo ✨

this doc is an Internet Best Current Practice for the Internet Community, and it's literally asking for discussion and suggestions to make it better 🌸 distribution of this memo is unlimited, so share it with everyone 🧚

Abstract 💖

so in lots of standards track docs, people use a handful of words to show what's required in the spec, and they usually capitalize them so you can spot them 👀 this doc says exactly how those words should be read in IETF documents. if you're an author who wants to follow these guidelines, put this line near the top of your doc:

   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.

and one more thing 🔥 the force of these words depends on the requirement level of the document they show up in, so the same word can hit different depending on where it lives 💅

1. MUST ✨

"MUST", or "REQUIRED" or "SHALL", means the definition is an absolute requirement of the spec. no wiggle room, no cap 💜

2. MUST NOT 🙈

"MUST NOT", or "SHALL NOT", means the definition is an absolute prohibition of the spec. full stop, don't do it 💀

3. SHOULD 🌈

"SHOULD", or the adjective "RECOMMENDED", means there may be valid reasons in particular circumstances to ignore a particular item. but the full implications must be understood and carefully weighed before you pick a different path 🧚

4. SHOULD NOT 🍓

"SHOULD NOT", or "NOT RECOMMENDED", means there may be valid reasons in particular circumstances where the behavior is acceptable or even useful. but the full implications should be understood and the case carefully weighed before you implement any behavior with this label 🫶

5. MAY 🦋

"MAY", or the adjective "OPTIONAL", means an item is truly optional 🌸 one vendor may include it because a marketplace needs it or because they think it makes the product better, while another vendor may skip the same item, and that's totally fine ✨

an implementation that doesn't include a particular option MUST be prepared to interoperate with another implementation that does include the option, though maybe with reduced functionality 🎀 and in the same vein, an implementation that does include a particular option MUST be prepared to interoperate with another implementation that does not include the option (except, of course, for the feature the option provides.) it's a two-way street, bestie 👑

6. Guidance in the use of these Imperatives 💅

okay this part is giving responsibility 😭 imperatives of the type defined in this memo must be used with care and sparingly. they MUST only be used where it is actually required for interoperation or to limit behavior that has potential for causing harm (e.g., limiting retransmisssions) for example, they must not be used to try to impose a particular method on implementors when that method isn't required for interoperability 🙈

don't use these words as a power move to boss implementors around. only use them when it's really needed for things to work together or to stop something harmful 🚫

7. Security Considerations 💀

not gonna lie, this section is serious and I'm here for it 😭 these terms are frequently used to specify behavior with security implications. the effects on security of not implementing a MUST or SHOULD, or of doing something the spec says MUST NOT or SHOULD NOT be done, can be very subtle 🔥 document authors should take the time to spell out the security implications of not following recommendations or requirements, because most implementors won't have had the benefit of the experience and discussion that produced the spec. so please, explain the stakes 🫶

8. Acknowledgments 🌸

the definitions here are an amalgam of definitions taken from a bunch of RFCs. and a bunch of people helped out with suggestions, including Robert Ullmann, Thomas Narten, Neal McBurnett, and Robert Elz 🧚💖

9. Author's Address 🎀

   Scott Bradner
   Harvard University
   1350 Mass. Ave.
   Cambridge, MA 02138

   phone - +1 617 495 3864

   email - sob@harvard.edu