Stan Kalisch <s...@glyphein.mailforce.net> writes: >On Fri, Apr 6, 2018, at 3:54 PM, Ion Larranaga Azcue wrote: >> >> My opinion is that if we are going to have extended error codes, it's >> better to use numeric ones and not text based errors. > >That was my own gut feeling on the least painful way to go, but I'm open to >the possibility that gut feeling was woefully naive.
To see why this won't work, you just need to think one step further: Try sitting down and defining the numeric error codes you're proposing. If it's still not obvious: The reason why we need free-form strings is because the numeric codes we already have provide insufficient detail. To provide the required detail, you'd need to define numeric codes for every error condition and failed check that every TLS and PKI library (because lots of handshake failures are due to problems with certs) could wish to communicate. To take a PKI example, there's "Certificate chain with length %d has a path constraint of length %d", which for reasonable values of the two %d leads to, say, around a hundred error codes just for that one condition. Then take every single type of error that would need to be communicated and you're into at least 16- bit values, or 32- or 64-bit if you take cases like "Packet length of %d indicated but only %d bytes were sent". Even if someone came up with the massive codebook of thousands or tens of thousands of error codes, which TLS author would want to spend hours paging through them to find the right code for each situation? Conversely, if you limit the number of error codes to, say, 5,000, how are you going to convince TLS library authors to check for and report only those errors? What happens if new error types are defined? Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls