Nick Gall's Weblog

Saturday, May 28, 2005

Some historical roots to Mass Innovation. Nice article in Forbes on Mass Amateurization (seen on Martin Koser's Furl feed). I especially like the quote about the mass amateurization enabled by the Model T: To be fair, all this amateur energy isn't exactly a new force. When exciting technologies emerge, Americans have always pounced and created something original. In his 1936 New Yorker article "Farewell, My Lovely," E.B. White eulogized the Model T and the creativity it inspired in its owners: "When you bought a Ford, you figured you had a start--a vibrant, spirited framework to which could be screwed an almost limitless assortment of decorative and functional hardware.... Gadget bred gadget. Owners not only bought ready-made gadgets, they invented gadgets to meet special needs." The difference today is simply the technology, says University of Virginia technology historian Bernie Carlson: "I would call it the Ralph Waldo Emerson or Henry David Thoreau theme, that it's as important to produce as it is to consume." Forbes Article Page 2 BTW, it wasn't just the gadgetry that was done by amateurs; the very act of driving was now a mass activity, where chauffeurs had previously been required. Also, according the PBS series A Science Odyssey, the Model T also amateurized automobile maintenance: owners could and did do basic maintenance to their Model T's. 3:45:32 AM

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

Tuesday, May 17, 2005

Take a free ride or be nickeled and dimed--it's up to you. Good article in the Sunday times on vendor's strategy of "shrouding" costs, aka to "nickel and dime": "Why That Doggie in the Window Costs a Lot More Than You Think". The article is based on the paper "Shrouded Attributes, Consumer Myopia, and Information Suppression in Competitive Markets". What I like about the article is the interaction among sophisticated consumers, myopic consumers, and vendors: sophisticated consumers are subsidized by the profit that vendors make from myopic consumers. For example, credit card companies offer no annual fee credit cards, which give sophisticated consumers free credit because myopic consumers foot the bill with late fees and interest charges. It reminds me of a New York Times article from a couple of years ago: " It Adds Up (and Up, and Up)". The "Adds Up" article discusses how information services vendors break up costs into lots of small charges to make it difficult for consumers to see the Total Cost of Ownership. The nice IT implication is that the TCO for a product or service will depend very much on whether the ITO is a sophisticated consumer or a myopic one. 5:32:53 AM

Monday, May 16, 2005

My So-Called Hieroglyphics Name. Here's another fun name generator--this time a hieorglyphs name generator. Here's my name in hieorglyphics. Son of Ra, Lord of the Two Lands, Nick Gall, given life, like Re, forever (I kinda like the sound of that): Again, thanks to Jochen Fromm for the link. 7:08:28 AM

My So-Called Chinese Name. Here's a fun web service: a Chinese Name Generator. Here's what it generated for me: Here's what it means: Surname (first character) Kuang Given Name (middle character) Ning repose, serenity, peace; peaceful Given Name (last character): sheng life Thanks Jochen Fromm. 6:20:01 AM