Re: Locale negotiation

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Sat, Oct 16, 2004 at 01:17:03PM +0200, Niels M?ller wrote:
> Nicolas Williams <Nicolas.Williams%sun.com@localhost> writes:
> 
> > 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,
> 
> 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.

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

> > 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
> 
> A channel request makes sense, and if the naming issues are solved, I
> 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.

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

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

> In the case that the server can't support your settings, to me there
> 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.

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

It helps multi-lingual users.

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

Yes, this was my thinking also.

> > 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 "locale-req%sun.com@localhost",
> 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 have not written or published such a draft yet.

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

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.

> > Which WG, if any, is the most appropriate home for the more generic of
> > these items?
> 
> No idea, I don't know very much about localization.

Thanks!

Nico
--