The Harmful Consequences of Postel’s Maxim «

Code: ,

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.


  1. From Stanislav Shalunov’s Musings on Protocol Design
    Be liberal—or not
    This is the most harmful part of the conventional wisdom. This is not how you make protocols interoperate; this is how you make them interoperate poorly, while burying booby traps for the future.
    Be pedantic in what you send and fascist in what you accept.

    The good protocols (IPv4, IPv6, BGP, etc.) are actually not at all liberal in what they accept. Being liberal in what you accept gives you HTML/HTTP.

Leave a Reply

Your email address will not be published.