Great point.
The original Usenet comp.mail.pine newsgroup post [1] by Mark Crispin (father of the IMAP protocol):
This statement is based upon a terrible misunderstand of Postel's
robustness principle. 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 don't give this reminiscence ANY credit. The very first version of Postel's law makes it VERY clear that Postel intended his law to deal with non-compliant behavior in a tolerant or "liberal" way: "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)."
See my potted history of Postel's law: http://ironick.typepad.com/ironick/2005/05/my_history_of_t.h...
Nice to see that so well documented: I'd only seen the one most common reference, RFC 793.
That said, it's still unclear how far this extends: the example given is of an unknown error code, which might lead you to think that the requirement is "syntactically well-formed input where you can't 100% determine the semantics." That's a far cry from the way browsers handle malformed HTML. Similarly, you have to apply some judgment concerning what an agent can interpret the meaning of.
The robustness principle is so compressed that it invites the reader to project an interpretation onto it.