Re: message lang tags verse SSH_MSG_KEXINIT

[nisse%lysator.liu.se@localhost (Niels Möller)]

Darren Moffat <Darren.Moffat%eng.sun.com@localhost> writes:

> My interpretation of the SSH_MSG_KEXINIT language negotiation was that
> the client and server would agree on a language and (if possible) send
> all futher communication in that language.

I think the problem is that languages aren't really negotiated the
same way the other parameters in the SSH_MSG_KEXINIT are.

    languages
      This is a comma-separated list of language tags in order of
      preference [RFC-1766]. Both parties MAY ignore this list. If there
      are no language preferences, this list SHOULD be empty.

(It is not entirely clear to me if an implementation is allowed to
send a non-empty list, and at the same time ignore the other side's
list, but it seems like a reasonable thing to do for an implementation
that supports a single language).

I think it is better to view the language list as user preferences
than as negotiated values. One scenario that makes some sense to me is
as follows:

An SSH server doesn't have any preferences, so it sends an empty list
for both "languages_client_to_server" and
"languages_server_to_client". The client sends the list "sv,dk,en"
(I'm not sure the syntax is right here, but the idea is that the
client prefers messages in Swedish, Danish and English, in that
order).

Now, various modules and subsystems in the server generate messages,
The modules may be written by different persons, come for different
sources, or simply have different sets of languages available. Then,
it would make sense for each module to use the language that it knows
and which is first on the client's preference list.

The end result is that not all messages use the same language. The
indivudual language tags provides information.

A more simple example is a server that sends an empty language list,
and a client that sends a single language, say "sv". After the initial
negotiation, the client has no way of knowing if the server will be
honoring or ignoring the client's language preference.

I agree the language negotiation is far from not crystal clear.
Another minor point is that languages_client_to_server seems to be
completely unused, I guess the mainr eason it's in the spec at all is
symmetry.

/Niels