School of Specs How standards actually get madeIn depth

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

  1. RFC 2119, section 1 the words of section 1 of RFC 2119 as stored at /var/www/whatthespec.net/data/data/rfcs/rfc2119.txt
  2. RFC 2119, section 3 the words of section 3 of RFC 2119 as stored at /var/www/whatthespec.net/data/data/rfcs/rfc2119.txt
  3. RFC 2119, section 5 the words of section 5 of RFC 2119 as stored at /var/www/whatthespec.net/data/data/rfcs/rfc2119.txt
  4. RFC 8174, section 1 the words of section 1 of RFC 8174 as stored at /var/www/whatthespec.net/data/data/rfcs/rfc8174.txt
  5. 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
  6. 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
  7. RFC 2418, section 1 the words of section 1 of RFC 2418 as stored at /var/www/whatthespec.net/data/data/rfcs/rfc2418.txt

Every source this course is built on

Check yourself

Answers appear when you pick one, with where they come from.

Q13.1 What does MUST mean in an RFC?

Q13.2 What does SHOULD allow?

Q13.3 A protocol document uses the word "must" in lower case. What does it carry?

Q13.4 Which word does 3GPP ban outright, and which does the IETF make its strongest?

Q13.5 What is the relationship between REQUIRED, SHALL and MUST?

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.