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. 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
