On 15/06/2017 08:20, Joel M. Halpern wrote:
...
> I would be very unhappy to see us take the lesson from cases where we
> were sloppy to be that we should tell everyone to have their
> implementations break at the slightest error.
Indeed. We need implementations to be as robust as possible. That
means careful thought, both in the specification and in every
implementation, about how to handle malformed incoming messages.
There's no single correct answer, as I am certain Jon would have
agreed. Some types of malformation should simply be ignored,
because the rest of the message is valid. Others should cause the
message to be discarded, or should cause an error response to be
sent back, or should cause the error to be logged or reported to
the user. There is no single correct solution.
Clearly the Postel principle was intended as general guidance.
Looking at the core of the draft:
Protocol designs and implementations should fail noisily in
response to bad or undefined inputs.
that seems a very reasonable principle for *prototype* and
*experimental* implementations, and a lousy one for production
code, where the response to malformed messages should be much
more nuanced; and the users will prefer the Postel principle
as a fallback.
Brian