push.cx
Peter Bhat Harkins
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.
A small thing I’d add to the draft is that errors, except rarely in the presence of (very few) security-sensitive topics, must provide the recipient with an obvious next step for addressing the error. For years, Internet Explorer’s JavaScript engine would tell you what exception had occurred with no further detail (no function, line number, filename). The bigger a standard is and the more functionality or sub-standards it includes (and JS sits atop a very tall tower of standards) the more value there is in implementations being strict, and also the more value there is in them being explicit and useful.
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.