Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24
Just make the text message UTF8. Is that so hard, so distasteful? This gets a very common use-case and is useful for debugging. I used to say "just teach 'em all English," but that was 25 years ago and I was not serious. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24
I can't believe the amount of pointless bikeshedding that's already been done over something that's going to be a rarely-if-ever used mechanism for one set of hardcore technical developers to communicate to another set of hardcore technical developers. This isn't a design for a multilingual IM system with emojis and animated GIFs, it's a rarely-used debugging/diagnostic facility, and yet we're arguing over whether a developer who can read a lengthy technical document specified entirely in US-ASCII (TLS RFC) and implement it in C or Java (US-ASCII, English keywords) will be unable to communicate an error message in anything but Cantonese (or Mandarin, or Qiang, or Kam–Sui, or Kipchak, or whatever was meant by "Chinese"). Even for the few steps in the process where there's i18n available like the gcc compile stage, the Chinese-speaking devs I know use the English version because they don't want an attempted guess in another language at what the error is, they want the actual error message from the compiler authors (many gcc error messages are barely comprehensible in English, let alone in an Uighur translation. Or maybe there are in Uighur, which is why I have trouble figuring out what they're saying). In any case it's a rarely-used, optional, by-special-request debugging facility for technical developers, make it UTF-8 and the devs can decide what they put in there. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24
Stan Kalisch 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
