My history of the (Internet) Robustness Principle.

Wed, 25 May 2005 10:06:37 GMT

[In making what I thought was a small update to my copy of a quotation of the Robustness Principle, I quickly fell down the rat hole of documenting as many versions of it as I could find. Here are the fruits of my labor. Full text of the RFCs can be viewed at the RFC Sourcebook. See also my earlier post regarding the Robustness Principle. I am posting this in monospace font in homage to the RFC style. (Besides, I'm too lazy to reformat.) I have to use the small font to make the margins fit. If you find it difficult to read, just cut and paste into your favorite editor (Notepad, Word, Emacs). -- NLG]

The Internet Robustness Principle: "Be liberal in what you accept, and conservative in what you send."

Attributed to Jon Postel. See the Postel Center In Memoriam web page: http://www.postel.org/postel.html

According to the Postel Center, the principle originated in RFC 760 "DOD STANDARD INTERNET PROTOCOL" (1980) using different wording:

3.2. Discussion

The implementation of a protocol must be robust. Each implementation
must expect to interoperate with others created by different
individuals. While the goal of this specification is to be explicit
about the protocol there is the possibility of differing
interpretations. In general, an implementation should be conservative
in its sending behavior, and liberal in its receiving behavior. That
is, it should be careful to send well-formed datagrams, but should
accept any datagram that it can interpret (e.g., not object to
technical errors where the meaning is still clear).

This may be the first RFC containing the principle, but two prior "Internet" specs contain the principle as well: IEN 111 "Internet Protocol" (August 1979) and IEN 123 " DOD STANDARD INTERNET PROTOCOL" (December 1979). The context and wording are identical, so the text is not quoted again.

It next appears in RFC 761 "DOD STANDARD TRANSMISSION CONTROL PROTOCOL" (1980), this time with the designation of "Robustness Principle":

2.10. Robustness Principle

TCP implementations should follow a general principle of robustness:
be conservative in what you do, be liberal in what you accept from
others.

Notice the switch from "sending behavior" to simply "do" and the switch from "receiving behavior" to "accept".

It also [next?] appears in RFC 791 "Internet Protocol" (1981), which obsoleted RFC 760:

3.2 Discussion

The implementation of a protocol must be robust. Each implementation
must expect to interoperate with others created by different
individuals. While the goal of this specification is to be explicit
about the protocol there is the possibility of differing
interpretations. In general, an implementation <> be conservative
in its sending behavior, and liberal in its receiving behavior. That
is, it <> be careful to send well-formed datagrams, but <>
accept any datagram that it can interpret (e.g., not object to
technical errors where the meaning is still clear).

Notice the change from "should" to "must".

It also [next?] appears in RFC 793 "Transmission Control Protocol" (1981). The context and wording are identical, so the text is not quoted again.

It also [next?] appears in RFC 1122 "Requirements for Internet Hosts -- Communication Layers" (1989)

1.2.2 Robustness Principle

At every layer of the protocols, there is a general rule whose
application can lead to enormous benefits in robustness and
interoperability [IP:1]:

"Be liberal in what you accept, and
conservative in what you send"

Software should be written to deal with every conceivable
error, no matter how unlikely; sooner or later a packet will
come in with that particular combination of errors and
attributes, and unless the software is prepared, chaos can
ensue. In general, it is best to assume that the network is
filled with malevolent entities that will send in packets
designed to have the worst possible effect. This assumption
will lead to suitable protective design, although the most
serious problems in the Internet have been caused by
unenvisaged mechanisms triggered by low-probability events;
mere human malice would never have taken so devious a course!

Adaptability to change must be designed into all levels of
Internet host software. As a simple example, consider a
protocol specification that contains an enumeration of values
for a particular header field -- e.g., a type field, a port
number, or an error code; this enumeration must be assumed to
be incomplete. Thus, if a protocol specification defines four
possible error codes, the software must not break when a fifth
code shows up. An undefined code might be logged (see below),
but it must not cause a failure.

The second part of the principle is almost as important:
software on other hosts may contain deficiencies that make it
unwise to exploit legal but obscure protocol features. It is
unwise to stray far from the obvious and simple, lest untoward
effects result elsewhere. A corollary of this is "watch out
for misbehaving hosts"; host software should be prepared, not
just to survive other misbehaving hosts, but also to cooperate
to limit the amount of disruption such hosts can cause to the
shared communication facility.

While it is clear that the quoted text is quoting Jon Postel, it is not clear whose interpretation of that text follows in the remainder of section 1.2.2. The author of the RFC is Robert (Bob) Braden. Who worked at ISI with Jon Postel and authored other RFCs with hime (e.g., RFC 1009). Note that RFC 1122 is the RFC referenced by the Postel Center In Memoriam page.

What I like about the RFC 1122 version of the Robustness Principle is that it clarifies a common misconception about the Robustness Principle, which is that it makes receiving systems vulnerable to attack. On the contrary, the principle as interpreted in RFC 1122 advises: "In gerneral, it is best to assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect. This assumption will lead to suitable protective design..."

Notice also that this version says that it applies at "every layer of the protocols"--including the application layer.

The last [latest?] formulation of the Robustness Principle is in RFC 1958 "Architectural Principles of the Internet" (1996):

3.9 Be strict when sending and tolerant when receiving.
Implementations must follow specifications precisely when sending to
the network, and tolerate faulty input from the network. When in
doubt, discard faulty input silently, without returning an error
message unless this is required by the specification.

I personally think this is a poor version of the principle and leads to much of the misunderstanding about it. It seems to advise a passive approach to "tolerance" and "liberal acceptance".

The Robustness Principle obviously also applies to life. Tim Berners-Lee has made this part of his religious beliefs, see: http://www.w3.org/People/Berners-Lee/UU.html and http://www.w3.org/DesignIssues/Principles.html.

The Tao of Modularity.

Fri, 12 Nov 2004 10:06:09 GMT

Chapter 11

Thirty spokes share the wheel's hub;
It is the center hole that makes it useful.
Shape clay into a vessel;
It is the space within that makes it useful.
Cut doors and windows for a room;
It is the holes which make it useful.
Therefore profit comes from what is there;
Usefulness from what is not there.

I read the Tao Te Ching many times as a philosophy major at Yale and for years after, but I haven't read it the last ten years. I guess I'd better read it again. "Usefulness [comes from] what is not there" beautifully states the value of modular extensibility. What is intriguing is the distinction between profit and usefulness.

At first pass it seems obvious that the maker of a modular object, like a clay vessel is paid for (on thereby makes a profit from) "what is there". On second pass, it strikes me that the user of the vessel makes a profit from "what is not there", either by adding it on, or by using the space to some purpose, say transporting liquid in the vessel. So the last two lines could be recast:

Therefore profit to the maker comes from what is there;
Profit to the user from what is not there.

Finally, the more I think about it, the more I believe that the profit to the maker really comes from what is not there. A potter buys a block of clay at a certain cost. Her "value add" is the vessel shape she forms the clay into. Someone pays her more money for the clay in the shape of a vessel than in the shape of the raw block of clay because the buyer values the shape--what is not there. Assuming she uses the entire clay block to make the vessel, her profit is the price of the vessel minus the price of the clay block. Now suppose she could get the same price for a vessel made from only half the block of clay. She has doubled her profit by halving "what is there." So the last two lines would be more clear if they were recast as:

Therefore profit is limited by what is there;
Usefulness from what is not there.

Which is another way of saying "Less is [worth] more." Which is why intangible artifacts (aka intellectual property) are the most profitable. There is no there there.

GM's reuse strategy.

Mon, 27 Sep 2004 09:25:19 GMT

This article about GM's efforts to increase reuse of part designs, touches on several very timely topics. First, software designers are not alone in preferring to design unique parts, rather than use existing ones. I find it the epitome of irony that the industry that IT seeks to emulate in its use of interchangeable parts, itself struggles with the issue! Second, to enable reuse, even of physical part, requires substantial IT investment to enable designers to simply find a part to reuse. Third, it touches on the "monoculture" issue being debated with regard to widespread use of Windows. In GM's case, when more product lines share a common part, design flaws in the part have wider repercussions.

Nicholas Gall: Systems, Modules, and Interfaces

My history of the (Internet) Robustness Principle.

The Tao of Modularity.

GM's reuse strategy.