[zAy0LfpBZLC8mAC]

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.

[SigmundA]

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...

[zAy0LfpBZLC8mAC]

What is your argument here?

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.)

[SigmundA]

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?

1. https://tools.ietf.org/html/rfc761#section-2.10

[zAy0LfpBZLC8mAC]

> 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?

Relevant ... for what?

[SigmundA]

>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".

Thats not reality, if everyone got perfect formed input we wouldn't be having this debate, the reality is it occurs, so what do you do, reject it or accept it and try and do something with it. XHTML simply rejects malformed markup and you get a blank page, HTML tries to make sense of it and render something.

>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.

So you never heard of ECN? The ECN bits being set where technically incorrect depending on how pedantic you where in the interpretation and some stacks rejected packets if the bits weren't set to zero. Due to he robustness principle most stacks ignored these bits allowing others to use them for ECN, allowing a graceful update to the spec. The stacks that took your stance however and rejected where simply roadblocks in the adoption.

>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.

I'm not ignoring anything, I am just pointing out reality, the real world is messy and the stacks that try to keep working under messy conditions seem to be prevailing. Its not pretty and I don't deny the issues that arise, but here we are communicating on the largest most successful computer network ever built using a protocol and a markup language built with Postels law in mind.

>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.

I think most who know the history there would disagree with this opinion [1], it was obvious to me at the time why XHTML would fail even though I thought it a cleaner solution, I realized thats what was holding it back. It was much better to see your page come up with maybe a weird rendering artifact than just have the browser render nothing and throw an error if some small part was malformed.

>How does that follow? And what does that have to do with anything?

Because complaining about security vulnerabilities found in some of the most used software in the world while comparing to something that no one uses doesn't help your point.

>Relevant ... for what?

Uh gee I don't know maybe Postel's law is kinda relevant when discussing TCP because Postel wrote the spec you know like what you asked in the post before? What kind of game are you playing here?

1. https://thehistoryoftheweb.com/when-standards-divide/

[zAy0LfpBZLC8mAC]

> Thats not reality, if everyone got perfect formed input we wouldn't be having this debate,

Erm ... you do understand that, you know, there is feedback involved in this? That I am obviously not saying that noone would ever have typed broken HTML into a file if browsers had rejected broken HTML from the start?

I mean, it's even the norm for implementations of other computer languages to be rather strict about syntax, and it doesn't hinder their popularity with the same audience. The exact same people who produce garbage HTML do so using Perl or PHP or Ruby or ... whatever. And whatever you otherwise think about those languages, none of them will just make shit up when there is a syntax error in your program, they will simply reject it. And no, that does not mean that I am claiming that noone has ever made a syntactical mistake when writing code in those languages. But, you know, people are actually capable of fixing those mistakes when they are pointed out to them.

> So you never heard of ECN? The ECN bits being set where technically incorrect depending on how pedantic you where in the interpretation and some stacks rejected packets if the bits weren't set to zero. Due to he robustness principle most stacks ignored these bits allowing others to use them for ECN, allowing a graceful update to the spec. The stacks that took your stance however and rejected where simply roadblocks in the adoption.

Erm ... what? That's almost fractally wrong!?

None of the ECN problem was one of pedantry, it was simply one of a broken specification, namely the TCP specification. "Reserved for future use. Must be zero." is simply a bad specification. If you specify an extension mechanism, you have to always specify how the extension mechanism is supposed to work. What you call the pedantic interpretation is a perfectly valid interpretation of what the text says. You are just looking at it in hindsight, with the idea that it's supposed to support the operation of ECN, and then it's obviously a problem--but people who implemented TCP stuff before there was ECN could not possibly know that that is how people would expect to use this if the TCP specification doesn't specify that. There is nothing wrong with extension mechanisms that work by having the recipient discard messages with flags it doesn't know. That's just not what ECN chose to do, but that is kinda ECN's fault. You might just as well have ended up with a situation where someone would have tried to build an extension that assumes that recipients discard segments with unknown flags, and everyone would have been pointing fingers at those who chose to ignore the flags instead, and how they were pedantic to ignore the flags just because the specification does not explicitly say that such segments are invalid. It's just an accident of history that most implementations chose to ignore unknown flags, and therefore people now point to the exception, without any basis other than them being the majority.

Also, obviously, the "robustness principle" did not allow for a graceful update to the spec. The fact that a graceful update was not possible is the whole reason why you mentioned ECN at all. And that is not necessarily a result of failing to follow the robustness principle, as the robustness principle really doesn't tell you anything useful. All you can do with it is to point at things in hindsight and say "if everyone had built this the same way, then things would be compatible now!" But the robustness principle is useless for actually achieving that. For any format specification, there is an almost infinite number of ways you can deviate from the specification where humans could look at any individual one of those deviations and come to an agreement as to how that deviating message could reasonably be interpreted. And any one of those deviations could in principle be implemented as part of the corresponding parser. But implementing a parser that "correctly" interprets all of those possible deviations is at the very least a major undertaking, and usually even impossible due to contradictions between various deviations when they appear in combination.

And that is why hindsight is misleading: In hindsight, you only see one particular (small set of) deviation(s) causing interoperability problems, and it would almost always have been possible to make every parser coherently interpret those deviations just fine, and if everyone had done that, then you would not have any interoperability problems. But that isn't the perspective of someone who initially builds the implementation. They can only either strictly follow the spec (which works perfectly if everyone does so and the spec isn't broken) or they can increase complexity of and effort required for their implementation an order of magnitude or more to accept close to anything that could happen (which noone does for obvious reasons) or they can implement a random selection of deviations they like (which then leads to interoperability problems and the view in hindsight that everyone else could easily have done the same, which, of course, they couldn't, because they couldn't know what others were doing). Of course, there is a simple solution to that last approach: If you want to implement deviations from the agreed-upon spec but you don't want to run the risk of creating interoperability problems, you could get together with all the other implementers and talk about which deviations everyone is going to implement. But obviously, that's just the first approach in disguise: After you have agreed on the deviations, they aren't deviations anymore, you have simply created a new spec, and everyone then strictly follows that new spec.

Essentially, what is happening here is that you see one interpretation of something that the spec doesn't actually specify as obvious. And then you claim that the solution to interoperability problems is that everyone does the obvious thing. But you fail to recognize that the whole problem we are trying to solve with specifications in the first place is that what seems obvious is different for different people. Which is why this (a) can not work and (b) obviously in practice does not work. You can not solve the problem of people having different approaches to problems by simply saying "they should just all have the same approach" while at the same time saying that methods to create agreement (i.e., specifications) should not be taken too seriously.

> I'm not ignoring anything, I am just pointing out reality, the real world is messy and the stacks that try to keep working under messy conditions seem to be prevailing. Its not pretty and I don't deny the issues that arise, but here we are communicating on the largest most successful computer network ever built using a protocol and a markup language built with Postels law in mind.

Then your points are just irrelevant? I never said that broken systems can not be successful, did I? Yes, there clearly are evolutionary advantages to externalizing costs, and taking risks can pay off. But there are also other parties who have to pay those externalized costs, and taking risks can also end in a catastrophe. Externalizing costs is still an asshole move (and is generally frowned upon by society when people understand that that is what is happening) and whether the risks taken by the web, for example, have actually paid off is far from obvious.

Also, possibly all of this was built with Postel's law in mind. But what I would be interested in is whether that was to our benefit. Just because something was a factor in creating a certain overall positive situation does not mean that therefore that factor made that situation better than if it hadn't been there. In particular, evolutionary success does not mean that a different approach would not have produced a better result.

> I think most who know the history there would disagree with this opinion [1], it was obvious to me at the time why XHTML would fail even though I thought it a cleaner solution, I realized thats what was holding it back. It was much better to see your page come up with maybe a weird rendering artifact than just have the browser render nothing and throw an error if some small part was malformed.

How does that contradict what I said? Yes, it was obvious that XHTML would fail due to the massive incompetence of developers ... your point being?!

> Uh gee I don't know maybe Postel's law is kinda relevant when discussing TCP because Postel wrote the spec you know like what you asked in the post before? What kind of game are you playing here?

I am not sure what kind of game you are playing, but I had the impression like you were trying to make a point and not just state the historical fact that that's where Postel formulated the "robustness principle". Yeah, I agree, that's what he did. And it was a bad idea.