Postel's Law

Attributes of Postel's Law. Source: Tilkov 2015, slide 36.
Attributes of Postel's Law. Source: Tilkov 2015, slide 36.

Postel's Law was formulated by Jon Postel, an early pioneer of the Internet. The Law was really a guideline for creators of software protocols. Computers used protocols to communicate with one another on the Internet. The idea was that different implementations of the protocol should interoperate. The law is today paraphrased as follows:

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

Although first stated with reference to TCP/IP, the Law has been applied in other areas, from the parsing of HTML to the acceptance of user inputs. The growth and success of the Internet has been attributed in part to this Law. However, its use in modern systems has been questioned. It's been suggested that following the Law is harmful from the perspective of maintainability, compatibility and security.

Postel's Law is also known as the Robustness Principle.

Discussion

  • Could you explain Postel's Law?

    The spirit of Postel's Law is to make different implementations interoperate. There are two parts to the Law and these are briefly explained in RFC 760:

    • Conservative in sending: Protocol should be careful to send well-formed datagrams.
    • Liberal in receiving: Protocol should accept any datagram that it can interpret. In other words, if the semantics are clear then errors in syntax can be overlooked.

    Herb Bowie calls it, "a general social code for software: be strict in your own behavior, but tolerant of harmless quirks in others."

    In a more general sense, the Law is about reducing variations in input and giving a more well-defined and easily understood output. Robustness comes because chaos at the input is managed to result in a cleaner output.

  • Can you give examples of Postel's Law in action?
    Protocol example of Postel's Law. Source: Allman 2011.
    Protocol example of Postel's Law. Source: Allman 2011.

    Here are some examples where the Law allows the system to continue functioning rather than break down with a fatal error:

    • If an incorrect type is received, cast it to the correct type.
    • If users enter whitespaces, trim them.
    • If arguments are invalid and your function is supposed to return an array, return an empty array.
    • If a closing HTML tag is expected but it's missing, close it yourself.

    Let's take a protocol example in which if option A is present, field X has a value; otherwise, X should be zero filled. A conservative sender will be sure to zero fill X if A is absent. Suppose the sender doesn't bother doing this. A liberal receiver will accept the packet even if X is not zero filled.

    Suppose in version 2 of the protocol, option B is introduced. B is applicable when A is absent. B also sets the value of X. Due to Robustness Principle, version 1 receivers will continue to accept packets sent by version 2 senders (A absent, B present with X) although they won't support B.

  • Why was Postel's Law so important for the early Internet?

    The Internet grew without centralized control. When a protocol was defined, it was implemented by multiple individuals and teams. For reliable communication, these different implementations needed to understand one another. However, standards are not always unambiguous. Sometimes different interpretations arise. In such cases, strict adherence to the standard will result in protocol errors. In a distributed system, it would be hard to iron out these differences. If there's tight control, Postel's Law is not needed. But the Internet is many pieces loosely joined. This is exactly why the Law made sense.

    In early Internet days, implementations were liberal in accepting non-standard inputs provided they could make sense of them and decide how to handle them. Without such a liberal approach, the growth of the Internet might have been slower than what it was. Without Postel's Law, standardization and their strict implementations would have taken longer. Implementations that interwork with one another was more important. This is partly reflected in the ethos of IETF that aims for "rough consensus and running code."

    A similar thing happened with browser and HTML. The Law made sense for rapid growth of the WWW.

  • In what aspects of a software system has Postel's Law been applied?
    Applying Postel's Law to user interfaces. Source: Deep 2019.
    Applying Postel's Law to user interfaces. Source: Deep 2019.

    Networking protocols commonly used on the Internet (such as TCP/IP, SNMP, FTP) adhere to the Law to achieve interoperability.

    When HTTP became popular in the 1990s, browsers applied the Law liberally. From a user experience perspective, it was better to parse and display as much of the content as possible rather than inform the user than the HTML page was not conforming to specifications. XML parsers on the other hand are more strict about accepting malformed or invalid XML documents. Nonetheless, some XML feed readers and aggregators from the 2000s were liberal.

    The Law's been applied to design systems. When parsing user inputs, the Law's been applied to deliver better user experience. It's been used in UNIX command line utilities. APIs and microservices have also applied the Law.

  • How does one apply Postel's Law to APIs and microservices ?

    Different services could be running different versions and maintaining strict compatibility is a challenge. However, the use of versioning for APIs can help achieve backward compatibility and avoid the situation of being too liberal in accepting invalid requests. The Law is equally relevant for consumers of API, who can be liberal and process only those fields of the response they are interested in and ignore extra fields.

    Where client implementations are not liberal with responses, the server may apply counter measures. In other words, the server responds in a less conservative manner so that client code does not break when the API is changed or upgraded later. This is an example of applying the Law selectively.

  • Are there problems with or exceptions to Postel's Law?
    Liberal implementation or a software bug? Source: Mullican 2013.
    Liberal implementation or a software bug? Source: Mullican 2013.

    It's been claimed that the Law has no exceptions, even when it comes to XML parsing. Others argue that XML documents have to be well formed and valid.

    While the Law is good for interoperability, it leads to incompatibilities. There's no agreement about how liberal an implementation needs to be. Thus, HTML5 is a stricter specification than its predecessors.

    RFC 2360 clarifies, "The sender accuses the receiver of failing to be liberal enough, and the receiver accuses the sender of not being conservative enough." One solution is to define standards in greater detail, particularly for the receiving end. It should be clear when to be liberal.

    There could be such a thing as being too robust. RFC 3117 states that robustness is at odds with efficiency. Robustness Principle can create deployment problems because errors in new implementations will go undetected until they meet a not-so-liberal implementation. Since errors are tolerated, over time they will become entrenched and make implementations more complex. Thomson calls this the Protocol Decay Hypothesis. It's therefore better to expose these errors early on and let implementations fix them.

  • Can Robustness Principle be called Resilience Principle?

    Robustness is quite different from resilience. A robust system attempts to avoid failure and thus incurs design complexity. A resilient system attempts to discover problems early and focuses on recovery. Equivalently, a robust system will continue to function without changing its essential nature. A resilient system will continue to function by adapting itself.

    Thus, it's proper to call Postel's Law as Robustness Principle.

Milestones

1974

Vinton Cerf and Robert Kahn publish details of Transmission Control Program (TCP) for use in packet-switched networks. This protocol is the genesis of what later became the popular TCP/IP.

1980

IETF releases two documents, RFC 760 (Internet Protocol) and RFC 761 (Transmission Control Protocol). This is the beginning of TCP/IP. Jon Postel, editor of both RFCs, mentions in RFC 760, "an implementation should be conservative in its sending behavior, and liberal in its receiving behavior." In RFC 761, he says in a section named Robustness Principle, "be conservative in what you do, be liberal in what you accept from others."

2004

Tim Bray argues why applying the Law to the parsing of XML documents can be harmful, particularly when the document has financial data.

2011

Eric Allman publishes an article titled The Robustness Principle Reconsidered. He explains that the Law made sense in the early days of the Internet when folks cooperated. Today, the world is more hostile and security is a concern. The Law is still relevant but a line must be drawn between being conservative and being liberal. For example, we can be liberal and accept a packet even when the byte allocated for an optional field is not set to zero. On the other hand, we shouldn't be liberal in accepting wrongly encoded digital signatures.

2015

M. Thomson proposes an alternative to Postel's Law. He states this as follows,

Protocol designs and implementations should be maximally strict.

References

  1. Allman, Eric. 2011. "The Robustness Principle Reconsidered." Communications of the ACM, Vol. 54 No. 8, Pages 40-45. Accessed 2017-11-03.
  2. Boulton, Mark. 2016. "Design systems and Postel's law." May 17. Accessed 2017-11-03.
  3. Bowie, Herb. 2013. "Reflections on Postel's Law." May 10. Accessed 2017-11-03.
  4. Braden, R., ed. 1989. "Requirements for Internet Hosts -- Communication Layers." RFC 1122. October. Accessed 2017-11-02.
  5. Bray, Tim. 2004. "On Postel, Again." January 11. Accessed 2017-11-03.
  6. Broad, MacLeod. 2015. "Wrestling with Postel's Law." Workiva Tech Blog. October 14. Accessed 2017-11-03.
  7. Cerf, V. and R. Kahn. 1974. "A Protocol for Packet Network Intercommunication." IEEE Transactions on Communications, vol. 22, no. 5, pp. 637-648. May. Accessed 2017-11-02.
  8. Deep, Rishi. 2019. "Postel's Law - Laws of UX." Dribble, March 18. Accessed 2018-10-03.
  9. Feathers, Michael. 2015. "The Universality of Postel's Law." September 21. Accessed 2017-11-03.
  10. Hoffman, Paul. 2012. "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force." IETF. November 2. Accessed 2017-11-03.
  11. Jim, Trevor. 2011. "Postel's Law is not for you." December 15. Accessed 2017-11-03.
  12. Monti, Gary. 2011. "Resilience Engineering #1: Robust Vs. Resilient." Active Garage. June 7. Accessed 2017-11-03.
  13. Mudhar, Raj. 2011. "Robustness vs. Resilience." May 24. Accessed 2017-11-03.
  14. Mullican, Lyle. 2013. "Your Website has Two Faces." A List Apart, February 12. Accessed 2018-10-03.
  15. Ordiales, Jose Luis. 2017. "Why you should follow the robustness principle in your APIs." March 25. Accessed 2017-11-03.
  16. Postel, Jon, ed. 1980a. "Internet Protocol." RFC 760. January. Accessed 2017-11-02.
  17. Postel, Jon, ed. 1980b. "Transmission Control Protocol." RFC 761. January. Accessed 2017-11-02.
  18. Rose, M. 2001. "On the Design of Application Protocols." RFC 3117. November. Accessed 2017-11-02.
  19. Rotbart, Tal. 2016. "Driving API Client Resiliency: How to enforce Postel’s Law by violating Postel’s Law..." Medium. May 25. Accessed 2017-11-03.
  20. Scott, G., ed. 1998. "Guide for Internet Standards Writers." RFC 2360. June. Accessed 2017-11-02.
  21. Swartz, Aaron. 2003. "Postel's Law Has No Exceptions." August 18. Accessed 2017-11-03.
  22. Thomson, M. 2015. "The Harmful Consequences of Postel's Maxim." Internet Draft. March 9. Accessed 2017-11-03.
  23. Tilkov, Stefan. 2015. "REST: I don't Think it Means What You Think it Does." InfoQ, March 05. Accessed 2018-10-03.

Further Reading

  1. Feathers, Michael. 2015. "The Universality of Postel's Law." September 21. Accessed 2017-11-03.
  2. Allman, Eric. 2011. "The Robustness Principle Reconsidered." Communications of the ACM, Vol. 54 No. 8, Pages 40-45. Accessed 2017-11-03.
  3. Thomson, M. 2015. "The Harmful Consequences of Postel's Maxim." Internet Draft. March 9. Accessed 2017-11-03.

Article Stats

Author-wise Stats for Article Edits

Author
No. of Edits
No. of Chats
DevCoins
User avatar dineshpathak
2
0
3749
Avatar of user arvindpdmn arvindpdmn
7
0
101
User avatar Backwards-Dave
2
0
69
User avatar vikasG
1
0
32
Avatar of user devbot5S devbot5S
1
1
31
DevCoins due to articles, chats, their likes and article hits are included.
1462
Words
5
Authors
13
Edits
1
Chats
11
Likes
47K
Hits

Cite As

Devopedia. 2022. "Postel's Law." Version 13, February 15. Accessed 2023-11-12. https://devopedia.org/postel-s-law
Contributed by
5 authors

Last updated on
2022-02-15 11:48:43
design networking standardization

See Also

  • Internet Protocol Suite
  • XML
  • Kerckhoff's Principle
  • Conway's Law
  • Fitt's Law