Wed, Jun 14, 2017 at 04:20:50PM -0400, Joel M. Halpern:
There are indeed contexts where an application calling attention to a
problem is very useful. Silently ignoring things that indicate trouble
is usually a mistake (although not always.)
I believe that it is always a mistake; it will either bite now or later,
or its not a real error and while ignoring it, real errors are missed.
It should be addressed, whether in your implementation, the test suite,
the spec or the other implementation. And, to Joe's point of resolving
the conflicts between the those; that dispute is not for the individual
to resolve. The standards body should determine what the correct behavior
is. That loop improves the spec, the suite, and interoperability - for
everyone's benefit.
quality, speed, price; pick two. if you dont pick quality, you will likely
be disappointed - whether beer, brakes or bgp. testing is a large
contributor to quality.
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.
That is the suggestion of the draft; i suggest only that a test suite
should follow this - be devilishly rude - about the slightest error.