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
