Postel’s Principle is a Bad Idea

Re:Postel’s Principle is a Bad Idea by Arnt on Monday February 04, 2013 @08:23AM (#5163927)

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

[ Parent | on HN ]

Re:Postel’s Principle is a Bad Idea by im3w1l on Monday February 04, 2013 @02:07PM (#5166264)

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

[ Parent | on HN ]

Re:Postel’s Principle is a Bad Idea by Arnt on Tuesday February 05, 2013 @06:20AM (#5170117)

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.

[ Parent | on HN ]