Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Postel’s Principle is a Bad Idea

programmingisterrible.com

Post reply on HN
Print view View original

31–40 of 62 posts

Re: Postel’s Principle is a Bad Idea

#31

Post by othermaciej »

This post, if you read it to the end, doesn't reject the principle of being liberal in what you accept. Rather, it proposes being liberal in a formally specified an interoperable way - i.e. specs should explicitly define behavior for all inputs, including any error correction.

HTML5 takes this path with its parsing algorithm, and in fact is cited as an example in the post. However, the designers of the parsing algorithm saw it as being an application of Postel's Principle, rather than an example of the opposite.

The post is really more nuanced than it sounds and would better be titled "Specifications Should Define How to be Liberal in What You Accept".

Re: Postel’s Principle is a Bad Idea

#32

Post by othermaciej »

MichaelGG wrote: post #20
mmahemoff wrote: post #18

Browser tolerance for HTML errors is one of the main reasons the web took off so fast.

Citation needed? Is there any reason to believe that if the browsers had insisted on wellformed documented and provided errors like "error at line X, table tag not closed" that people would not have been able to fixup documents? I don't believe that's would have stopped things. But that exact behaviour, trying to infer intent, meant that tons of unspecified behaviour had to be added to all browsers to try to mimic wh…

We've tried this experiment - it's called XHTML. For a long time, adoption by authors of the strict error handling it offered was stymied by lack of support in MSIE. So it's not a full counter-factual. However, we have learned two things:

(1) Now that MSIE does support true XML parsing of XHTML, almost no one is choosing to use it over HTML.

(2) Of the few experts who conditionally served either text/html or application/xhtml+xml depending on the UA, or serve XML unconditionally now, almost all have bugs in their sites which can get them to produce ill-formed XML which then shows an error page in the browser (for instance, submitting comments with certain sorts of errors). This is evidence that the draconian error handling approach is too challenging even for experts and imposes the costs of small mistakes on users.

Re: Postel’s Principle is a Bad Idea

#33

Post by Hixie »

gruseom wrote: post #3
tptacek wrote: post #2

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 re…

when instead they've accidentally built dependencies on other people's implementation details I think it would be very interesting if you could give an example or two of this.

HTML (and the Web in general) has many, many examples of this, for example the way we parse x 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.

Re: Postel’s Principle is a Bad Idea

#35

Post by salgernon »

btilly wrote: post #27
MichaelGG wrote: post #14

The authors of the SIP spec published another spec (RFC4475[1]) called "SIP torture tests", where they seem to take a perverse glee in showing how messed up their "human readable" syntax can get. They even use the phrase "infer" in several places, encouraging systems to take obviously malformed packets and try to figure out what they meant. Being liberal in accepting input, apart from security issues, seems to create…

I can't read this comment without thinking about SOAP.

I could kiss you for that.

If the use of a format for interoperability can only be reasonably used by a single vendor, it has no benefit over a binary protocol.

The entire SOAP and XML-RPC space is postels law writ large.

Re: Postel’s Principle is a Bad Idea

#38

Post by gbog »

I am reminded of the discussion we had with colleagues about Markdown versus RestructuredText.

On Markdown side, you have sexy but ill-defined grammar, and on RST you have a slightly less nice-looking guy with a much better defined grammar, which allow building a saner tooling upon it.

Re: Postel’s Principle is a Bad Idea

#39

Post by tedunangst »

barrkel wrote: post #26
MichaelGG wrote: post #20

Earlier quoted context omitted.

Citation needed? Is there any reason to believe that if the browsers had insisted on wellformed documented and provided errors like "error at line X, table tag not closed" that people would not have been able to fixup documents? I don't believe that's would have stopped things. But that exact behaviour, trying to infer intent, meant that tons of unspecified behaviour had to be added to all browsers to try to mimic wh…

A nontechnical user, given a choice between two environments, one of which nags them pedantically over technical details, and another which displays the gist of entered content but perhaps with sometimes screwy formatting which one would win? Word processors won out over text processors for the nontechnical user partially for this reason. Postel's law applied to HTML let nontechnical users get things done with less i…

Writing correct HTML is not significantly harder than writing crappy HTML. Comparing it to latex vs word isn't a good analogy IMO. And wouldn't nontechnical users be using higher level HTML editors anyway? At least some bad HTML comes from lazy developers who should know better, and could have done better with a stricter tool.

Re: Postel’s Principle is a Bad Idea

#40

Post by tedunangst »

othermaciej wrote: post #32
MichaelGG wrote: post #20

Earlier quoted context omitted.

Citation needed? Is there any reason to believe that if the browsers had insisted on wellformed documented and provided errors like "error at line X, table tag not closed" that people would not have been able to fixup documents? I don't believe that's would have stopped things. But that exact behaviour, trying to infer intent, meant that tons of unspecified behaviour had to be added to all browsers to try to mimic wh…

We've tried this experiment - it's called XHTML. For a long time, adoption by authors of the strict error handling it offered was stymied by lack of support in MSIE. So it's not a full counter-factual. However, we have learned two things: (1) Now that MSIE does support true XML parsing of XHTML, almost no one is choosing to use it over HTML. (2) Of the few experts who conditionally served either text/html or applicat…

I think the bigger lesson to be learned is that after poorly followed ad hoc standards have made a mess of things, it's hard to come in and clean up later.
Post reply on HN