Basically, we shouldn't issue standards or RFCs without test vectors and tests that are meaningful, and updated if bugs are found in them (or the RFC).
Expecting someone to (say) read the HTTP spec and write a compliant implementation without tests that everyone else is using as well is lunacy, and leads to the nightmare we have today.
Standards without engineering to back them up are bad.
Side effect: Committees that produce "ivory tower" standards that are unimplementable will find that their work is ignored.
Another side effect: Standards will get simpler, because over-complex nonsense will be obvious once the committee gets down to making an exemplar actually work.
Not that it will ever happen...
[I helped write an HTTP proxy once. The compliant part took a couple weeks; making it work with everyone else's crappy HTTP implementation was a months-long nightmare on rollerskates]
Expecting someone to (say) read the HTTP spec and write a compliant implementation without tests that everyone else is using as well is lunacy, and leads to the nightmare we have today.
Standards without engineering to back them up are bad.
Side effect: Committees that produce "ivory tower" standards that are unimplementable will find that their work is ignored.
Another side effect: Standards will get simpler, because over-complex nonsense will be obvious once the committee gets down to making an exemplar actually work.
Not that it will ever happen...
[I helped write an HTTP proxy once. The compliant part took a couple weeks; making it work with everyone else's crappy HTTP implementation was a months-long nightmare on rollerskates]