How the IETF works · chapter 13 of 16 · 6 minutes
13 MUST, SHOULD and MAY — three words, one short document
The IETF's requirement words, quoted exactly, the correction that made only the capitalised spellings count, and what each one costs an implementer.
13.1 The same problem, a different instrument
3GPP solved the requirement problem with a drafting rule: a table of verbal forms in a separate document: "shall" for a requirement [5], "should" for a recommendation [6].
The IETF solved it with a document so short that every other document simply cites it. The words are defined once, in capitals, and any RFC that says it uses RFC 2119 keywords has imported the whole set RFC 2119.
13.2 The three words
MUST is the top of the scale, and it comes with two synonyms.
SHOULD is the interesting one, because it grants permission and imposes a duty in the same sentence.
MAY is the floor, and its definition is the shortest of the three.
The three definitions above are taken from sections 1, 3 and 5 of RFC 2119. The sections between them are not quoted here, and this course does not say what they contain — the document itself is in the archive on this machine RFC 2119.
13.3 What each one costs you
The scale is easiest to see from the implementer's side, in terms of what you have to be able to say if somebody asks.
| Word | What you have to be able to say |
|---|---|
| MUST | "We do this." Nothing else conforms. |
| SHOULD | "We do this" — or "we do not, and here is the reasoning, and here is what we understood the consequences to be." |
| MAY | "We do" or "we do not." No explanation is owed. |
SHOULD is where the interoperability trouble collects, and the definition tells you why. It does not say the item may be skipped when inconvenient. It says there may exist valid reasons in particular circumstances, and that the full implications must be understood and carefully weighed first [2]. The permission is real. So is the homework.
13.4 Only the capitals count
For twenty years the words carried an ambiguity that everybody eventually hit: an author writes "the client must retry", meaning ordinary English, and a reader takes it as an absolute requirement.
RFC 8174 settled it.
So a lower-case "must" in an RFC is ordinary prose, and carries no more weight than any other sentence in the paragraph RFC 8174. Modern documents usually say so explicitly in their own text, citing both RFCs together.
This is also a small demonstration of the publication rule from The life of an RFC, from a draft nobody may cite to a number nobody may edit: RFC 2119 was not edited to add the clarification. A second document was published that updates it, and both remain in the series with their own numbers. The two together are known by one practice designation, BCP 14, so that citing "BCP 14" picks up the pair.
13.5 Why one short document instead of a rulebook
3GPP keeps its wording rules inside a drafting-rules document that also governs layout, tooling and structure TR 21.801 v19.1.0, and every 3GPP author is expected to follow the whole thing. The IETF has a style guide of comparable scope RFC 7322, but it deliberately did not put the requirement words in it.
The reason is who writes the documents. There is no formal membership and no list of approved authors [7], so a specification may arrive from anybody, through any of four streams RFC 7841. A vocabulary that only trained authors would apply correctly would not survive that.
So the definitions were made small enough to import: one page, three words and their synonyms, cited by a single line near the front of the document that uses them. An author who has read nothing else can still be precise about requirements, and a reader who knows only RFC 2119 can still read the document for what binds.
13.6 Set against 3GPP
The two vocabularies overlap, and the overlap has one sharp edge.
| 3GPP | IETF | |
|---|---|---|
| Absolute requirement | shall | MUST, REQUIRED, SHALL |
| Recommendation | should | SHOULD, RECOMMENDED |
| Permission | may | MAY, OPTIONAL |
| "must" | not used | the strongest word there is |
| Where defined | the drafting rules, a separate document | RFC 2119, updated by RFC 8174 |
| Marked how | ordinary lower case | capitals only |
3GPP avoids "must" so that nobody confuses a standard with a law, and defines "shall" and "should" instead [5]. The IETF makes MUST its strongest term and folds SHALL in underneath it as a synonym [1].
Both bodies arrive at the same three strengths. Neither could be read using the other's rules without getting at least one sentence in three wrong.
13.7 Reading habit
Three questions, in order, for any sentence in an RFC that looks like a rule:
-
Is the keyword capitalised? If not, it is prose [4].
-
Does the document say it uses these keywords? Modern documents state it near the front, citing RFC 2119 and RFC 8174 RFC 8174.
-
Which of the three is it? MUST binds [1], SHOULD binds unless you have done the thinking [2], and MAY does not bind at all [3].
The same three questions, asked of a 3GPP document, become one: what is the verb? Why the documents read the way they do covers that side.
13.8 Where this leads
Both halves of the course now have their vocabulary, their procedure and their publication rules. The two cultures, side by side and on the evidence puts them side by side and says what the evidence here does and does not support.
Where the numbers in this chapter come from
- RFC 2119, section 1 the words of section 1 of RFC 2119 as stored at /var/www/whatthespec.net/data/data/rfcs/rfc2119.txt
- RFC 2119, section 3 the words of section 3 of RFC 2119 as stored at /var/www/whatthespec.net/data/data/rfcs/rfc2119.txt
- RFC 2119, section 5 the words of section 5 of RFC 2119 as stored at /var/www/whatthespec.net/data/data/rfcs/rfc2119.txt
- RFC 8174, section 1 the words of section 1 of RFC 8174 as stored at /var/www/whatthespec.net/data/data/rfcs/rfc8174.txt
- TR 21.801, Annex E the words of clause Annex E of 3GPP TR 21.801 v19.1.0 as parsed under /var/www/whatthespec.net/data/friendlyspec/json/21801/19.1.0
- TR 21.801, Annex E the words of clause Annex E of 3GPP TR 21.801 v19.1.0 as parsed under /var/www/whatthespec.net/data/friendlyspec/json/21801/19.1.0
- RFC 2418, section 1 the words of section 1 of RFC 2418 as stored at /var/www/whatthespec.net/data/data/rfcs/rfc2418.txt
Check yourself
Answers appear when you pick one, with where they come from.
Q13.1 What does MUST mean in an RFC?
RFC 2119 says MUST, and the terms REQUIRED and SHALL, mean that the definition is an absolute requirement of the specification. RFC 2119, section 1
Q13.2 What does SHOULD allow?
RFC 2119 defines SHOULD, and the adjective RECOMMENDED, in exactly those terms. The permission is real but it comes with an obligation to think. RFC 2119, section 3
Q13.3 A protocol document uses the word "must" in lower case. What does it carry?
RFC 8174 updates RFC 2119 by clarifying that only UPPERCASE usage of the key words has the defined special meanings. RFC 8174, section 1
Q13.4 Which word does 3GPP ban outright, and which does the IETF make its strongest?
3GPP uses "shall" for a requirement and "should" for a recommendation, and does not use "must", so a standard is not mistaken for a law. RFC 2119 makes MUST the absolute requirement and lists SHALL as one of its synonyms. RFC 2119, section 1
Q13.5 What is the relationship between REQUIRED, SHALL and MUST?
RFC 2119 gives them in one breath — MUST, or the terms REQUIRED or SHALL, mean the definition is an absolute requirement. RECOMMENDED pairs with SHOULD and OPTIONAL with MAY in the same way. RFC 2119, section 1
This chapter was written against TR 21.900 version 20.0.0, and built from a source register generated 2026-08-04. A newer version of the document may say something else.