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
HELOlines 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 fixalso make breaking changes less painful.
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."