Joe,
I think we are in agreement -- we have been so far-- but let me
add a real world example that might help clarify some of this.
--On Thursday, June 22, 2017 13:29 -0700 Joe Touch
<touch(_at_)isi(_dot_)edu> wrote:
...
We have tried to be liberal in DNS protocol in last 25 years.
It resulted in humongous mess which in the end forces sender
to do multiple guesses until he finds meaning of particular
"symbol" for that particular "receiver".
IMO, you're overdoing the "liberal in what you receive".
Liberal means that if it's possibly valid, you should accept
it as such. It does not mean that all ambiguous messages need
to be handled in the best possible light.
I would have been even more restrictive and said "possibly valid
and generally unambiguous". Taking SMTP as an example, not just
because because it is one of the classic robustness principle
cases but because there is a long history of reasonable
applications of the principle and an equally long on of
unreasonable applications including situations in which senders
have claimed "be liberal about what you accept" allows them to
send complete nonsense and, if things then don't work, to claim
that is the receiver's fault (see my earlier comments about
common sense).
Prior to the introduction of the extension mechanism in RFC
1651, the spec said that the command that specifies recipients is
RCPT TO:<forward-path>
Now, putting a space after the colon is a really common error.
The robustness principle is properly applied to just let that
go; there is no possible ambiguity about what was intended. I
don't recall ever seeing "RCPTTO:", rather than "RCPT TO:", but
accepting it in the name of liberal acceptance would be
similarly reasonable although I'm not sure it would justify
redesigning a command parser just to allow it.
The question of whether the receiver should generate an error
reply if the brackets are omitted or should just assume them was
an argument that went back and forth for years. It is an odd
case, because they are less easily overlooked in the specs than
someone not reading the BNF (821) or ABNF (2821 and 5321)
carefully enough. But that is connected to another issue with
the robustness principle that I don't think has been discussed:
For some years, there were a few SMTP implementations around
that assumed that, since the syntax was as above, they could put
things into the command after the forward path and closing
bracket and have them treated as comments. It got all the
predictable reactions: Some servers (receivers) just didn't
notice anything past the ">" and hence applied liberality in
acceptance accidentally. Others applied it deliberately on the
assumption that ignoring noise was reasonable. And still
others generated syntax replies, perhaps on the theory that
additional text might be an extra address or something else they
didn't know how to handle reliably. Those choices needed to
come to an end with RFC 1651 because we needed to allow text
after the ">" for something specific. That forced us to invent
a new session-starting verb rather than just dropping extra
syntax at the end, but that was (at least IMO) a relatively
small price to pay for giving receiver implementations (who
would be blamed, fairly or not, if messages didn't go through)
permission to use their judgment about how flexible to be.
Let's say that DNS says "all domains are lowercase, dash, and
dot", and you get uppercase. Sure, maybe that means convert to
lowercase. It also means you should not crash if you get some
other character that isn't valid - but it also does not mean
that you strip invalid characters and provide a response
anyway. Maybe a trailing CR, LF, NL, etc., but not much else.
Somewhat in parallel with the SMTP case, it also doesn't mean
that, when "lowercase" doesn't automatically mean "lowercase
ASCII letters", that, in the general case, you don't get to
receive "á" or "č" and decide that the accent and caron are
superfluous so you can change them to, or interpret them as, "a"
and "c". But, again, "be liberal" means to exercise
reasonable judgment about flexibility of interpretation. It is
a requirement for thinking and understanding, not a requirement
that one be stupid or irresponsible.
So if that's the point, I do agree - it's possible to overdo
the Postel Principle, but IMO that usually requires deliberate
intent to make a mockery of what is otherwise a generally
useful principle.
Yep.
john