The Robustness Principle, also called Postel’s Law, advises: “Be conservative in what you do, be liberal in what you accept from others.” Jon Postel stated it in the early Internet RFCs that defined the core protocols. In RFC 760, the January 1980 specification of the Internet Protocol, Postel wrote that an implementation should be conservative in its sending behavior and liberal in its receiving behavior. The principle was restated and given its most quoted form in RFC 1122, the 1989 Requirements for Internet Hosts document edited by Robert Braden, which cites Postel’s IP work as its source.
The motivation was practical and rooted in the realities of building a network out of independently written implementations. If every sender follows the specification strictly, the data on the wire is clean. If every receiver also tolerates minor deviations rather than rejecting them, then a buggy or slightly nonconforming sender does not break the whole conversation. The asymmetry is deliberate: you hold yourself to a high standard while extending grace to others, which lets a heterogeneous network of imperfect software interoperate well enough to function. In the early Internet, where implementations were written by small teams without a central authority enforcing conformance, this tolerance was arguably essential to getting anything to work at all.
For decades the principle was treated as settled wisdom, and the early Internet’s remarkable ability to grow despite countless interoperability quirks was credited in part to it. Being liberal in what you accept smoothed over the friction that would otherwise have stalled adoption, and many influential protocols were built with this forgiving posture baked in.
In time, though, a serious critique emerged. Liberal acceptance, critics argued, has a hidden cost: it lets nonconforming senders survive and spread, because their bugs are silently tolerated rather than surfaced. Over years this leads to specification rot, where the real protocol becomes “whatever the dominant implementations happen to accept” rather than what the standard says. It also creates a security surface, since code that tries to make sense of malformed input is exactly the code where parsing vulnerabilities live. Later IETF work, including documents revisiting the principle for protocol designers, argued that strict, fail-fast handling and active maintenance of implementations often produce more durable interoperability than open-ended tolerance.
The modern consensus is more nuanced than either the original rule or its sharpest critics. Be conservative in what you send remains uncontroversial good advice. Be liberal in what you accept is now seen as context-dependent: valuable for bootstrapping a young protocol with many independent implementers, but dangerous for a mature, security-sensitive protocol where ambiguity and silent tolerance accumulate into long-term fragility. Postel’s Law endures less as a commandment and more as a tradeoff that every protocol designer has to weigh deliberately.