rfc·explained

RFC 2119 · · Best Current Practice

MUST, SHOULD and MAY, defined once and for all.

The official title is "Key words for use in RFCs to Indicate Requirement Levels." What it actually decides: that when a spec writes MUST, SHOULD or MAY in capitals, those words carry an exact, agreed meaning instead of the usual English fuzz.

Status
✓ Still current
Also known as
BCP 14
Updated by
RFC 8174

Written by Noel Lang · IT trainer

TL;DR

RFC 2119 is the dictionary every other RFC is written with. It pins down three requirement levels: MUST (absolute, no exceptions), SHOULD (do it unless you can justify not to) and MAY (genuinely optional), plus their negatives and a few synonyms. Published as BCP 14 and updated by RFC 8174, which added the rule that only the capitalised words are binding.

The problem it solves

Ordinary English is too vague for a protocol. If a spec says an implementation “should” verify a signature, does that mean it has to, or that it would be nice if it did? Two vendors can read the same sentence, build to opposite conclusions, and ship products that refuse to talk to each other. That defeats the entire point of a standard.

RFC 2119 removes the guesswork with a tiny, fixed vocabulary. Once everyone agrees that MUST is absolute, SHOULD is a recommendation with a documented escape hatch, and MAY is truly optional, a spec can be read the same way by every implementer on earth. It is three pages long and quietly load-bearing for the whole standards ecosystem.

The building-code analogy

Think of a specification as a building code, because building codes already speak in exactly these three tones. Some rules are the law: a fire exit is not negotiable, and an inspector who finds none fails you on the spot. That is MUST. Some rules are strong professional guidance: smoke alarms belong near the bedrooms, and you may deviate only if you can point to a real reason and show you thought it through. That is SHOULD. And some choices are simply yours: paint the walls any color you like. That is MAY.

The value of the code is not that it lists rules. It is that everyone reading it knows, at a glance, which tone each rule is written in. RFC 2119 gives spec writers those three tones and gives readers the legend for them.

The three requirement levels

One vocabulary, three strengths of obligation. Everything else in RFC 2119 is a synonym or a negative of these:

  • MUST · MUST NOT REQUIRED · SHALL · SHALL NOT

    Absolute. No judgement allowed. To conform, you do it (or never do it). Break a MUST and your implementation is simply non-conforming. Everyday version: a building MUST have a fire exit. The inspector does not care how nice your reasons are.

  • SHOULD · SHOULD NOT RECOMMENDED · NOT RECOMMENDED

    Do it, unless you can justify not doing it. The default is yes; deviating is allowed only after you understand and weigh the full consequences. Everyday version: smoke alarms SHOULD sit near the bedrooms. You may place them elsewhere, but you had better have a documented reason.

  • MAY OPTIONAL

    Genuinely your choice. Including it and omitting it are both fully conforming. One vendor ships it, another skips it, and neither is wrong. Everyday version: you MAY paint the walls any color. Nobody will ever fail you for it.

Bar length ≈ how binding the level is, from absolute (MUST) down to fully optional (MAY).

The SHOULD that trips everyone up

If you remember one thing, remember this: SHOULD does not mean optional. It is the most misread word in the whole vocabulary. SHOULD means “do it, unless you genuinely cannot, and if you cannot, you had better understand exactly what you are giving up.” The RFC spells it out: valid reasons to ignore a SHOULD may exist in particular circumstances, but the full implications must be understood and carefully weighed before choosing another path.

So SHOULD sits between two very different words. Above it, MUST leaves no room at all. Below it, MAY hands you a free choice with no justification required. SHOULD is the middle: a default yes that you are allowed to override, on the record, with your eyes open. Treat a SHOULD as “nice to have” and you will quietly build something the spec’s authors expected you not to.

The 2017 fine print: only capitals count

For twenty years RFC 2119 had a gap. It never actually said what happens when a document uses the word “must” in lowercase, in an ordinary sentence, with no normative intent. Pedants argued. In May 2017 RFC 8174 closed the hole with a single rule: the keywords carry their special meaning only when they appear in all capitals. A lowercase “must” is just English.

Since then, the two documents together form BCP 14, and you cannot cite one correctly without the other. You can spot a spec that follows them by its boilerplate, a near-identical paragraph that reads: “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.” When you see that line, every capitalised keyword below it is a promise. Everything in lowercase is just prose.

What the RFC actually says

The whole document is three pages, and most of it is the vocabulary itself. The map, in case you visit:

Section In plain words
1–5 · The definitions One numbered section per keyword: MUST, MUST NOT, SHOULD, SHOULD NOT, MAY. This is the entire dictionary, and it fits on a single page.
6 · Guidance A plea for restraint: use these imperatives sparingly, only where genuinely needed for interoperability or to prevent harm. Not every sentence deserves a MUST.
7 · Security A short reminder that requirement levels have security weight: a careless SHOULD where a MUST belongs can leave a real hole.

Things people get wrong

  • "SHOULD means optional."

    The single most common misreading. SHOULD is a strong recommendation with an escape hatch, not a free choice. RFC 2119's own words: there may be valid reasons to ignore it, but the full implications must be understood and carefully weighed first. If you skip a SHOULD without a real, defensible reason, you are getting it wrong. The truly optional word is MAY.

  • "A lowercase must is still binding."

    Not since RFC 8174 (2017). Only the all-capitals forms carry the special meaning. A prose sentence saying an implementation "must be fast" is ordinary English and imposes no formal requirement. This is why spec authors are careful to capitalise only where they mean it.

  • "MAY means recommended."

    No. MAY means truly optional: do it or don't, both conform. The word for "recommended" is SHOULD (or the literal synonym RECOMMENDED). Confusing the two turns an option into an obligation, or vice versa, which is exactly the ambiguity RFC 2119 exists to kill.

  • "RFC 2119 is just an IETF thing."

    It started that way and then leaked everywhere. W3C standards, OpenAPI and JSON Schema, cloud-provider API docs, internal engineering RFCs and even procurement contracts now lean on MUST/SHOULD/MAY in the RFC 2119 sense. Learn it once and you read all of them correctly.

Where you'll meet these keywords

RFC 2119 is the standard you have read a thousand times without noticing. A field guide:

You see You're probably looking at
The key words "MUST", "MUST NOT" ... are to be interpreted as described in BCP 14 The RFC 2119 / 8174 boilerplate. Its presence tells you the capitalised keywords in this document are normative, not casual.
MUST / SHOULD / MAY in an OpenAPI or JSON Schema description API authors borrowing the vocabulary to state which fields are mandatory, expected or optional.
A wall of capitalised keywords in the HTTP spec RFC 9110 and friends. Every conformance rule is graded by exactly these words.
MUST / SHOULD in a CONTRIBUTING.md or internal style guide A team adopting requirement levels for its own coding standards, so "SHOULD" reviews differently from "MUST".
shall / shall not in an ISO norm or contract "shall" is the legal ancestor of MUST. RFC 2119 lists SHALL as an exact synonym, which is why the translation practice lines up.

Questions people actually ask

What does SHOULD mean in RFC 2119? +

SHOULD (and its synonym RECOMMENDED) means: do it, unless you have a valid reason not to, in which case you must fully understand and weigh the consequences first. It is not 'nice to have'. The default answer is yes, and skipping it is a deliberate, defensible decision, not a free choice.

What is the difference between MUST and SHALL? +

None. RFC 2119 lists MUST, REQUIRED and SHALL as exact synonyms: all three mean an absolute requirement. SHALL is the older, more legal-sounding word (common in ISO and contract text); MUST is what modern RFCs prefer. If a document mixes them, read them identically.

What is MUST in RFC 2119? +

MUST (also written REQUIRED or SHALL) marks an absolute requirement of the specification. To conform, you have to do it, with no room for judgement. MUST NOT (or SHALL NOT) is the mirror image: an absolute prohibition.

Does a lowercase 'must' in a spec count as a requirement? +

No. RFC 8174 (2017) clarified that the keywords only carry their special RFC 2119 meaning when written in all capitals. A lowercase 'must' or 'should' is just ordinary English prose and imposes no formal requirement.

Does RFC 2119 only apply to IETF documents? +

In theory yes, in practice no. It was written for RFCs, but the vocabulary escaped: W3C specs, OpenAPI and JSON Schema descriptions, vendor API docs, internal engineering standards and even some contracts now use MUST/SHOULD/MAY the RFC 2119 way. It has become the de facto dictionary for requirement language across tech.

Referenced by

Other explainers on this site that point back to this RFC:

How RFC 2119 connects