> On Apr 6, 2018, at 7:39 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
> 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.
Yes, it is not impossible, but it is much too brittle. There's little reason
(in general)
to expect the server to have support for the client's locale, let alone have
locale-specific
translation tables for TLS errors. Numeric codes are much better if the error
reasons are
easily to classify in advance. Otherwise, numeric codes + UTF8 text in English.
This works with enhanced status codes in SMTP, which some MUAs (Outlook) render
in local
languages based on the status code, but the remote postmaster will want the
original text,
so that's often more useful for debugging when there's a problem (and not just
a wrong
email address).
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
