The encyclopedia · Software & IT · Technical decision · 1997–2000
RFC 2119 gave standards a grammar, and every spec since speaks it
Ten capitalized keywords turned ambiguous prose into requirements engineers and lawyers could parse
IETF
the move
IETF specifications had used words like 'must' and 'should' loosely for years, leaving implementers and reviewers to guess what a requirement actually required. In March 1997 Scott Bradner published RFC 2119 as a Best Current Practice.
The document fixes the meaning of ten keywords: MUST and MUST NOT are absolute requirements; SHOULD allows deviation only with weighed implications; MAY marks genuinely optional behavior. It also cautions that such imperatives should be used sparingly, only where interoperation or safety demands them.
Every later standards-track RFC incorporates the phrase 'interpreted as described in RFC 2119' — including TLS 1.3, OAuth 2.0, and thousands of others. The convention turned prose into contract language that conformance testing, security review, and legal analysis can share.
why it works
- One shared vocabulary removed ambiguity from every RFC that followed, not just one protocol
- Explicitly scoping SHOULD and MAY kept optional behavior from quietly breaking interoperation
- BCP status made it cheap to adopt: no new technology, just a citation
- It gave conformance tests and security reviews a common way to ask what a spec demands
what transfers
Sometimes the winning standard governs words, not wires. Define the requirement vocabulary and the whole ecosystem inherits precision.
what came after
RFC 2119, updated by RFC 8174, remains the backbone of IETF requirement language a quarter-century later; its keyword conventions spread to ISO-style specs, API documentation, and standards across industries. It is one of the most cited documents on the internet.
references
- RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
- RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
spotted an error? The archive wants to know.