Re: deprecating Postel's principle- considered harmful

[John C Klensin <[e-mail]>]

--On Thursday, May 9, 2019 11:04 +1200 Brian E Carpenter
<[e-mail]> wrote:

> 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.

An observation that goes a little beyond the robustness
principle (but this threat seems to be have already drifted off
it)...    It may be useful to remember that one of the oldest
and most important principles in the design of what were then
called human interfaces to computers is that, when an error
occurs, the result should, if at all possible, provide
information about the cause, rather than either having the
program freeze up or die or generating an error message with the
same information content as "you lose".  As with the robustness
principle, failure to engage in thinking when apply this design
principle often has unfortunate effects, there may be sound
reasons for deciding how much information is too much, and a
good interpretation of the principle may be different for the
kinds and layers of protocols and implementations covered by
1122 than might be the case for those associated for 1123.  But
none of those considerations would be good reasons to discard or
deprecate the principle itself.  Doing so, like doing so with
the robustness principle, would almost certainly cause serious
harm to the perceived quality and usefulness of our protocols
and, in particular (as others have suggested in other contexts)
would increase customer support costs for those the user
community holds responsible when things don't work sufficiently
to cause protocol specifications to be either rejected in
practice or for non-conforming, but less costly to support,
alternatives to be introduced.

best,
   john


    john