Applying RFC 2119 with Confidence: Keywords Explained for ESL Engineers
Tired of specs that sound clear but fail in testing and translation? In this lesson, you’ll learn to apply RFC 2119 with confidence—choosing MUST, MUST NOT, SHOULD/SHOULD NOT, and MAY precisely, writing testable requirements, and separating normative rules from informative context. You’ll get ESL-friendly definitions, real-world examples, and targeted exercises (MCQs, fill‑in‑the‑blank, and corrections) to lock in measurable, conformance-ready phrasing. Finish with a checklist you can use to upgrade any sentence from soft advice to auditable behavior.
Why RFC 2119 Exists: Reducing Risk, Enabling Tests, and Supporting Global Teams
Technical teams fail not only from broken code but also from broken language. When a requirement is written loosely—“the client can retry” or “the server should be fast”—each reader imagines a different rule. One engineer thinks it is optional; another treats it as mandatory; a tester does not know what to measure. These misunderstandings multiply in international teams where people bring different linguistic backgrounds and cultural expectations. RFC 2119 exists to eliminate this ambiguity by standardizing a small set of modal verbs with exact meanings. When everyone uses these keywords consistently, we gain three benefits at once:
- Lower misinterpretation risk: A shared vocabulary tells every reader the same thing about obligation, prohibition, recommendation, and permission.
- Conformance testing: If a requirement uses RFC 2119 keywords correctly, we can design tests to verify that an implementation conforms or fails.
- Smooth collaboration: Global teams with different native languages align on the same meanings, reducing the cost of clarification and rework.
Consider the contrast: “Clients should send a token” can mean “best practice” to one reader and “mandatory” to another. In RFC 2119 terms, “Clients MUST send a token” is unmistakable: it is compulsory, non‑negotiable, and testable. Similarly, “The endpoint might return 429” is vague, but “The endpoint MAY return 429 when rate limiting is in effect” clearly grants permission under a defined condition.
RFC 2119 gives us five core keywords with precise meanings:
- MUST and MUST NOT: mandatory presence or absolute prohibition.
- SHOULD and SHOULD NOT: strong recommendation with allowed exceptions that must be justified.
- MAY: permitted or optional behavior.
A simple mnemonic is “2 M’s are Mandatory, 2 S’s are Strong advice, 1 M is Maybe”: MUST/MUST NOT = mandatory; SHOULD/SHOULD NOT = strong advice; MAY = optional.
Deep Dive on Each Keyword: ESL-Friendly Definitions, Tests, and Pitfalls
When writing for engineering audiences, treat these keywords as technical terms, not casual English. In documents, they are often capitalized to signal their special meaning.
MUST
Plain-language definition: This is a non-negotiable requirement. The behavior is compulsory for conformance. No exceptions are allowed.
ESL clarity test:
- How compulsory? Completely. It has to happen exactly as stated.
- Is failure allowed? No. Failure means the product does not conform.
- Can we test it? Yes. We can design a pass/fail test that proves the requirement is met.
Pronunciation and L1 interference notes: In everyday English, “must” can sometimes feel like “strong advice.” In technical writing, “MUST” is never advice. It is a rule that defines conformance. Speakers of languages where obligation words are softened for politeness may underuse MUST. Do not soften mandatory rules; use MUST when you truly require compliance.
MUST NOT
Plain-language definition: This behavior is forbidden. Implementations are prohibited from doing it if they want to conform.
ESL clarity test:
- How compulsory? Completely—do not do it.
- Is failure allowed? No. If the behavior occurs, the product fails conformance.
- Can we test it? Yes. We can create scenarios to verify the behavior never occurs.
Pronunciation and L1 interference notes: Avoid vague negatives like “shouldn’t” or hedging such as “is not recommended.” If the behavior would break safety, security, or interoperability, write MUST NOT.
SHOULD
Plain-language definition: This is a strong recommendation. It is the default expectation, but exceptions may be allowed in specific, justified circumstances.
ESL clarity test:
- How compulsory? Strong, but not absolute.
- Is failure allowed? Rarely, and only with documented, valid reasons.
- Can we test it? Yes, though tests may include recognized exceptions.
Pronunciation and L1 interference notes: In everyday English, “should” often sounds like gentle advice. In RFC 2119, “SHOULD” is much stronger. It signals that deviating is unusual and must be justified. Speakers of languages where “should” equivalents mean “maybe good” must raise the strength in their mental model: “default required unless strong reason.”
SHOULD NOT
Plain-language definition: Avoid this behavior in almost all cases. Exceptions require strong justification.
ESL clarity test:
- How compulsory? Strong discouragement.
- Is failure allowed? Only with documented, compelling reasons.
- Can we test it? Yes. Testing expects absence in normal conditions; exceptions are controlled.
Pronunciation and L1 interference notes: Avoid mixing “should not” with soft phrases like “not preferred.” If a behavior is merely stylistically undesirable but harmless, prefer informative wording. Use SHOULD NOT when the behavior creates risk but may be necessary in rare, justified contexts.
MAY
Plain-language definition: This behavior is permitted. It is optional. Implementers are free to include it or omit it.
ESL clarity test:
- How compulsory? Not at all. It is allowed, not required.
- Is failure allowed? There is no failure in omitting it; both choices conform.
- Can we test it? We can test that, if implemented, it behaves correctly; but conformance does not require its presence.
Pronunciation and L1 interference notes: Everyday “may” can mean possibility (“It may rain”). In RFC 2119, “MAY” means permission (“You are allowed to do this”). Replace vague possibility language like “might” or “can” with “MAY” when you intend to grant permission.
Normative vs. Informative: Does the Sentence Affect Conformance?
To write testable specifications, you must distinguish two types of statements:
- Normative statements define requirements or prohibitions and therefore affect conformance. They use RFC 2119 keywords to signal testable obligations, recommendations with exceptions, or permissions.
- Informative statements explain context, provide background, show rationale, or offer non-binding guidance. They do not set pass/fail conditions for conformance.
Use these decision questions when classifying a sentence:
1) Does the sentence prescribe behavior that can pass or fail? If yes, it is likely normative. 2) Can a tester write a test case that proves compliance or non-compliance? If yes, it is likely normative. 3) Does the sentence merely explain why, give examples, or describe a typical pattern without forcing behavior? If yes, it is informative. 4) Does the sentence grant or restrict permission? If yes, it is normative (MAY for permission, MUST NOT for prohibition).
Not every helpful sentence must be normative. Many documents mix informative explanations with normative rules. A good pattern is to present rationale in informative text and then state a clear normative requirement. For example, you can explain performance context in an informative paragraph and follow with a MUST requirement describing minimum throughput or latency ceilings.
When you find a sentence that gives “soft advice,” decide whether conformance should depend on it. If yes, convert it to a normative statement using the correct keyword and add measurable conditions. If no, keep it informative but avoid misleading verbs like “should” in lowercase, which readers may confuse with the technical term.
Replacing Soft Language with Precise Keywords and Measurable Criteria
ESL engineers often transfer natural language habits into specifications: using “can,” “might,” “normally,” or “it is recommended” to be polite or cautious. These words create ambiguity because they do not specify obligation or measurability. The fix is twofold: select the correct RFC 2119 keyword and attach a clear, testable criterion.
- Replace “can” (ability) with a normative keyword: if it is optional, use MAY; if it is required, use MUST; if it is discouraged but sometimes necessary, use SHOULD NOT.
- Replace “might” (possibility) with MAY (permission) or write a factual, informative description of circumstances, then add a normative rule governing behavior in those circumstances.
- Replace “it is recommended” with SHOULD, and specify when exceptions are valid and how to document them.
- Replace “normally,” “typically,” or “usually” with either an informative pattern or a normative default plus exceptions.
Attach measurement to make requirements testable:
- Define conditions: “when rate limiting is in effect,” “on network errors,” “if configuration X is enabled.”
- Define thresholds: latency bounds, retry counts, payload sizes, error codes.
- Define pass/fail logic: what constitutes success or violation in measurable terms.
By combining the correct keyword with measurable criteria, you transform vague intentions into operational rules that testers and implementers can agree on.
Application Mindset and Writer’s Checklist
Choosing the correct keyword is not about being strict everywhere; it is about being precise where it matters. Overusing MUST makes a specification brittle and may block legitimate implementations. Underusing MUST invites incompatible behavior and security issues. A balanced approach is to assign the strongest force only to the rules whose violation would break interoperability, safety, security, or data integrity, and to use SHOULD for strong recommendations that allow justified deviations.
Use this writer’s checklist when drafting or reviewing requirements:
- Purpose: Does the sentence need to affect conformance? If yes, make it normative; if no, keep it informative and avoid RFC keywords.
- Keyword selection:
- Mandatory? Use MUST.
- Forbidden? Use MUST NOT.
- Strong default with rare exceptions? Use SHOULD or SHOULD NOT.
- Optional/permitted? Use MAY.
- Measurability: Have you specified conditions, thresholds, or criteria that a tester can verify?
- Exceptions (for SHOULD/SHOULD NOT): Have you stated when exceptions are acceptable and how to justify them?
- Consistency: Are keywords capitalized consistently and used only for normative statements?
- Clarity: Have you removed soft, ambiguous verbs such as “can,” “might,” “normally,” “try to,” “it is recommended,” unless they are clearly informative and non-binding?
- Scope: Is the subject (client, server, component) explicit, and are preconditions defined?
- Negative requirements: If you prohibit behavior, is MUST NOT used, and is the prohibited action precisely described?
- Test design: Can a QA engineer derive test cases directly from the statement without asking for clarification?
- Overuse check: Are you reserving MUST/MUST NOT for rules that truly protect interoperability, safety, or security?
Finally, remember the communication goal: a good specification is a contract between authors, implementers, and testers. By using RFC 2119 keywords rigorously—and pairing them with clear, measurable conditions—you create a shared understanding that survives translation, time zones, and turnover. ESL engineers gain confidence because the language is controlled and intentional. Testers gain efficiency because the rules map to checks. Product owners gain predictability because conformance becomes objective. That is the practical power of RFC 2119: fewer arguments about words, more alignment on behavior.
- Use RFC 2119 keywords precisely: MUST/MUST NOT = mandatory or forbidden; SHOULD/SHOULD NOT = strong default with justified exceptions; MAY = optional permission.
- Make statements normative only if they affect conformance and are testable; otherwise keep them informative and avoid RFC keywords.
- Replace soft, ambiguous language (can/might/normally/it is recommended) with the correct keyword and add measurable conditions, thresholds, and pass/fail criteria.
- Capitalize keywords consistently and reserve MUST/MUST NOT for rules critical to interoperability, safety, security, or data integrity.
Example Sentences
- The client MUST include an Authorization header on every request to the /payments endpoint.
- The server MUST NOT log plaintext passwords at any time, including in debug mode.
- Mobile apps SHOULD cache product metadata for 10 minutes to reduce load; exceptions MUST document a bandwidth constraint.
- The API MAY return HTTP 429 when rate limiting is active, and clients MAY retry after the Retry-After duration.
- For audit integrity, services SHOULD NOT delete transaction records; if legal erasure is required, teams MUST record a redacted tombstone.
Example Dialogue
Alex: Our spec says the service should encrypt data. Is that a recommendation or a rule?
Ben: If we want it testable, write it as "The service MUST encrypt data at rest with AES-256." That makes conformance clear.
Alex: Got it. What about compression? It helps performance but isn't always needed.
Ben: Then use "Clients MAY send gzip-compressed payloads; servers SHOULD support gzip unless constrained by CPU limits." Now testers know what's optional and what's a strong default.
Exercises
Multiple Choice
1. Which sentence correctly uses an RFC 2119 keyword for a non-negotiable security requirement?
- Clients should rotate API keys every 90 days.
- Clients MAY rotate API keys every 90 days.
- Clients MUST rotate API keys every 90 days.
- Clients SHOULD rotate API keys every 90 days unless they forget.
Show Answer & Explanation
Correct Answer: Clients MUST rotate API keys every 90 days.
Explanation: MUST indicates a mandatory, testable requirement with no exceptions. Key rotation for security is non‑negotiable, so MUST is appropriate.
2. You want to allow but not require gzip compression. Which wording is correct?
- Clients MUST send gzip-compressed payloads.
- Clients SHOULD send gzip-compressed payloads in most cases.
- Clients MAY send gzip-compressed payloads.
- Clients SHOULD NOT send gzip-compressed payloads.
Show Answer & Explanation
Correct Answer: Clients MAY send gzip-compressed payloads.
Explanation: MAY grants permission and signals optional behavior. Compression is allowed but not required, so MAY is correct.
Fill in the Blanks
The service ___ log plaintext passwords in any environment, including development and debug modes.
Show Answer & Explanation
Correct Answer: MUST NOT
Explanation: MUST NOT expresses absolute prohibition, appropriate for sensitive data like passwords.
When rate limiting is active, the API return HTTP 429, and clients retry after the Retry-After duration.
Show Answer & Explanation
Correct Answer: MAY; MAY
Explanation: MAY indicates permitted/optional behavior for both the server returning 429 and the client retrying under defined conditions.
Error Correction
Incorrect: The client should include an Authorization header on every request to the /payments endpoint.
Show Correction & Explanation
Correct Sentence: The client MUST include an Authorization header on every request to the /payments endpoint.
Explanation: This is a mandatory authentication requirement affecting conformance and security. Replace soft “should” with the normative MUST to make it testable and non‑optional.
Incorrect: Services normally do not delete transaction records, but they can if needed.
Show Correction & Explanation
Correct Sentence: Services SHOULD NOT delete transaction records; if legal erasure is required, teams MUST record a redacted tombstone.
Explanation: “Normally” and “can” are vague. SHOULD NOT expresses strong discouragement with justified exceptions, and the follow‑up MUST adds a mandatory, measurable action for exceptions.