QUIC error codes -- too many *and* too few

["Aron ." <[e-mail]>]

Dear QUICsters,

I believe that the QUIC protocol specification goes overboard in trying to
have an error code for each error condition.  Of course, the roots of this
are historic: since both first client and server use the same code base, it
makes sense to enumerate all possible errors to facilitate debugging.  (An
error code like QUIC_MAYBE_CORRUPTED_MEMORY is a good example of this.)
However, as the number of QUIC implementations grows, a list of errors this
long and this specific is, I think, ill-advised.

My copy of *HTTP: The Definitive Guide (O'Reilly, 2002)* lists a
grand total of eighteen 400-level codes.  15 years later, Wikipedia's list
of HTTP status codes
<https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_errors>
has twenty-eight.  draft-ietf-quic-transport.md
<https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-transport.md>
has about sixty.  What is the client to do with these error codes?  It can
probably not do much more than log them.

On the server side, finding a matching error code for an error condition
would probably be a difficult task, especially if the implementation folds
several checks into one.  Other error codes are potential information
leaks, such as some crypto-related codes.

In regards to having too few error codes, it would be useful to have two
catch-all error codes (like HTTP 400 and 500), one for client errors and
one for server errors, which could be used (something like a MAY in the
spec?) when an appropriate error code does not exist.

  An aspiring QUIC implementer.