Hacker News new | past | comments | ask | show | jobs | submit login

It's a pity so many people grossly misunderstand Postel's Principle.

Postel didn't talk about off-spec behaviour. He talked about the borderline details, which were often quite hazy in early RFCs. When an RFC says the line length is at most 512 bytes and the terminator is CRLF, does that mean 510+CRLF or 512+CRLF? Postel says to accept 512+CRLF and send 510+CRLF.

If a write a receiver and want to accept 1024 bytes instead, maybe that's a good idea and maybe it's a bad idea. But if you do that, don't invoke Postel's Principle in defense.




As some one who used to work on OSI based systems well thats just sloppy standards writing the bane of internet standards.

Its a pity that RFC's and other internet standards are not written and implemented more rigorously - for example Google have problems interpreting the xml sitemap standard and that is only 3 pages FFS.


I've written ten RFCs of varying quality. It's terribly difficult to write something that a) gives a good overview of the subject, b) explains the choices that had to be made, c) spells out every detail, and d) remains short enough that implementers actually read all of it. All of mine fail in some way. I've heard the OSI documents failed too.

Quoting one implementer, whose code did not accept non-ASCII passwords: "Oh, the password syntax is on page 88? My printout ends after page 68". In that RFC, the details are spelt out in appendices, and Appendix A starts on page 69. (And I'm sure pg assigns bonus karma if you can identify the RFC.)


Is there any way to request an official clarification for borderline cases the RFC-author didn't think about when typing it up?


You can submit an erratum and an author will comment and often clarify, so formally speaking the answer to your question is yes. But other implementers don't generally read the errata, so you have to expect that your interoperation peers haven't read the clarification.

Once you understand the problem, the clarification, and that your interop peers do not, I bet your implementation's handling of the issue will be conservative in what it sends and liberal in what it receives.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: