On Fri, Apr 6, 2018 at 4:11 PM, Viktor Dukhovni <ietf-d...@dukhovni.org>

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


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

Reply via email to