Postel's liberality rule
david-sarah at jacaranda.org
Fri Jun 5 18:13:15 PDT 2009
John Cowan wrote:
> David-Sarah Hopwood scripsit:
>> (Note that this is somewhat different from Postel's "be liberal in
>> what you accept" rule, because it is specifying *precisely* what must
>> be accepted, and requiring everything else to be explicitly rejected.
> That was, indeed, the original force of Postel's Law.
That isn't what Postel said, and actually I don't think (considering
the context) it is even what he intended.
RFC 760 - DoD standard Internet Protocol:
# 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 793 - Transmission Control Protocol:
# 2.10. Robustness Principle
# TCP implementations will follow a general principle of robustness:
# be conservative in what you do, be liberal in what you accept from
Note that there is no specification here (or elsewhere in these RFCs)
of what behaviour should be accepted; for example IP specifies only
the set of datagrams that are "well-formed", not the set that should be
accepted. That is, the principle is not just about the possibility of
accepting a larger (but still explicitly specified by the protocol
standard) set of inputs than you produce as output. It *is* about
accepting some unspecified set of inputs "where the meaning is still clear",
in the opinion of each implementor.
In particular, the intent is not just that, say, an IP stack is not
supposed to fall over completely as soon as it receives an ill-formed
datagram. "Accepting" a datagram means more than just tolerating (e.g.
dropping) it. Microsoft's implementation notwithstanding, it would have
been taken as a given even in those days that IP stacks should not fall
>> I do not accept the validity or wisdom of Postel's liberality rule
>> when it is applied to unspecified inputs.)
> It never meant that except in the minds of demented HTML parser authors,
> including me. :-)
Unfortunately I think you're wrong -- not only is that what it originally
meant, that is how it has been interpreted by the majority of protocol
designers and implementors who follow or propound it. I believe this has
done immense damage to the design, and the implementation complexity of
numerous protocols and formats, not just HTML (even if HTML is one of
the most blatant and egregious examples).
And yes, we are still on topic for es5-discuss :-) (Section 16, cough.)
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
More information about the es5-discuss