Brian, > On Jun 14, 2017, at 3:44 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > > 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. I agree. It also seems to me that having implementations "fail noisily in response to bad or undefined inputs" is a great formula to making implementations very fragile and consequently very easy to attack. Overall, I think the approach outlined in this draft would not have allowed us to build the current Internet. Bob p.s. The file name chosen for this draft appears to be a good example of stepping on the toes of those who came before, instead of standing on their shoulders. See: http://wiki.c2.com/?ShouldersOfGiants > > Brian >
Attachment:
signature.asc
Description: Message signed with OpenPGP