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

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

On Fri, Apr 02, 2004 at 09:34:25AM +0200, Niels Mller wrote:
> Nicolas Williams <Nicolas.Williams%sun.com@localhost> writes:
> 
> > 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?
> 
> No, if you actually support all those languages, then including the
> full list seems to be the right thing to do. About how many are there?

Er, many?  The most locales I've seen installed was ~280.  Of course,
there was much overlap since, for example, "en_US" and "en_US.UTF-8"
both map to the same langtag, "en-us".

So say, maybe, 150 5-charater-long langtags (plus commas), so... close
to 1KB.

Of course, few install so many locales on a server, but it does happen.

> (My code does impose some arbitrary limits on the lenght of language
> and algorithm lists, independent of the maximum packet size, just to
> let me use simpler code that would waste cpu or memory for large
> inputs. I'll have to reconsider those limits if/when there's a
> reasonable use of large lists out there).

See above.  One way to figure out many langtags might be sent is to
figure out how many langtags of the form

<language tag>-<regional variation sub-tag>

are possible given the current registrations.

> > This is the first that I hear of any issue with the size of our
> > server's KEXINIT packets.
> 
> I don't think there's any problem with the current protocol. There may
> be a concern with a hypothetical protocol that changes the
> SSH_MAX_PACKET (the packet size that implementations MUST handle) from
> today's 32K to a significantly smaller value, say 1K, 

Clients have [almost[1]] no reason to send large KEXINITs; servers do,
if they use certs, for example, or have many locales installed.

[1]  In the case of GSS-API keyex w/ optimistic keyex it is possible
     that client could send a very large packet following its KEXINIT.

At least for the initial key exchange I think that we need to mandate
that implementions be able to deal with large packets; after the initial
kex there's no need, I think, to have a large packet support
requirement.

Cheers,

Nico
--