Subject: Locale negotiation

From: Nicolas Williams <[email-masked]>
Date: Fri, 15 Oct 2004 18:46:44 -0500

Our users need to be able to have local locale settings propagated to
remote sessions.

The SSHv2 protocol does not provide a sufficiently general facility for
this purpose.  It does provide for language negotiation, but locales are
more than just a language -- for example, locales typically specify a
language, for L10N, and a codeset.

The language negotiation in the SSHv2 protocol is sufficient for
localization of UTF-8 display strings in the SSHv2 protocol.  It is not
sufficient for negotiation of locales for sessions.

Currently we may use the environment variable passing facility of SSHv2
to pass POSIX locale variables (LANG, LC_ALL, LC_CTYPE, ...).

This approach will work for platforms that support the same locales and
implementations for POSIX platforms or, for non-POSIX platforms, which
can map these variables and POSIX locale names to non-POSIX equivalents.

Even where this approach works it only works if the server has support
for the locales that its clients may so reference.  There is no way to
determine that a server may have support other locales that may satisfy
its clients.

So, I'll be posting, post-IETF 61, several I-Ds to address this.

My current plan is to define RFC3066-like namespaces of locale
categories and codesets, define an abstract description of locales,
roughly matching the POSIX locale concept, and, finally, two extensions
to SSHv2:

 - a global request for locale negotiation
 - a channel request for setting the locales for the various categories
   for a given channel

Comments?

Which of these I-Ds, if any, should be SECSH WG work items?

Which WG, if any, is the most appropriate home for the more generic of
these items?

Nico
--

---

From: [email-masked] (Niels Möller)
Date: 16 Oct 2004 13:17:03 +0200

Nicolas Williams <[email-masked]> writes:

> roughly matching the POSIX locale concept,

I'm not very familiar with these issues, but standardized naming of
locales and locale properties seems somewhat out of scope for the
secsh wg.

> and, finally, two extensions to SSHv2:
> 

A channel request makes sense, and if the naming issues are solved, I
hope it should be fairly simple.

I don't know how the negotiation is supposed to work, if you want to
transfer the settings from the local environment to the remote
session, then how it ought to work is:

  1. Client encodes the information in some standard form for
     transmission over the wire.

  2. Server decodes the information.

  3. Server applies the information to the session, as good as it can.

  4. Server reports back to the client to which extent the locale
     settings could be applied.

In the case that the server can't support your settings, to me there
seems not to be much to negotiate about.

One could provide a preference lists for things like languages and
charsets and negotiate about that, but I'm not sure that really helps
in practice. I would expect the applications on the server side to
have verying levels of localization, which the ssh server won't have
much control or knowledge about.

So if you have a preference lists, what you should do is to propagate
that list to the applications; negotiating with the server seems
pointless.

Anyway, I think the channel request should be specified so that it is
independent of the negotiation/locale-query mechanism.

> Which of these I-Ds, if any, should be SECSH WG work items?

The channel request, and the global request (if one really is needed)
would fit here, I guess.

Personally, I'd encourage you to start with a "[email-masked]",
share the spec informally with other implementors who are interested,
and take it to the wg for standardization when there's some more
experience with it. Or perhaps you've done that already?

I think the handling of "keyboard-interactive" in the wg was somewhat
unfortate; there's a draft and one early implementation. At the time
other implementors read the spec carefully, the installed base is
already large enough that it is a serious argument against all
changes, improvements and bug-fixes of the spec. The effect is that
much of the implementation experience can't easily be taken into
account.

> Which WG, if any, is the most appropriate home for the more generic of

No idea, I don't know very much about localization.

Regards,
/Niels

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 18 Oct 2004 04:48:20 -0500

> locales and locale properties seems somewhat out of scope for the

I think so too, but this may be the first WG where some of these issues
come up.

> hope it should be fairly simple.

I think so too.  The channel request should be very simple: a request to
set some locale category (e.g., LC_TIME) to a given locale.  Quite
similar to what we may do with environment variables.

> session, then how it ought to work is:

I see two aproaches:

 - a global request through which the client may list the locales
   available on the server

 - a global request through which the client may ask the server for the
   locales that match a given specification (e.g., "tell me what locales
   are available that best match this list of RFC3066 language tags and
   this list of codesets" [I think we can ignore "modifiers"])

The former can be a subset of the latter, but it's much simpler to
implement, even if it may be very chatty (I've seen Solaris systems with
more than 200 locales available).

> seems not to be much to negotiate about.

Oh, but there is.  I might want a french locale with ISO8859-1
as the codeset but might settle for spanish and/or UTF-8.

> much control or knowledge about.

It helps multi-lingual users.

> independent of the negotiation/locale-query mechanism.

Yes, this was my thinking also.

> experience with it. Or perhaps you've done that already?

I have not written or published such a draft yet.

> much of the implementation experience can't easily be taken into

Point taken.  I'm concerned that while language negotiation (through use
of RFC3066 language tags) and codeset for use on the wire in Internet
protocols (UTF-8) are fairly well-covered matters at the IETF,
localization is less well covered, thus my post -- there may be issues
here that deserve consideration outside SECSH.

> No idea, I don't know very much about localization.

Thanks!

Nico
--