Large lang tag lists (was Re: Speaking of implementation quirks...)

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

On Thu, Apr 01, 2004 at 10:54:23PM +0200, Niels Mller wrote:
> (You would fail to interoperate with implementations that put
> ridiculously long algorithm or language lists into their KEXINIT
> message, but that should not be common. Only example I'm aware of is
> SSH-2.0-Sun_SSH_1.0 which dumps its complete locale list into the ssh
> language list, resulting in a KEXINIT message of some 1400 bytes plus
> header, and that's a known bug which I hope will be fixed in the next
> release).

The known bug is that it uses locales rather than RFC3066 language tags.

The next release will use RFC3066 language tags and will send its entire
list of installed locales (mapped to langtags).  Do you propose that we
do something different?

I posted sometime last year on inconsistencies in the spec wrt language
tags.  I got precious few comments...  This is the first that I hear of
any issue with the size of our server's KEXINIT packets.  If our current
approach causes problems for anyone then perhaps you might like to
review those comments and make some suggestions.

IIRC I mentioned the possibility of the server not advertising any
langtags and instead relying on the langtag fields of various packets to
convey the negotiated language to the client.

Since then I'm also finding that, while RFC3066 lang tags are really
nice for negotiating a language for localization (L10N), they are not
appropriate for negotiating other I18N matters, such as what encoding to
use in a given channel.  I'm afraid that SSHv2 tried valiantly to get
I18N/L10N right but missed a few things (though perhaps nothing that
can't be corrected with new channel requests).

Nico
--