The robustness principle is a general design guideline for software that operates or controls the infrastructure of the Internet or other Internet Protocol-based networks.
The Internet Engineering Task Force publishes its research, public communications, policies, and standard-setting specifications as a numbered series of Request for Comments (RFC) documents.
In RFC 761 (Transmission Control Protocol, 1980) American computer scientist Jon Postel summarized earlier communications of desired interoperability criteria for the Internet Protocol (cf. IEN 111[1], RFC 760) as follows: TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.
This clause has been generalized into the robustness principle, also known as Postel's Law:
- Be conservative in what you do; be liberal in what you accept from others.
The principle suggests that Internet software developers carefully write software that adheres closely to extant RFCs but accept and parse input from peers that might not be consistent with those RFCs.
Postel's principle is often misinterpreted as discouraging checking messages for validity. For example, a subsequent RFC, RFC 3117, suggests that Postel's principle be followed only loosely, lest errors or less-than-desirable implementations should be propagated generally:
Counter-intuitively, Postel's robustness principle ("be conservative in what you send, liberal in what you accept") often leads to deployment problems. Why? When a new implementation is initially fielded, it is likely that it will encounter only a subset of existing implementations. If those implementations follow the robustness principle, then errors in the new implementation will likely go undetected. The new implementation then sees some, but not widespread deployment. This process repeats for several new implementations. Eventually, the not-quite-correct implementations run into other implementations that are less liberal than the initial set of implementations. The reader should be able to figure out what happens next. Accordingly, explicit consistency checks in a protocol are very useful, even if they impose implementation overhead. [emphasis added]
However, a deeper understanding of Postel's principle encourages such consistency or validity checks. While errors detected by such checks should indeed be logged (and perhaps even displayed to the user), they should not result in the rejection of invalid messages unless necessary. See RFC 1122:
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. [emphasis added]
The robustness principle of Internet architecture has also found applications and interpretations in social contexts in the popular media.[2]
[edit] References
[edit] External links
