Skip to main content
Category: Laws
Type: Network / systems interoperability principle
Origin: Jon Postel; TCP specifications (e.g., RFC 793, 1981)
Also known as: Robustness principle
Quick Answer — Postel’s Law is the robustness principle: be conservative in what you send, liberal in what you accept (wording varies slightly by document). It helped early Internet protocols interoperate across imperfect implementations. Today it remains a design heuristic—and a contested one—because tolerance can cement bugs and enlarge attack surfaces if not paired with security review.

​
What is Postel’s Law?

Postel’s Law names a guideline for protocol implementations: emit bytes that strictly follow the spec, but parse inputs generously when meaning can still be recovered. The aim is interoperability when specs were evolving and peers differed. It sits alongside Conway’s Law (systems mirror communication structure—different axis) and contrasts with Brooks’s Law (adding people adds coordination cost—orthogonal, but both shape shipping constraints). Unlike Murphy’s Law, Postel is prescriptive, not fatalistic.
Strict speakers and forgiving listeners carried the early net—until ambiguity became exploit surface.

​
Postel’s Law in 3 Depths

  • Beginner: Expect older clients to send odd whitespace; strict servers still reject illegal frames, but may trim benign variation.
  • Practitioner: Encode canonical outputs; on input, validate with allow-lists, log anomalies, and version behaviors explicitly.
  • Advanced: Treat tolerance as a security budget—modern analyses warn bug-for-bug compatibility can ossify flaws across the ecosystem.

​
Origin

Jon Postel articulated the robustness principle as an implementation strategy for early TCP/IP work. The widely cited formulation appears with RFC 793 (Transmission Control Protocol, September 1981), instructing TCP implementations to be robust: conservative in sending behavior and liberal in accepting incoming segments consistent with the specification’s intent. The exact phrasing evolved across documents, but the pairing of strict generation with tolerant consumption became foundational engineering folklore for protocols, parsers, and APIs.

​
Key Points

Use Postel to maximize compatibility—then measure where tolerance hurts safety.
1

Interoperability first

Heterogeneous vendors and partial deployments required forgiving receivers to keep the network useful.
2

Canonicalize outputs

“Conservative sending” pushes complexity to well-tested encoders rather than scattered clients.
3

Liberal acceptance needs bounds

Without schemas, fuzzing, and monitoring, permissive parsers become vulnerability farms.
4

Ecosystem effects dominate

Once many peers depend on a quirk, fixing it requires coordinated change—bug-for-bug pressure.

​
Applications

Map the principle to modern API and platform design.

Protocols & parsers

Emit strict JSON or protobuf; accept with validation layers that reject ambiguous or oversized inputs early.

Web front ends

Normalize user input on save; still escape on render—liberal UX is not SQL injection forgiveness.

Collaboration norms

Be precise in commitments you emit; allow good-faith variation in how teammates phrase updates—within agreed standards.

Backward compatibility

Version APIs explicitly; deprecate tolerant paths on a published timeline instead of silent forever-quirks.

​
Case Study

The principle’s institutional anchor is textual: RFC 793 (1981) encodes TCP’s robustness guidance for implementations that had to coexist across vendors—an externally citable standard with a dated RFC number and year rather than a lab metric. Later engineering discourse (including ACM Queue / Communications of the ACM treatments in the 2000s–2020s) revisits whether permissive acceptance entrenched interoperability bugs—an indicator that the debate shifted from whether networks connected to what security invariants must hold when tolerance is default.

​
Boundaries and Failure Modes

Boundary 1: Security breaks naive liberality
Attackers craft ambiguous inputs precisely where parsers guess intent. Boundary 2: Standards matured
Modern protocols often prefer explicit failure over silent repair. Common misuse: Infinite tolerance without telemetry—quirks become undeletable legacy.

​
Common Misconceptions

Separate generosity from abdication.
Reality: Liberal parsing still rejects illegal states; kindness is bounded by safety and spec intent.
Reality: Conservative sending pairs with disciplined validation—often layered (syntax vs semantics).
Reality: The tradeoff evolved; the pattern still appears wherever ecosystems must interoperate.
Use these when balancing compatibility and correctness.

Conway's Law

System shapes follow communication shapes—coordination sets what “compatible” means.

Brooks's Law

Adding people adds communication overhead—shipping fixes for legacy quirks costs time.

Murphy's Law

If something can go wrong, it will—design validation accordingly.

​
One-Line Takeaway

Canonicalize what you emit; validate what you accept—with explicit limits and metrics, not infinite guesswork.