IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: message lang tags verse SSH_MSG_KEXINIT



>I agree the language negotiation is far from not crystal clear.

If others agree with this point I think this presents a hurdle for
progressing the core drafts.  It seems at the moment that nobody on
the list actually knows how this is supposed to work.

May be if I explain how I see it being used in a unix environment as
an example:

Client sends in languages_client_to_server the current locale as returned
by setlocale()

Server sends in languages_server_to_client the list of all languages it
currently has installed for the ssh server (I'm assuming there is a way
to find this out)

If the client gets back the value of languages_client_to_server in the
list provided in languages_server_to_client it knows that the server
supports its currently running locale (I don't think the client would
actually do anything with this).

If the server gets a value in languages_client_to_server that it sent
in languages_server_to_client then it uses setlocale() to change the
locale of the currently running sshd.


The goal is to have the server run in the same locale as the client,
the client is running in a user choosen locale so if I want to run my
client in "fr" then I set my locale to "fr" before running my ssh
client program.  Using the language fields in the SSH_MSG_KEXINIT the
server gets to find this out and switches its locale to match my client
(if it has the relevant language files installed).

I can't see a use for a client sending multiple entries in
languages_client_to_server in an environment that uses setlocale() (ie
LC_* variables, but I can if the client config has a list of preffered
languages - like what netscape has for webpages).

How does my understanding of this match that of the person who wrote this
section in the core drafts ?

As for the language tags I could see that a subsystem provided by a 3rd
party may not have the same (even any) language files that are provided
by the core server, so it may need to use the message language tags to
say that the messages are different.  Other than that I can't see a general
use for the per message tags.

If my interpretation of the languages_client_to_server and server_to_client
above is correct, must an implmenation that does that also send the
language tag with every message ?  Eg the above resulting in the server
setting its locale to "fr" do I need to add "fr" to every message in the
language tag field or do I only need to add a language tag if it is
different ?


If there is no agreement on this before the WG meeting can we have this
as an agenda item - I believe it is important we have no ambiquous sections
in the drafts before moving them onwards to being RFCs.

Thanks to those who have replied so far (and those that have taken the
time to read this far ;-)) - I know this isn't the most interesting part of
the drafts but it is a very important part for me - particularly if there
is an ambiquity.

One final question has anyone got an implemenation that does anything
with language tags either the client_to_server/server_to_client of the
per message tags ?

--
Darren J Moffat




Home | Main Index | Thread Index | Old Index