Re: additional core draft nits in need of WG attention.

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

On Sat, Nov 15, 2003 at 05:55:03PM +0100, Niels M?ller wrote:
> Bill Sommerfeld <sommerfeld%east.sun.com@localhost> writes:
> 
> > The proposal during the WG session was that we should add text so that
> > for both algorithms and language tags,
> 
> Why language tags? I think assymmetric choices make a lot of sense:
> For example, sending Swedish messages from server to client (because
> that's the user's native and preferred language, but default language
> or English (because these messags will end up in the server log, and
> the sysadm doesn't read Swedish, or because the client doesn't
> implement any localization for messages it sends to the server).

Neither list of lang tags has anything to do with with logs on the
server.

The lists supposedly represent the languages that the client and server
can have the user "speak at" the server and the languages that the
client and server can "speak at" the user - the latter refers to L10N of
server messages for the user and the former refers to, to what?  to the
language that the user is willing to answer prompts in??.  (Logs just
don't enter into this.)

Now, why would I want to have the server localize messages for me in one
language but accept, from me, answers to [yes/no, ...] prompts in some
other language??  Is there an assumption that servers may have
incomplete L10N support for certain languages?  If so, still, why a
second list of language tags?  Or is there an assumption that users
could be really tricky and prefer one language for reading and another
for typing?  Now, we humans do weird things, so I suppose this could be,
but I'd like to see some examples.

On Solaris, in any case, there isn't much we can do with this language
assymetry, though one can play some games.  E.g., client2server langs ->
LC_CTYPE setting and server2client langs -> LC_MESSAGES setting.  But
really, is this worth it?

> And furthermore, implementations that want to take the easy way can
> just send an empty language list and ignore whatever is received, so
> they gain no simplicity by the ban on assymmetric language lists.

Some implementors don't have a choice and have to implement what G11N
features the protocols provide due to regulations, internal or
otherwise.  Such implementors will gain something from at least a
clarification on what the hell assymetric langtag negotiation really
means.

[...]
> > the negotiated value SHOULD be the same in both directions.
> 
> I think it's a lot better to say that the lists in the KEXINIT
> message, i.e. the *input* to the negotiation, SHOULD be the same for
> both directions.

I agree with this.  But if we find no theoretical use for assymetric
langtag negotiation that we wish to support I would consent to
deprecating one of the two langatg list fields.

> It makes no sense to say that implementations MUST go to the
> trouble[1] of performing independent algorithm selection for both
> directions, and then say that they are allowed, and even recommended,
> to sometimes refuse to use the result. The point of discouraging
> assymetric choices should be to make things simpler for the
> implementations.

For langtag negotiation it may make sense to ignore the negotiation for
one of the directions.  See above.

Cheers,

Nico
--