On Wed, 8 May 2019 at 14:18, Joe Touch <touch@xxxxxxxxxxxxxx> wrote:
*NONE* of it is about tolerating bugs or errors, nor is it about allowing arbitrary behavior for senders.Sure about that?From RFC 760:That is, it should be careful to send well-formed datagrams, but should accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear).The parenthetical example is explicitly stating that a datagram with a technical error should still be accepted.Your cut off the part about the meaning being clear.And technical error doesn’t necessarily mean bug. It could mean specification error.If you stick with the “meaning is clear” part, it’s safe. It’s when we get into what things might, could, or probably mean that there be dragons.
I accept your points, but if the meaning were genuinely unambiguously clear, it'd likely have been in the specification - the problem is that when there's some kind of technical error, what is and is not clear becomes very much in the eye of the implementer.
So while I did indeed fixate on that "technical errors" to the exclusion of "the meaning is still clear", that's because it's the technical error bit that I think is the technical error here.
This is also why I drew attention to the RFC 1122 Section 1.2.2 restatement and lengthy discussion - I don't see anything I could reasonably disagree with there, yet both the first RFC to discuss the principle (RFC 760 above) and the last (RFC 1958) both seem problematic to me.
Dave.
