Skip to content

CONCEPT Cited by 1 source

RFC normative language

RFC normative language is the set of capitalised keywords — MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, etc. — that Internet standards use to express requirement strength. The vocabulary was formalised by RFC 2119 in 1997. Before RFC 2119, specifications used ordinary English and relied on context for requirement force; after RFC 2119, those keywords became reserved terminology with precise semantics.

The RFC 2119 keywords

  • MUST / REQUIRED / SHALL — absolute requirement.
  • MUST NOT / SHALL NOT — absolute prohibition.
  • SHOULD / RECOMMENDED — may be ignored with full understanding of the consequences.
  • SHOULD NOT / NOT RECOMMENDED — similar to SHOULD, but negative.
  • MAY / OPTIONAL — truly optional.

Modern RFCs typically open with a boilerplate paragraph stating "The key words... in this document are to be interpreted as described in RFC 2119."

The pre-1997 gap

Many foundational Internet RFCs predate RFC 2119 and use ordinary English words that sound prescriptive:

Words like must, should, preface, normally in these documents were not reserved terms. Readers using post-1997 intuitions can over- or under-read prescriptive force.

Case study: "preface" in RFC 1034 §4.3.1

Cloudflare's 2026-01-19 post-mortem on the 2026-01-08 1.1.1.1 incident pins the structural cause on exactly this gap:

The answer to the query, possibly preface by one or more CNAME RRs that specify aliases encountered on the way to an answer.

"Preface" in 1987 English is ambiguous — it reads like a constraint ("CNAMEs come first") but carries no RFC-2119 MUST. Implementers split:

  • Some (most stub resolvers, glibc getaddrinfo) treated "preface" as a requirement and built sequential parsers that depend on it.
  • Others (systems/systemd-resolved, BIND, Unbound) treated it as advisory and built parsers that tolerate any legal ordering.

Cloudflare itself had originally implemented CNAMEs-first for over a decade — "consistent with the preface hint" — but, because the spec wasn't unambiguous enough to mandate a formal requirement, the team did not write a test asserting the invariant, which is the gap a 2025-12 memory optimisation fell through.

Implication: old RFCs need care

Pre-1997 RFCs require:

  1. Don't read MUST where there's only "must" — the lower-case word may be advisory.
  2. Don't read MAY where there's silence — post-1997 RFCs list MAY cases explicitly, but pre-1997 silence can conceal decades of implementer convention.
  3. Check the historical implementation record — "what real implementations have always done" is often the load-bearing constraint, not the spec text.
  4. Write tests for behaviour that convention has settled even when the spec hasn't (the test the ambiguous invariant pattern).

Modernisation by Internet-Draft

Cloudflare's response to the 2026-01-08 incident is to file draft-jabley-dnsop-ordered-answer-section at IETF DNSOP — converting the convention into explicit RFC-2119 MUST language so future implementers don't have to reverse-engineer it from "preface". This is the textbook remediation for ambiguity in a foundational RFC: ship an updated RFC with normative keywords. The alternative (expecting every deployed stub to change) is unavailable at Internet scale.

Last updated · 200 distilled / 1,178 read