... be conservative in what you do, be liberal in what you accept from others.
The Robustness Principle was described by Jon Postel in the 1981 Transmission Control Protocol (TCP) definition paper, RFC 793, like this:
2.10. Robustness Principle
TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.
The goal of this principle was facilitate interoperation of systems built by different groups, when those systems based on a common specification. Since the specification might not be 100% clear in all scenarios, following the robustness principle maximizes the chances of interoperability.
For example:
A file format specification defines that each line of the file must be handled individually.
This specification is taken by two groups: group A works in UNIX environments
(where new line separator is byte 0x0A, known as \n) while group B works in
Windows environments (where new line separator is the byte sequence 0x0D 0x0A, known as \r\n).
In the case file format the specification does not describe explicitly which is the line separator character or sequence, it is reasonable to assume that both separators are valid.
Both groups, based on the robustness principle shall choose to accept files with either separators: so Windows group will be able to receive files from the UNIX group and viceversa. This is the application of be liberal in what you accept part of the principle.
About being conservative in what you do: both groups can take care of not adding cosmetic/formatting/extra lines to the file; something that can cause confusion to a receiver implementation that can consider those extra lines as actual data an not merely decorations.
Cons:
By deciding to be flexible in the input accepted by the implementation of a protocol, serious flaws (including security holes) might be overseen or not reported early in the protocol definition.
To minimize the amount of indefinition in the protocol specification, a safe approach is to build a reference implementation; so the experience in building that implementation reinforces the completeness of the specification itself.