Re: Need the quote and the author

Edward M Greshko <> Thu, 17 July 1997 03:03 UTC

Received: from cnri by id aa27626; 16 Jul 97 23:03 EDT
Received: from ( []) by (8.8.5/8.7.3) with ESMTPid XAA10381; Wed, 16 Jul 1997 23:02:33 -0400 (EDT)
Received: (from majordomo@localhost) by (8.8.5/8.7.3) id TAA03632 for ietf-smtp-bks; Wed, 16 Jul 1997 19:44:38 -0700 (PDT)
Received: from ( []) by (8.8.5/8.7.3) with ESMTP id TAA03628 for <>; Wed, 16 Jul 1997 19:44:33 -0700 (PDT)
Received: from by; Thu, 17 Jul 1997 10:47:06 +0800
Date: Thu, 17 Jul 1997 10:47:06 +0800 (GMT)
From: Edward M Greshko <>
To: John C Klensin <>
Subject: Re: Need the quote and the author
In-Reply-To: <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk

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