On Fri, 11 Jul 1997 07:27:52 +0800 (GMT) Edward M Greshko
<Edward(_dot_)M(_dot_)Greshko(_at_)cdc(_dot_)com> wrote:
Of course this is not quite related to SMTP......
good. see below.
There is a quote by someone from a time long ago which goes along the
lines of being conservative in what you generate and liberal in what you
receive. In other words, make sure that you follow the specs to the
letter in what you generate, however try to deal with anything reasonable
that you can anticipate being thrown your way.
I need to know the exact quote and the author. If it is documented
someplace that would be "nice" too.
As Tim Goodwin pointed out, the first written form of the
comment (that I know of) is in RFC 1123. The quote itself
is due to Jon Postel, a _lot_ earlier -- it has been
floating around since the early 80s or earlier.
As Tim suggests, you need to be quite careful about the
quotation and its applicability. It was intended, more or
less, as a "smoothing principle: Traditionally, we don't
do precise specifications for Internet protocols,
especially at the applications level. Instead, we have
tried to make things easier to write and understand with
less-than-precise syntax rules, a certain amount of
handwaving about semantics, general assumptions about
goodwill, etc. That is typically ok, if there is some
rule about how to handle all of the ambiguities. The
robustness principle was, more or less, intended to cover
those cases, i.e., if it was possible to read a particular
provision in different ways, the sender was expected to
read it in the narrowest way feasible while the receiver
was expected to give it the most relaxed and broad reading
that was feasible. I.e., senders are required to read and
follow the specs closely; receivers are to anticipate
senders who don't. Virtually every time one looks at a
terrible implementation of an Internet protocol that seems
to work anyway, the underlying cause is proper behavior
using the robustness principle.
The problem is that it has been used to justify incredible
nonsense, including software authors who have taken the
position that receivers are obligated to accept any
foolishness that is thrown at them (and therefore the
sender is permitted to send such foolishness). That was
never the intent, and some of us have argued in a number of
specific cases for dropping the robustness principle in
favor of a "if bad stuff comes in, bounce it" model, just
on the grounds of cleaning up/ preserving the
infrastructure.
john