[jbert]

As a counterpoint, perhaps it is reasonable, if interpreted more strictly.

Taking the perl-over-c-stdlib example (but I think it applies in other cases), if the "perl layer" was more strict in what it sent to the stdlib layer, there would have been no problem.

i.e. the error is in thinking of only the network as the place to apply the maxim. In fact, you should scrupulously adhere to every interface you pass data to (internal or external) - and interpret as reasonably as possible all interfaces you receive data from.

[I'd agree that the latter pt can be weakened. But it does help interop - and if you clean up your act before you hit the next layer then you limit any damage.]

[DanBC]

Postel wrote it in 1980. (First found in RFC760[1])

Since then we've had computer viruses, worms, and other malware; we've had hackers, crackers, spies, criminals, and semi-competent people flooding the Internet; we have people not just making accidental requests but fuzzing and fusking to try to break things or bypass controls.

It's a great principle for the human stuff, but it feels really outdated for technical stuff.

[1] (http://www.ietf.org/rfc/rfc760.txt)

[_delirium]

I agree, Postel's principle makes a lot of sense in context, if you view it as a bunch of mostly good-faith people attempting to bootstrap communication in a new medium. Then it's clear that to get things working, you want to forgive errors on the receiving side (to the extent you can do so), but send as clean and unproblematic output as you can. Basically what a sensible, not-anally-bureaucratic human who's trying to establish communication would do. It was also, iirc, influenced by some of the difficulties ARPANET had experienced in getting different implementations to interoperate. But it may make less sense today.

[ams6110]

Agreed. Today, I think "fail fast" is a much better principle.