Area VI · Controlled Natural Languages & Constrained Registers

RFC-2119 Normative Keywords

MUST · SHOULD · MAY

Reserve specific capitalized keywords for exact, agreed levels of requirement.

Definition & mechanics

Internet standards fix the meaning of requirement words through RFC 2119: MUST and MUST NOT mark absolute requirements; SHOULD and SHOULD NOT mark strong recommendations with allowable exceptions; MAY marks genuine optionality. Capitalized, they carry defined force; everywhere else the same words stay ordinary prose.

A curiosity

The difference between “should” and “MUST” has decided lawsuits and interoperability wars. Making the requirement level explicit removes the reader's need to infer how serious you are.

Example

BeforeClients should really validate the token, and they can cache it if they want to.

After (RFC-2119)Clients MUST validate the token before use. Clients MAY cache a validated token until it expires.

Copy-ready prompt

Copyable Prompt

Apply the concept of RFC-2119 Keywords (rewrite requirements using RFC 2119 normative keywords—MUST / MUST NOT for absolute requirements, SHOULD / SHOULD NOT for strong recommendations, MAY for optional behavior; capitalize these keywords only where normative, and phrase each requirement as a single testable statement) to the provided text and rewrite in place.

Apply the edits directly to the file as a clean, production-ready deliverable. Output ONLY the revised document text without embedding revision notes, changelogs, or meta-commentary in the file itself—put any explanations in your chat response only.