Subject: Re: Need the quote and the author
From: Edward M Greshko <[email-masked]>
To: John C Klensin <[email-masked]>
Cc: [email-masked]
Date: Thu, 17 Jul 1997 10:47:06 +0800 (GMT)

On Sun, 13 Jul 1997, John C Klensin wrote:

> 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.

Thanks.  I did find Jon's original musing on the subject.

> 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.

Your points, and Tim's, are very well taken as I can certainly see how a
general statment like that can be taken to the *extreme*.

-- 
Edward M. Greshko                  Technical Manager, Electronic Commerce
                                   Control Data Asia/Pacific Region
Voice: +886-2-715-2222 x287        6/F, 131 Nanking East Road, Section 3
FAX  : +886-2-712-9197             Taipei, Taiwan R.O.C

Date: Sun, 13 Jul 1997 09:21:23 -0400 (EDT)
From: John C Klensin <[email-masked]>
Subject: Re: Need the quote and the author
To: Edward M Greshko <[email-masked]>
Cc: [email-masked]
Reply-to: John C Klensin <[email-masked]>
Sender: [email-masked]

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

To: Edward M Greshko <[email-masked]>
CC: [email-masked]
Subject: Re: Need the quote and the author
Date: Fri, 11 Jul 1997 10:58:57 +0100
From: Tim Goodwin <[email-masked]>
Sender: [email-masked]

> 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.

It's from Host Requirements, STD 3, RFC 1123.

>           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.

No, that's *not* what it means.  The Robustness Principle does not
justify ad hoc extensions to the specification (for example, sendmail
accepting `RCPT TO:[email-masked]').  Study section 1.2.2 of 1123
carefully.

Tim.

Date: Thu, 10 Jul 1997 21:55:41 -0400 (EDT)
From: "Donald E. Eastlake 3rd" <[email-masked]>
To: Edward M Greshko <[email-masked]>
Cc: [email-masked]
Subject: Re: Need the quote and the author
Sender: [email-masked]

Don't know where it started but it is included in RFC 1958, Architectural 
Principles of the Internet, in section 3.9.

Donald

On Fri, 11 Jul 1997, Edward M Greshko wrote: 

> Date: Fri, 11 Jul 1997 07:27:52 +0800 (GMT)
> From: Edward M Greshko <[email-masked]>
> To: [email-masked]
> Subject: Need the quote and the author
> 
> Hi,
> 
> Of course this is not quite related to SMTP......
> 
> 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.
> 
> Ed
> 
> 
> 

=====================================================================
Donald E. Eastlake 3rd     +1 508-287-4877(tel)     [email-masked]
   318 Acton Street        +1 508-371-7148(fax)     [email-masked]
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.eff.org/blueribbon.html

Date: Fri, 11 Jul 1997 07:27:52 +0800 (GMT)
From: Edward M Greshko <[email-masked]>
To: [email-masked]
Subject: Need the quote and the author
Sender: [email-masked]

Hi,

Of course this is not quite related to SMTP......

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.

Ed