The Harmful Consequences of Postel’s Maxim
« Against Tedium
» Deleting Spam From sup Maildirs
Code: Postel's Maxim, standards
Comments Off on The Harmful Consequences of Postel’s Maxim
Be liberal in what you accept, and conservative in what you send.
Postel’s Maxim, RFC 1122
There’s a short draft called The Harmful Consequences of Postel’s Maxim that reads:
An implementation that reacts to variations in the manner advised by
Postel sets up a feedback cycle:
- Over time, implementations progressively add new code to constrain
how data is transmitted, or to permit variations what is received.
- Errors in implementations, or confusion about semantics can
thereby be masked.
- As a result, errors can become entrenched, forcing other
implementations to be tolerant of those errors.
The short draft is very insightful and worth your time to read in full.
But did Postel mean what we thought by his Maxim? A blog post found reference to an old mailing list message:
I knew Jon Postel. He was quite unhappy with
how his robustness principle was abused to cover up non-compliant
behavior, and to criticize compliant software.
Jon’s principle could perhaps be more accurately stated as “in general,
only a subset of a protocol is actually used in real life. So, you should
be conservative and only generate that subset. However, you should also
be liberal and accept everything that the protocol permits, even if it
appears that nobody will ever use it.”
I was curious if this was an accurate characterization. There’s an earlier formulation of Postel’s Maxim than was cited in the draft:
The implementation of a protocol must be robust. Each implementation
must expect to interoperate with others created by different
individuals. While the goal of this specification is to be explicit
about the protocol there is the possibility of differing
interpretations. In general, an implementation should be conservative
in its sending behavior, and liberal in its receiving behavior. That
is, it should be careful to send well-formed datagrams, but should
accept any datagram that it can interpret (e.g., not object to
technical errors where the meaning is still clear).
RFC 760, Jan 1980
This document, edited by Jon Postel, seems unambiguous. That incorrect data (like the too-long encodings in message subjects in the “I knew Jon Postel” thread) should be tolerated as long as the sender’s intent was clear. This was the oldest thing I could find on Postel’s Maxim (also known as his Law, Prescription, and a few others), though there may be more elaboration out there for someone who wants to dig deeper.
Turning back to the draft, I especially like the analysis of long-term costs. Iâ€™ve been making websites for over 20 years and lack of standards and compatability with standards has been an enormous, generally needless cost. Over the fall I implemented a new, barely-used standard and still lost time to differing implementations and questions that could only be resolved by running a debugger against an implementation.
The biggest missing recommendation in the draft that standards MUST include programmatic test suites. Those suites SHOULD be expanded and updated more frequently than an RFC lifecycle of years based on the size and popularity of the standard. The various ACID tests were really good for CSS; a browser conformed or you had a list of missing features that you could discuss with a standard vocabulary and shared understanding. English is complex and vague. Computer standards need to be explicit and precise. That means some part of them needs to be programmatic, not prose.
Tools like FitNesse (though I have no horse in this race) provide a standard for examples and tests without standardizing on a programming language or testing library in the same way that BNF provides an unambiguous grammar for data without tying a standard to the tools of a particular programming environment. I hope to see more tools help us write better standards.