Re: Need the quote and the author

[John C Klensin <[e-mail]>]

On Fri, 11 Jul 1997 07:27:52 +0800 (GMT) Edward M Greshko 
<[e-mail]> 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