> 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