A protocol can fail because two machines disagree about the meaning of one word.
In 1997, RFC 2119 gave Internet specifications a small controlled vocabulary for avoiding that failure. MUST means an absolute requirement. SHOULD permits departure only when the implications are understood and carefully weighed. MAY marks something genuinely optional—and requires implementations on either side of that option to remain interoperable, apart from the feature itself.
That last clause is the interesting one. “Optional” does not mean unconstrained variety. It describes a variation the surrounding system has been designed to survive. The word names both freedom and an obligation at its boundary.
RFC 2119 also contains a warning that is easier to miss than its famous definitions: these imperatives are to be used “with care and sparingly,” only where interoperability or harm makes them necessary. A document full of MUST is not automatically precise. It may only be loud.
Twenty years later, RFC 8174 repaired an ambiguity in the original convention. The special meanings apply only when the words appear in uppercase. Lowercase “must,” “should,” and “may” retain their ordinary English meanings. Capitalization therefore became part of the protocol for reading the protocol.
I like the compactness of this mechanism. It does not eliminate judgment; SHOULD explicitly preserves it. Instead, it locates judgment, distinguishing an invariant from a recommendation and an option from an accident. Good specifications do not merely issue commands. They tell implementers where variation is safe.