No, it's terrible advice as it only causes unnecessary interoperability problems and vulnerabilities. There is no reason why anyone should need to generate invalid input to your program and it is never a better idea to make every consumer more complex to deal with broken input than to make one producer create non-broken output.
The only robustness to invalid input you should have is that you should not fall over when you encounter broken input, but simply reject it.
Both TCP which Postel wrote the spec and HTML follow this principle so it it seems have its merits.
You know what followed your principle? XHTML...and the arguments were the same, its not well formed just reject it, why would you ever accept broken input.
Sure it makes parsing faster and simpler and yet what actually works and is robust in the real world, HTML...
That HTML is a platform with an extraordinary security track record? Noone has ever exploited all the ambiguities that result from the incoherent mess that is the web?
Or is it that we never had any interoperability problems with HTML? All browsers always reliably rendered websites consistently? "This website is optimized for IE" never happened?
How isn't that just the best example to support my point?
As for TCP ... how is it relevant that Postel wrote the spec? Does that mean that the vulnerabilities in TCP never happened? Or are you saying that modern TCP implementations try to accept any crap whatsoever? (No, they don't, of course they don't, people have actually learned that that's a bad idea.)
People seem to prefer web sites that render inconsistently rather than not at all because of one little issue in the markup. It is more robust to render something rather than nothing and is one big reason XHTML was abandoned.
Yes a system that no one uses is more secure than one everybody does.
Postel's Law is literally in the TCP RFC [1], don't you think that makes it relevant?
> People seem to prefer web sites that render inconsistently rather than not at all because of one little issue in the markup.
Except those are not the alternatives. The alternatives are consistently rendered websites or inconsistently rendered websites. If browsers had strictly enforced HTML syntax from the beginning, noone would ever have built websites with "little issues in the markup".
IP stacks do not accept randomly misformatted IP packets. The result is obviously not that you constantly encounter internet services that you can not access because your IP stack is picky about broken IP packets, the result is that noone ever sends you broken IP packets.
> It is more robust to render something rather than nothing
No, it just isn't. You are just looking at a very small part of the consequences of this implementation strategy that indeed happens to be positive, but completely ignoring the big picture of all the externalities and other indirect damage that result from it.
> and is one big reason XHTML was abandoned.
Erm ... no? The reason why XHTML was abandoned was because people are incompetent at writing software, and there existed an alternative that allowed them to keep their idiotic practices, including all the vulnerabilities and interoperability problems that result from those, so that's what people did.
> Yes a system that no one uses is more secure than one everybody does.
How does that follow? And what does that have to do with anything?
> Postel's Law is literally in the TCP RFC [1], don't you think that makes it relevant?
It's good wisdom but beware the counter-argument. Being liberal in what you accept causes your implementation to have to maintain a wide range of implicitly defined odd inputs in perpetuity and leads to a form of lock-in based on handling of edge-cases. HTML and browser implementations that allowed all sorts of garbage behaviors are a good example of this. The robustness principle works, but it does come with a cost, like all things.
https://en.wikipedia.org/wiki/Robustness_principle
Having done plenty of interfaces between systems these are words to live by.