Wednesday, May 25, 2005

My history of the (Internet) Robustness Principle. [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. 6:06:37 AM

Friday, November 12, 2004

The Tao of Modularity. 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. 6:06:09 AM

Monday, September 27, 2004

GM's reuse strategy. 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. 5:25:19 AM