Postel's Law

postels_law.md

The biggest mistake is treating Postel's Law as a suggestion. It's a law, just like Moore's Law, Hyrum's Law, Goodhart's Law, and the Law of Diminishing Returns.

In an ecosystem of interoperating implementations, accepting sloppy input and emitting strict output is the locally-optimal strategy to avoid your implementation being seen as the direct cause of problems. This is contingent on two "facts":

• The upside to accepting sloppy input is immediate, while the downside is far away and diffuse.
• Accepting sloppy input is a one-way ratchet. It's easy to add, sometimes, if it happens to be easy to do it with your current implementation strategy. But, once people start relying on it, it's very painful to remove.

This is a collective action problem, because, in an ecosystem where every other implementation is strict on both emitting and consuming input, the locally-optimal strategy is still Postel's Law, as long as bugs that are easy to work around exist. Advising individual development teams that "Postel's Law is Bad" won't help—their users will abandon them in favor of competitors that Just Work.

Postel's Law causes long-term issues, but that's small comfort if the market stays irrational longer than you stay solvent.

Fixing it requires fixing one of the two "facts". Either:

• Accepting sloppy input needs to cause immediate downsides. For example, mail servers validate HELO lines because (in the past) it works against spammers. Some forms of certification can also require you to reject sloppy input.
• Or breaking changes need to be tolerable. For example, Signal can deploy "breaking changes" to their protocol whenever they need to because they retain centralized control over the whole system. Migration-script upgrades like Abseil and cargo fix also make breaking changes less painful.

See also: https://datatracker.ietf.org/doc/html/rfc9413

In other engineering domains, Postel's law makes a lot more sense. In electronics design, for instance, there will inevitably be some noise added between the output of one component and the input of the next; the tolerances that Postel's law indicates become crucial for a reliable overall system under those circumstances.

The difference may be that it works out in electronics because the digital abstraction is built on top of analog effects in circuits. The tolerances are not only useful, they are compulsory. Without them, the abstraction fails.

We don't really have anything comparable to electromagnetic noise at the software abstraction level. Even floating point numbers are quantized. Software is far above digital in the abstraction hierarchy. If you want any value other than 1's and 0's, it has to be simulated. Simulating noise in, e.g. protocols, is a choice, as is tolerating it.

We don't really have anything comparable to electromagnetic noise at the software abstraction level.

I guess that really depends on what you mean by "the software abstraction level"? If the only thing mediating your access to the outside world is a DAC, your software might need to deal with artifacts from actual electromagnetic noise in your software.

The other thing that makes me thing that EM tolerance isn't comparable to protocol tolerance is that the one-way ratchet isn't there. A button debouncer that's too weak will let noise through, but one that's too strong will filter out actual input. Designing a system to cope with EM interference isn't exactly the same thing as being "liberal in what you expect."

That is accurate, but probably not relevant to internet protocols. (I think we agree on this point?)

The same could be said about randomness. Random data can be useful, random behavior in the protocol not so much.

https://en.wikipedia.org/wiki/Bitsquatting

EM interference can, sometimes, reach the internet protocol level.

However, that sort of thing is usually dealt with by making it stricter, especially with checksumming, not by making it more tolerant.