On Fri, Apr 6, 2018 at 4:11 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> On Fri, Apr 06, 2018 at 12:10:35PM +0000, Salz, Rich wrote: > > > > For debugging messages, I'm with Peter, they'll only be implemented > if they're > > > simple enough to support. I can't see having to have localization > files on the > > > server for debug messages that might be requested by a client is > some other locale > > > and only when debug is enabled, and the consumer is a developer and > not an end-user. > > > > The table stakes have increased, 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. > > Because the server has no idea what locale the client is in. > Localization is not an option. That would depend on how you designed the feature. Because the client would have to opt-in in any case, it could provide its locale in that opt-in message. I'm not saying that this (or even the feature at all) is necessarily a good idea, but it's not like it's impossible. -Ekr The only option (which is essentially > "use-ascii") is to use UTF-8, and then the error messages are in > whatever language the developer of the server used. So the Russian > developer will be seeing Chinese debug messages from the server. > That's not progress. > > If you want localization, the messages need to be numeric codes, > with localized string tables on each client. But then older clients > might not understand some new server messages (perhaps OK if the > message list is sufficiently stable given a client protocol version > and set of client supported extensions). > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
