Postel’s Law

Details
Full Name

Postel’s Law / The Robustness Principle

Also known as

"Be conservative in what you send, be liberal in what you accept"

Core Concepts:

The principle

Send strictly conforming output; accept input tolerantly, coping with anything you reasonably can — to maximize interoperability between independently built systems

Conservative output

Emit only well-formed, specification-compliant messages so peers never have to compensate for your sloppiness

Liberal input

Tolerate minor deviations and unknown-but-ignorable fields rather than rejecting otherwise-usable messages — supports forward/backward compatibility

Where it shines

Long-lived network protocols, public APIs, file formats, and event schemas that must evolve while old and new participants coexist

The modern critique

Excessive tolerance accumulates undefined behaviour and security risk (ambiguous parsing, smuggling); contemporary guidance favours strictness plus explicit versioning. Apply with a documented tolerance boundary, not blanket leniency

Key Proponents

Jon Postel (RFC 760/761, 1980, in the context of TCP/IP)

When to Use:

  • Designing protocol, API, or event-schema contracts that must evolve

  • Deciding how strictly a parser/validator should reject input

  • Reasoning about forward/backward compatibility and graceful degradation

When NOT to Use:

  • Security-sensitive parsing where ambiguity is dangerous — prefer strict validation

  • Internal interfaces under one team’s control, where strictness catches bugs earlier

Criticism:

  • Eric Allman, "The Robustness Principle Reconsidered" (ACM Queue, 2011) — decades of liberal acceptance bred de-facto protocol forks and security holes; tolerance that was meant to be transitional became permanent

  • RFC 9413, "Maintaining Robust Protocols" (Thomson & Schinazi, IETF, 2023) — formal IETF guidance that blanket liberality harms protocol ecosystems over time; ambiguous tolerance enables interoperability failures and attacks such as request smuggling

  • Alternative named in the discourse: active protocol maintenance with strict parsing and explicit versioning ("fail fast") instead of silently accepting malformed input — see Semantic Versioning