Subject: message lang tags verse SSH_MSG_KEXINIT

From: Darren Moffat <[email-masked]>
Date: Thu, 8 Mar 2001 18:33:03 -0800 (PST)

In Section 6 of draft-ietf-secsh-filexfer-01.txt SSH_FXP_STATUS packet is
defined as follows:

The format of the data portion of the SSH_FXP_STATUS response is as
follows:

  uint32     id
  uint32     error/status code
  string     error message (ISO-10646 UTF-8 [RFC-2279])
  string     language tag (as defined in [RFC-1766])

This isn't the only place this occurs, it just happens to be the one I
have infront of me at the moment and the one that prompted me to look
into the issue, infact I believe it is consistant thought the drafts
that language tags are sent with free format messages.

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.  As an example, an
implmenation of this on unix might use setlocale() to change the locale
of the client and server processes to be the negotiated language, thus
automatically generating all messages in the appropriate language.

Are the drafts saying that I should send the language tag the client
and server agreed on at SSH_MSG_KEXINIT time as every message is sent ?

So I guess I'm saying I don't understand the need for a language tag
for individual messages when the language was negotiated at the
SSH_MSG_KEXINIT packet stage.

Any clarification greatly appreciated.

--
Darren J Moffat

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 08 Mar 2001 21:49:47 -0500

> As an example, an implmenation of this on unix might use setlocale()
> to change the locale of the client and server processes to be the
> negotiated language, thus automatically generating all messages in
> the appropriate language.
> 

one possible rationale has occurred to me:

Even if the peers negotiated that all messages will be in, say,
martian, the server might not have translations for all possible
messages, and might need to send some messages in a "default"
language, in which case it should be tagged as such so it gets
displayed appropriately (e.g., not using martian letters).

					- Bill

---

From: Alok Aggarwal <[email-masked]>
Date: Thu, 8 Mar 2001 19:01:49 -0800 (PST)

> language, in which case it should be tagged as such so it gets

If the server didn't have support for, say, martian, it shouldn't have
negotiated martian as the language with the client in first place. Although 
if it did initially agree on talking in martian then it should be capable of
translating all the messages. Do you have a particular case in mind where
what you are saying would supersede this?

-Alok

---

From: [email-masked] (Niels M�ller)
Date: 09 Mar 2001 11:40:57 +0100

Darren Moffat <[email-masked]> writes:

> 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

---

From: Simon Tatham <[email-masked]>
Date: Fri, 09 Mar 2001 12:13:40 +0000

Niels Möller <[email-masked]> wrote:
> completely unused, I guess the main reason it's in the spec at all is
> symmetry.

Surely languages_client_to_server is used when the client is
selecting a language to send a message to the server?

This does happen in a few cases: consider the reason message sent in
SSH_MSG_DISCONNECT.

Cheers,
Simon
-- 
Simon Tatham         "My heart bleeds.
<[email-masked]>    (That's how it works.)"   -- Gareth Taylor

---

From: [email-masked] (Niels Möller)
Date: 09 Mar 2001 14:46:39 +0100

> > completely unused, I guess the main reason it's in the spec at all is

...

> This does happen in a few cases: consider the reason message sent in

You're right, of course. Other cases are SSH_MSG_DEBUG and
SSH_MSG_CHANNEL_OPEN_FAILURE. Those three are the only messages with
language tags that I can find and which it makes sense for the client
to send. So who is the target for these messages? The most likely
answer is the sysadm of the server, so the server's preferences would
equal the sysadm's.

/Niels