Postel's Principle was very important for bootstrapping adoption of TCP/IP, but it's mostly a curse in mature systems. It doesn't even help new implementors; instead, it deceives them into thinking that they've achieved interoperability when instead they've accidentally built dependencies on other people's implementation details.
That said, I wouldn't suggest that our Insertion, Evasion paper presented an argument regarding the Principle in either direction. Even if we forbad leniency, there'd still be ambiguous standards.
Vendor A writes a parser that is helpful and is liberal and infers missing quotes and stuff. Vendor B writes something that's mostly to spec, but accidentally doesn't properly quote things. It works fine, because A is liberal and infers these quotes.
Vendor C comes along and builds exactly to spec. But despite being perfectly to spec, it doesn't interop because B sends invalid data! But B is a big vendor, and their stuff works with A.
So now C must add a hack to their parser to deal with the fact that, because A was liberal, B got their implementation wrong.
One example is the loose routing parameter, "lr". It has no value, you just add the name of the parameter "uri;lr" in contrast to other parameters like "tag=bla". Some implementations send "lr=on", and that should be mostly harmless. Except other implementations take that to mean "lr" has a value, and no longer accept just "lr" as turning the feature on.
SIP is full of these things, many of them in the parsing layer alone, let alone actual semantics of what things mean. Browsers are another example: vendor A decides to allow closing tags out of order - how do you do handle such unspecified stuff cross browser?
I should do better than this, but my flight to SF takes off in just over an hour, so for now: the first paper this article linked to (I wrote it with Tim Newsham) is a study in how you can compare implementation details between two TCP/IP stacks and use them to sneak traffic past a middlebox that assumes one interpretation or the other. The example that comes to mind is putting data in a TCP SYN segment.
Windows software is a similar case - a program works on one version of Windows due to accidental dependencies on Windows implementation details (e.g. memory management), and then fails on the next version of Windows when the underlying implementation changes. Raymond Chen has written about the huge difficulty for Windows to maintain backwards compatibility with "broken" programs. New versions of Windows provide special-case handling for old applications so they will still run. See http://www.joelonsoftware.com/articles/APIWar.html and scroll way down to "The Two Forces at Microsoft" for a long discussion of this, and how Apple is much stricter.
In the terminology of this article, Torvalds is firmly in the Raymond Chen camp as far as "The kernel is not allowed to break user software" is concerned. The difference between Windows and Linux (and especially between Windows 95 era Windows and Linux of the same vintage) is, apparently, that Linux didn't come from MS-DOS, and so never had to allow application software to get hooks into low-level parts of the kernel.
There was never an official version of Linux for hardware without memory protection, and there never will be. Scope is important.
No this is actually very different. Linus doesn't want breaking API changes to documented behavior, in the Raymond Chen case its not breaking applications that misbehave or abuse undocumented behavior.
The point I was making was that Linux didn't expose the same kind of deep, undocumented behavior because, as I said, it always had the ability to hide its inner workings.
* A decent chunk of email server code (SMTP & IMAP implementations in particular) is there to handle erroneous client behaviours. The worst cases are those where the workaround leads to misbehaviours (or less optimal behaviours) for conforming clients. If I remember correctly, the popular Outlook series of clients is a notorious source of such warts. A number of SMTP sender libraries will skip over significant parts of the protocol state machine; configuring a mail server to handle that degenerate case can weaken its anti-spam provisions.
Yes, there were major changes between the way IMAP worked in Outlook 2003 & Outlook 2007 too, I think they re-wrote their IMAP code as it behaved completely differently. Admittedly it was much better, but it broke our custom IMAP server which I ended up fixing. I can't remember exactly why now, but Outlook 2003's implementation was bizarre, as if they'd not read the RFC.
That reminds me of the bizarre big because they used a short uint to store the message UID. Maybe it wasn't a short but it definitely wasn't 32-bit as per the spec, there was some magic number that if you went over 'boom'. As an end user it appeared that some messages just disappeared.
HTML (and the Web in general) has many, many examples of this, for example the way we parse <i><b>x</i></b> is required to be compatible with pages that relied on the way early browsers did it. In fact almost all of the Web's quirks are because of this.
That said, I wouldn't suggest that our Insertion, Evasion paper presented an argument regarding the Principle in either direction. Even if we forbad leniency, there'd still be ambiguous standards.