Re: deprecating Postel's principle- considered harmful

[Brian E Carpenter <[e-mail]>]

On 09-May-19 02:33, Joe Touch wrote:
> 
> 
>> On May 8, 2019, at 6:13 AM, Dave Cridland <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>
>>
>> On Wed, 8 May 2019 at 14:18, Joe Touch <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>
>>
>>     On May 8, 2019, at 12:05 AM, Dave Cridland <[e-mail] <mailto:[e-mail]>> 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
> 
> Take a look at RFC errata; you’ll find many counterexamples. Few (if any) protocol specifications are not exhaustively complete.
> 
>> - 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.
> 
> It’s true that the issues often come to light in implementations, but that’s a bit like saying spelling errors are caused by editing.
> 
>> 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.
> 
> 760 includes “where the meaning is still clear”.
> 
> 1958 just says “tolerate” - which doesn’t mean “accept as valid”. 

Also, RFC1958 says:

"Principles that seem sacred today will be deprecated tomorrow. The principle of constant change is perhaps the only principle of the Internet that should survive indefinitely." We (the IAB in 1996) didn't consider that we were laying down holy writ.

But yes, the word "tolerate" was carefully chosen. It doesn't say "ignore buffer overflow errors" or "use heuristics to guess what the sender meant". It means "don't throw a fatal exception when something unexpected arrives." And it suggests silent discard unless an error message "is required by the specification". That's entirely consistent with the RFC1122 text that Roland quoted.

We'd better stick to "don't throw a fatal exception when something unexpected arrives" unless we want several billion unhappy users.

   Brian

> 
> In all cases, IMO the Postel Principle just expresses a level of agnosticism that, at a human level, is often expressed as “give others the benefit of the doubt” (when receiving) and “don’t push your luck” when sending.
> 
> When you get deep into trying to infer intent (as some in the IETF have done regarding defending against so-called “attacks” that are indistinguishable from benign errors), you end up in trouble. The same problem occurs if you’re too strict in every exchange in both directions.
> 
> Joe