This might brand me as a heretic, but I'll say it anyway.
I like brittle software.
Now, what I mean by that deserves some explanation, but
whenever I think of ideal software that does a job for me, I
of it as a harmonious blend of the robust and the brittle.
First, the robust. Software needs to check its buffer
sizes, check OS error codes, behave defensively and not
crash even if given complete garbage as input. This side of the
equation is very strongly linked to security. The software
should be impossible to use for malicious purposes due to a
bug in the code.
Another aspect of robustness is flexibility. It should put
the user in control, while defending the user from possible
mistakes he might make while learning to use the program, or
in just everyday use. It should be hard to use wrong.
The brittle side of software also shows up in its error
detection, and is a critical part of putting the user in
control. If there is an error, I want to know about it. If
the program is not absolutely certain that my data is safe,
I want to know. If an attacker is trying to use the program
me, I want it to complain loudly and often.
I would rather have the program stop running than harm my data.
Not every program can achieve these lofty goals, but this is
the nebulous image my mind creates when I think of ideal
software. Some of this comes from my background in writing
industrial network firmware, where it was better for
firmware to halt completely and go to a known safe state,
than to assume it knew what you meant and just let that
piston stay on your coworker's arm.
So bringing Postel's Law into the equation, there are places
where I definitely do not want my software to be liberal in
what it accepts. Take a git repository, for example. If
there is any remote possibility of data corruption, I want
to know, and I want git to refuse to proceed. Luckily, git
does a fantastic job of data integrity, which is one of the
reasons I like it so much.
Postel's Law was originally about TCP, and so pertains to
communication. Taking TCP as a specific example, and trying
to apply Postel's law, let's say that a packet arrives with
the entire TCP header shifted by 1 bit. I am no TCP stack
expert, but I would be surprised if any TCP stack would be
able to parse such a packet correctly. The only logical way
of dealing with such a packet would be to look at the
existing bits with the header format in mind, try to make
sense of the non-sensical data, and send back an error if
possible, or drop it on the floor.
How does Postel's Law fix a situation where the very format
of the data is not respected?
I can understand if there is a TCP flag that is out of
order, or if some unambiguous packet abnormality exists in an
incoming packet. But there are only a limited number of
such possible error combinations. Things have actually
progressed in the opposite
direction: TCP stacks have gotten more strict to deal with
various attacks, and firewalls are used to strictly guard
inbound and outbound traffic.
Being too liberal has a cost. And some costs are so high,
they are seen as a detriment to society. Just look at the
once-popular open SMTP relay.
Even in places where it would seem obvious that being
liberal in what you accept is a good thing, upon further
reflection, it turns out to be not so clean cut.
example, a corrupt OpenOffice document. The user definitely
wants to open it. Maybe some invalid XML is
getting in the way, or maybe the file is only half there.
What should OpenOffice do? It should make a best effort at
retrieving what data it can, and it should open the file
read only. It should also warn the user loudly that the file
was corrupt, invalid, and inaccurate. The user needs to
know this. This may be a file from an outside source, and
so the error is not important. But it may also be the first
error the user receives about a dying hard disk, or a bad
network, or a corrupted filesystem, and restoring from
backup is the next item on the agenda.
So in my frame of reference, Postel's Law, which is also
called the Robustness Principle, fits right in, but only to
half of my ideal software equation. Yes, be robust in what
you accept. Be able to process complete garbage input
without crashing. I've heard of people who fed a
program's own EXE into itself as test input. It should be
safe to use input data as a baseball bat and bludgeon the
program without it falling over.
Yet the Brittle half of ideal software doesn't change. It
is still as loud as before, warning the user of potential
pitfalls and trouble on the horizon, and will refuse to
proceed if it can't guarantee his data's safety or
determine his intent without ambiguity.
In the end, Postel's Law is too ambiguous to be a useful
guide, let alone a law. Those that accept it are too
liberal, and those that don't are too strict. :-)