Summary

  • RFC 8174 says BCP 14’s special meanings apply only to the listed words in all capitals under the declared convention. Lowercase must and should retain ordinary English meanings.
  • The correction does not make typography a complete normativity test. RFC 8174 expressly says normative text need not use the keywords, while RFC 2119 says their force is modified by the requirement level of the document.
  • A trustworthy conformance receipt therefore needs the document version and status, the declared convention, the full sentence and subject, any exception rationale, a test and an observed result—not merely a count of capitalized tokens.

The scanner stopped at the easiest evidence

Suppose a procurement tool ingests an RFC and highlights every MUST. The result looks decisive: a list of obligations ready to become tickets, tests and contract clauses. Yet the tool has not answered basic questions. Is the word part of a quotation? Is the document invoking BCP 14? Which actor performs the action? Does a referenced definition narrow it? Is this document the authoritative version? What observation would show compliance?

Those are not edge cases around an otherwise automatic rule. They are the rule’s operating context. A keyword is a pointer into a sentence, and the sentence is a pointer into a document whose status and scope matter.

RFC 8174 is valuable because it removes one avoidable ambiguity without pretending to remove all judgment. Leiba narrowed the lexical switch. The change makes automated discovery safer, but it also shows where automation must stop.

“Often capitalized” left two grammars in one word

Scott Bradner’s RFC 2119 gave protocol authors a common vocabulary for requirement levels. MUST means an absolute requirement of the specification; MUST NOT an absolute prohibition. SHOULD permits departure only when valid reasons exist and the implications are understood. MAY makes a feature truly optional while preserving interoperability between implementations that choose differently.

The original text said these words were “often capitalized.” That phrase left a practical question. If an author wrote must in lowercase, was it the defined imperative with casual typography or an ordinary English word? Reviewers, authors and tooling could reach different conclusions while reading the same sentence.

RFC 8174’s repair is exact: the special BCP 14 meanings apply only when the words are in all capitals. When they are not, they have their normal English meanings. The updated boilerplate turns that rule into an explicit convention inside the document.

The second half of the correction matters more

It is tempting to turn the clarification into a shortcut: capitals are normative, lowercase is not. RFC 8174 rejects that shortcut in the same section. The document says use of the keywords is optional and that much normative text does not use them.

This produces two separate tests. Capitalization answers whether a listed word is invoking BCP 14’s defined meaning. It does not, by itself, answer whether the surrounding text is normative, who authorized it, or how broad the requirement is.

The distinction is easy to miss because both questions appear on one line. A lowercase instruction may still be normative through the document’s structure and authority. An uppercase token may sit inside a quotation, an example or a discussion of someone else’s requirement. A parser that collapses the two tests creates false negatives and false positives at once.

A word receives force from a document

RFC 2119 itself warns that the force of its terms is modified by the requirement level of the document in which they appear. Typography cannot promote an Internet-Draft into a standard, turn an Informational RFC into an interoperability mandate or make a private checklist an IETF decision.

This is the institutional boundary in Leiba’s small procedural document. Authors choose text. Working groups and stream approvers establish process and status. The RFC Editor preserves an approved meaning. Implementers then map that meaning onto behavior. Capital letters make the handoff more legible; they do not replace any party in the chain.

That is why the standard boilerplate is not decorative. It tells a reader which vocabulary the document has adopted. Without that receipt, a familiar word may still be important, but the BCP 14 definition cannot simply be assumed.

SHOULD is an exception protocol, not a softer MUST

People often arrange MUST, SHOULD and MAY on a single severity slider. The definitions describe different control designs. MUST identifies a condition the specification treats as absolute. SHOULD carries an exception mechanism: deviation can be legitimate, but only after its consequences are understood and weighed. MAY protects implementation choice while requiring the surrounding system to tolerate either choice.

Current IETF author guidance calls SHOULD especially problematic. The author must explain why it is not MUST and what happens when an implementation varies. A conformance matrix that labels every SHOULD “optional” has discarded precisely the decision record that makes the word useful.

The requirement is therefore larger than the token. It includes the actor, behavior, precondition, exception and interoperability consequence. A highlighted word without those fields is an index entry, not an implementable control.

The style guide supplies the decisive counterexample

RFC 7322 says it does not use RFC 2119 terminology. It then uses lowercase must and should and explains their local editorial meanings: one describes changes the RFC Editor will apply automatically, the other recommended usage that may be questioned.

The example does not weaken BCP 14. It proves the value of declaring the grammar in use. Readers do not have to guess whether the lowercase words are failed capitalization. The document tells them that a different local convention applies.

The same style guide says that a document using the RFC 2119 interpretation must cite it and make it a normative reference; otherwise it must define the intended interpretation. Authority travels with explicit context, not visual familiarity.

Even structured markup marks only the phrase

The current RFCXML vocabulary offers an optional <bcp14> element. It can wrap MUST or SHOULD NOT, helping authoring and rendering tools distinguish the defined phrase. The official guidance warns not to wrap the entire requirement inside that element.

That design is a quiet admission of scale. The machine-readable object is the phrase, not the complete obligation. The subject, action, condition and exception remain in ordinary document structure and prose.

A tool can use the tag as a high-quality candidate signal. It should then preserve the full sentence, section, referenced definitions and document metadata. Turning the tag into a complete compliance rule would claim more than the markup records.

Capitalization is a receipt, not a mandate

Barry Leiba’s contribution was not to make upper case more powerful. It was to make the vocabulary’s activation condition honest. A reader can now distinguish a BCP 14 keyword from the same letters used as ordinary English.

The next distinction belongs to governance and evidence. Consensus and publication supply authority; prose supplies scope; implementations and tests supply observed conformance. None can be reconstructed from font case alone.

The durable lesson for automated review is modest. Find the keyword. Keep the document around it. Ask who is bound, under which status, with what exception and what test. The capital letters have done their job when they lead to those questions—not when they are allowed to answer them.

Sources