&gt; <i>RFC 793 and RFC 1122 both include Jon Postel&#x27;s famous robustness
   principle, also from RFC 791: &quot;Be liberal in what you accept, and
   conservative in what you send.&quot;</i><p>Which is complete nonsense that doesn&#x27;t justify anything and only casts suspicion on the muddled reasoning.<p>The correct principle is: <i>be conservative in what you send, and loudly reject nonconforming, out-of-spec input.</i><p>&quot;Be liberal in what you accept&quot; results in situations like some broken piece of HTML, CSS or JavaScript working in seven diffrent ways on seven different browsers.<p>&gt; <i>However, the phrasing in RFC 793 does not permit sending resets in response to TCP packets with a non-zero Reserved field, as is explained in the section above.</i><p>Non-zero in a reserved field that has no meaning now, and should be loudly diagnosed as an error until such a time that it has a meaning. Resetting a connection is a good facsimile of such a diagnostic.<p>Just like in a C program if you use a name like __foo that is reserved, cows can fly out of your nose; but diagnosing it is better: diagnosing it now, while it has no meaning. Once __foo gets a meaning, it will be too late.<p>If connections are reset when their machines send packets which infringe on reserved fields, they will quickly learn to fix things so that their machines stop sending that. Then when the time comes, it will be possible to actually assign a use to a previously reserved field.<p>If everyone uses a reserved field willy-nilly and never gets punished with RST&#x27;s, it will be difficult to impossible to introduce a standard new use for that field. Hosts receiving the field will not know whether they are getting a genuine request with the new meaning of the field, or whether they are getting garbage which is a continuation of the widespread abuse of the field. And at that time, it will no longer be possible to send a RST due to the ambiguity, right?  The time to spew a RST in the face of the offending systems is <i>today</i>.<p>The original meaning of RST is to inform the sender that they are sending data for a connection that doesn&#x27;t exist. Sending a RST for a nonzero value of a field is a logical extension of this: it&#x27;s a piece of data destined for something that doesn&#x27;t exist: namely, the meaning of that field! The bits aren&#x27;t, ahem, <i>connecting</i> with a meaning. See?<p>Really, what is the point of a rule that is not <i>enforced</i>? If sender are supposed to leave something zero, but nobody checks that and takes any action against nonconforming senders, why document such a requirement at all?