26 lines
1.5 KiB
Plaintext
26 lines
1.5 KiB
Plaintext
Postel's Prescription
|
|
|
|
Several of the key Internet RFC s, especially 1122 and 791 contain a piece
|
|
of advice due to Jon Postel, which is most often stated as: Be liberal in
|
|
what you accept, and conservative in what you send. That is, a
|
|
well-engineered implementation of any of the Internet protocols should be
|
|
willing to deal with marginal and imperfectly-formed inputs, but should not
|
|
assume that the program on the other end (that is, the program dealing with
|
|
the well-engineered implementation's output) will be anything other than
|
|
rigid and inflexible, and perhaps even incomplete or downright buggy. This
|
|
property is valuable because a network of programs adhering to it will be
|
|
much more robust in the presence of any uncertainties in the protocol
|
|
specifications, or any individual implementor's failure to understand those
|
|
specifications perfectly. Though the policy does tend to accommodate broken
|
|
implementations it is held to more important to get the communication
|
|
flowing than to immediately (but terminally) diagnose the broken
|
|
implementations at the expense of the people trying to use them. The
|
|
principle is a well-known one in the design of programs that handle Internet
|
|
wire protocols, especially network relays and servers, and it is regularly
|
|
applied by extension in any situation where two or more
|
|
separately-implemented pieces of software are supposed to interoperate even
|
|
though the various implementors have never talked to each other and have
|
|
absolutely nothing whatsoever in common other than having all read the same
|
|
protocol specification.
|
|
|