Naughty protocols, need spanking

I have previously mentioned Joel Spolsky’s brilliant post about standards. If you’ve not read it yet, it is really worth your while. In that post he quotes Jon Postel‘s robustness principle and Marshall Rose’s critique:

Counter-intuitively, Postel’s robustness principle (”be conservative in what you send, liberal in what you accept”) often leads to deployment problems. Why? When a new implementation is initially fielded, it is likely that it will encounter only a subset of existing implementations. If those implementations follow the robustness principle, then errors in the new implementation will likely go undetected. The new implementation then sees some, but not widespread deployment. This process repeats for several new implementations. Eventually, the not-quite-correct implementations run into other implementations that are less liberal than the initial set of implementations. The reader should be able to figure out what happens next.

The reader should, but I’m not sure Rose got it right. “What happens next” is that both implementers receive complaints from their customers, and force their implementation to be more lenient. Then they encounter another variant, and have to account for that as well. As time goes by, the protocol stacks have to account for so many different implementations that the decoder has to run around in circles just to decode a message. Rose argued, “Explicit consistency checks in a protocol are very useful, even if they impose implementation overhead”, not realizing that the lenient implementation ends up imposing an even greater overhead. Even implementations that start out righteous and unforgiving end up joining the mass majority of lenient decoders, simply because they end up paying the price for their rigidity, when it should be the “misbehaving” protocols that should be punished. A scene by Monty Python springs to mind:

DINGO: Oh, wicked, bad, naughty, evil Zoot! Oh, she is a naughty person, and she must pay the penalty — and here in Castle Anthrax, we have but one punishment for setting alight the grail-shaped beacon. You must tie her down on a bed and spank her!

GIRLS: A spanking! A spanking!

DINGO: You must spank her well. And after you have spanked her, you may
deal with her as you like. And then, spank me.

VARIOUS GIRLS: And spank me.

And me.

And me.

DINGO: Yes, yes, you must give us all a good spanking!

GIRLS: A spanking! A spanking!

- Extract from “Monty Python and the Holy Grail“, Scene 11

Text-based protocols suffer the most from this. I’m not sure why, but it seems like the greatest advantage of text-based protocols, is that they may be read by humans, which leads programmers to believe that if they can understand it, so should their implementation. Alternatively, it may just be too complicated to decide which implementation is the “wicked, bad, naughty, evil” implementation that should be spanked until it behaves. Perhaps, like Joel says, “since nobody has a way to test against the standard, it’s not a real standard: it’s a platonic ideal and a set of misinterpretations”. That leaves implementers to support both ways.

The question is, what can be done about this? Can a standard be formulated in a strict enough way so that little to no misinterpretations are possible? Of course, it can - most binary standards are formulated strictly enough. Moreover, with binary standards, in case of misinterpretations, it is usually easy to determine which side should be spanked. I am sure it is possible to write a set of rules to narrow down the range of possible errors for text-based protocols as well. It is more a matter of making the cut, than where the cut is, and in the end, everyone benefits: implementations will be come more efficient, and the standard will become more robust.