The Universality of Postel's Law

Design is deep topic. One could say it’s the deepest. It’s about making decisions that affect choices in the world. When you design a chair, what you’ve really done is make a set of choices about how people using it will sit and what their experience will be. People sitting on chairs have choices too. They can defy your expectations by turning the chair on its side and sitting on it that way. That makes them designers as well. Design is a wonderful interactive game.

Below this game, there is a deeper game. It’s the game of principles that help us create stable processes that run in the world, and it’s rather sublime.

One of my favorite examples of this is Postel’s Law. Sometimes it is called ‘The Robustness Principle’, but I think that Jon Postel deserves to have his name attached - it was a tremendous insight. Postel was an instrumental figure in the early days of the internet. Aside from his Law he is probably best known for the DNS Root Authority Test - a courageous act that was equally sublime.

History and biography aside, Postel’s law was a simple observation that he made about networking. In an early internet RFC he said "an implementation should be conservative in its sending behavior, and liberal in its receiving behavior.” This has been paraphrased over the years as “Be liberal in what you accept, and conservative in what you send” and for people who are mathematically inclined: “be contravariant in your inputs and covariant in your outputs.”

What does all of this mean?

Well, the thing that Postel was trying to do is articulate a principle that would help the internet grow. If every node were unforgiving with respect to input errors, the internet would’ve been brittle. Having a little bit of tolerance when you receive inputs, being able to carry on in the face of minor formatting errors, makes the overall system more robust.

The thing that I don’t think many people appreciate about Postel’s Law is its universality. In software, it’s not just about creating components for a network. You see Postel applied in command line utilities in Unix. Many of them are tolerant at input and very regular at output. This allows us to string them together with reasonable assurance that the composition will work. You can also see it at work in the HTML rendering engines of browsers. Browsers have historically been remarkably tolerant of ill-formed HTML and that allowed the web to grow tremendously fast.

We can see Postel in the physical world too. Every time you see a PVC pipe with a flanged end, you’re seeing something that serves as a decent visual metaphor for Postel’s Law. Those pipes fit well together because one end is more accepting. In fact, it’s almost as if they have a magnetic attraction toward attachment. They are certainly built for it. It may seem weird to use this sort of physical analogy - pipes have nothing to do with errors - but still there is this notion of accepting more on one end than the other. It aids composition.

Here’s another example that shows the dynamics of Postel. Imagine being in a room full of language translators. Each translator can either understand one language and speak one another, or understand multiple languages and speak one. It’s likely easier to get from an arbitrary language A to an arbitrary language B using a chain of translators of the latter type than the former.

The galvanizing force behind Postel is the narrowing that happens between the input and the output. In physical terms it is a lessening in size but in information terms we can see it as an analog to lessening of bad variation. The world of information is chaotic. Errors creep in, but if every component takes the opportunity to make things a little simpler or cleaner, it acts as a counter-balance to those errors. In the aggregate, systems become more robust.

Depending upon how much abstraction and analogy you care for, this article is a bit of a wild ride. I’ve drawn a comparison between an information systems principles and the physical world. Let’s go further and extend it to social systems.

Societies often have the notion of ‘good character.’ We can attempt all sorts of definitions but at its core, isn’t good character just having tolerance for the foibles of others and being a person people can count on? Accepting wider variation at input and producing less variation at output? In systems terms that puts more work on the people who have that quality - they have to have enough control to avoid ‘going off’ on people when others ‘go off' on them, but they get the benefit of being someone people want to connect with. I argue that those same dynamics occur in physical systems and software systems that have the Postel property.

Postel’s Law is not without controversy. If you search you’ll find a lot of criticism. The primary argument is that when components accept loose specifications they invite bad practice. It’s almost like the concept of ‘moral hazard’ in economics. The classic example of this is, again, web browsers. The number of odd cases browsers dealt with in the growth years of the web was staggering, and you could get just about anything that was HTML-like to render. As a result, browser rendering code became some of the most complex and exceptional-case ridden code on the planet. But, in exchange, the web grew swiftly. Over time, browsers have started to tighten the reins. That sort of thing can happen slowly after a growth period. But it doesn’t always. The question is whether accelerated growth is worth it. In manufacturing, we’ve achieved incredible efficiencies by reducing tolerances. Clearly, a different strategy but not one that seems able to achieve the same kind of infectious growth as Postel.

So far I’ve been talking about Postel’s Law as it is a conscious strategy, but it works even if it isn’t. I don’t think browser developers were thinking about input tolerance through the lens of Postel, although they knew that it was a competitive advantage.

I suspect that Postel structuring is prevalent because it is stable under selection. Think about it in these terms: if you have N components with the Postel property and one without, meaning that it is very strict in its inputs, when people are given a choice, they’ll be likely to reject the stricter input component and select a more tolerant one. It’s just less of a headache. To me this seems like an obvious point, but no doubt someone could run simulations to learn more.

In any case, I think that Postel’s Law is rich. It’s like many other systems principles - once you internalize it you can use it in design. It becomes another tool in the toolbox.