Software and engineering
Postel's law
Be conservative in what you send and liberal in what you accept: it got the early internet to interoperate, and it lets errors harden into the standard.
Jon Postel, "robustness principle", section 2.10 of RFC 761, the Department of Defense standard TCP specification (January 1980).
RFC (Request for Comments) 761 told Transmission Control Protocol (TCP) implementers to follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. In 1980 the internet was a handful of independent implementations, all with bugs, and a receiver that rejected every slightly malformed packet would have talked to nobody. Tolerance let the network bootstrap. The half people forget is the first half: send the strictest, plainest form of the protocol, so that the tolerance of your peers is never exercised. Read as a pair, the two halves are a way to make a system work before everyone agrees on the details.
RFC 9413, published by the Internet Architecture Board in 2023 (Martin Thomson and David Schinazi), argues that the second half ages badly. An implementation that quietly accepts a variation lets that variation survive; the next implementation has to accept it too, to interoperate; over time the protocol decays toward bug-for-bug compatibility with whatever was deployed first, and the parts nobody varies become frozen, so the protocol can no longer change. Their alternatives are active maintenance of both specifications and implementations, fatal errors for unspecified conditions so faults surface early, and designed extension points that are exercised on purpose (greasing) so that nothing ossifies by accident.
Both sides have a point, and the difference is who can be updated. RFC 9413 itself notes the principle has been read in several ways, some of which helped the internet, and it does not say to reject everything unfamiliar. Strictness is only safe when a broken peer can be fixed: browsers and servers on an auto-update cycle can afford to fail fast, while a protocol spoken by millions of unmaintained devices still needs tolerance to keep working. The practical rule, in my reading, is to accept generously but never silently: log every tolerated deviation, report it to whoever sends it, and treat the list as debt to pay down rather than behaviour to preserve.
Example
In February 2017 the browser makers tried to ship TLS 1.3, the Transport Layer Security version that replaces TLS 1.2. Chrome measured a 92.3 percent success rate for TLS 1.3 connections to Gmail against 98.3 percent for TLS 1.2; Firefox with Cloudflare saw 96.1 percent against 97.8 percent. The failures came from middleboxes that had accepted TLS 1.2 handshakes loosely but choked on a new version number and missing fields. The fix was to disguise TLS 1.3 as TLS 1.2: the version field says 1.2, a dummy session identifier, a ChangeCipherSpec message and an empty compression field were put back, and the real version is negotiated in an extension. With the disguise, Chrome's success rate was 98.8 percent against 98.6 percent for TLS 1.2.
Where it applies
When you parse someone else's output, decide which deviations you accept and log every one, because each silent acceptance is a format you now support forever. In a large language model (LLM) pipeline the same holds for model output: a tolerant JSON repair step is useful, but if it does not report how often it fires, you will not notice the prompt has drifted until the repair stops working.
Think about it
Where does your code accept malformed input silently, and who would notice if the sender fixed it?
Applied it to something real? Log it.
Test yourselfRFC 9413 argues that Postel's principle sets up a feedback cycle. What is the cycle?
Receivers tolerate variations, so the variations survive; new implementations must reproduce them to interoperate; the protocol decays toward bug-for-bug compatibility and the untouched parts freeze, so it can no longer change.
Related models
- Hyrum's lawWith enough users of an interface, every observable behaviour gets depended on by someone, whatever the contract promises.
- Feedback loopsA system's output feeds back into its input: balancing loops hold a level steady, reinforcing loops make change grow on itself.
- Unintended consequencesPurposeful actions produce outcomes nobody planned, because the people and systems acted on respond in ways the plan never modelled.
- Second-order thinkingKeep asking "and then what?" until you have looked at the consequences of the consequences.