Re: deprecating Postel's principle- considered harmful

[Dave Cridland <[e-mail]>]

On Wed, 8 May 2019 at 14:18, Joe Touch <[e-mail]> wrote:

>
>
> On May 8, 2019, at 12:05 AM, Dave Cridland <[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 - 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.