Hi,
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. Imagine a chinese client trying to troubleshoot a connection to a server using a TLS stack that reports its errors in russian. That would be crazy! I'm not saying that forcing English is better. There are many people out there who have problems with english as well, and I'm sure that they would rather look a numeric code in a table with localized error messages than having to use google translate. That being said... If in the end a decission is made to have text based error messages, I think that the messages should be (at least) UTF-8. If a developer wants to generate an error message including information from the certificate (I can't imagine a valid scenario but... why not?), there are many places where UTF-8 is allowed. Additionally, a server name can also contain non-ASCII characters and so on... ________________________________ De: TLS <tls-boun...@ietf.org> en nombre de Stan Kalisch <s...@glyphein.mailforce.net> Enviado: viernes, 6 de abril de 2018 16:39 Para: tls@ietf.org Asunto: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 Hi, On Fri, Apr 6, 2018, at 8:10 AM, Salz, Rich wrote: The table stakes have increased, Exactly. and I don't think it is reasonable any more for any IETF protocol to have "just use ASCII" for text messages. It could be UTF8, or it could be codeset/tagged. Why two developers in, say, Russia need to speak English to debug their TLS implementations. Viktor rightly points out that in this situation the developer is the consumer. As the Internet exponentially expands-often in ways we're not always able to posit ahead of time-the base of developers exponentially expands. The IETF shouldn't be sanguine about the possibility that at some point the number of those developers who do not speak English will reach a critical mass that is able to start eschewing protocols that it finds too mired in US-ASCII. I would ask anybody who would say it could never happen how sure they are of that assertion. Thanks, Stan
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
