Re: [I18nrp] Additional input needed for i18nRP BOF

[Nico Williams <[e-mail]>]

On Wed, Jun 06, 2018 at 05:27:05PM -0600, Peter Saint-Andre wrote:
> As stated in BCP 18:
> 
>    Internationalization is for humans. This means that protocols are not
>    subject to internationalization; text strings are.
> 
> If there are no human-readable text strings in a protocol, then no i18n
> review is needed. In the IETF, that significantly narrows the field. My
> sense is that few INT or RTG area specs, a somewhat higher proportion of
> OPS, SEC, and TSV area specs, and a preponderance of ART area specs
> would at least need a spot check to determine if review is required.

Almost.  Consider SSHv2...

SSHv2 carries UTF-8 strings in some of its messages, and supports
language negotiation for localization of messages to users.  This is
very nice and maybe was fairly forward-thinking at the time.

SSHv2 easily could have not carried any such strings -- at least if we
ignore password and interactive authentication methods, which I will for
the sake of the argument I'm about to make.

   [TL;DR?  My point is this: even a protocol which carries no strings,
    but which does carry session text data, or documents, might need to
    support language or locale negotiation.
    
    Related point: it's not just I18N we should think about, but also
    L10N (localization).  In the IETF we tend to include L10N in I18N,
    but elsewhere I've seen G11N (globalization) used as encompassing
    I18N + L10N.]

But the whole point of SSHv2 is to carry "shell session" user data,
including user _interactive_ session data, which means: text -- text
that the protocol carries as-is no matter the choice of codeset, so
there are no internalization issues in SSHv2 regarding that text.  But
there are still _localization_ issues regarding that text: specifically,
negotiation of server-side locale for user sessions.

So even if SSHv2 had carried no strings in its various messages, it
would still have needed to support locale negotiation.

The protocol only supports language negotiation, but for the sessions it
establishes it kinda needed to support codeset negotiation as well, and
maybe other locale attributes.  Users make do by just sending LANG
and/or LC_* POSIX environment variables without any kind of negotiation,
hoping for the best.

Note also that the IETF has no standard notion of locale (unless that
has changed recently), which is partly why SSHv2 doesn't either.  In our
protocols we speak of language tags and codesets completely from each
other, and we try hard to only use Unicode and UTF-8.  But operating
systems tend to deal with {language, codeset} as units -- locales.
(There's a bit more to a locale than language + codeset, but let's
ignore that for a moment.)

It might be useful for the IETF to adopt (a subset of?) the POSIX notion
of locale.  Though admittedly we have very few protocols where we'd need
it, thus lacking a notion of locale has not been noticeably problematic.

Nico
--