Subject: [eap] Re: Language Negotiation

From: [email-masked] (Glen Zorn)
Date: Sun, 27 Oct 2002 22:38:33 -0800

Issue 38 says:

"Currently there is no way to make sure that displayable messages
(such as Notifications) are sent in a language that the user understands.

Resolution: Discuss
Some ideas on how this might be accomplished:

a. Add language type to the first octets of the Notification Request AND
allow a Notification Response to encode an alternate language. However,
the Notification Response is of zero length, so there is a question of
whether this would break existing implementations.

b. Encode the proposed language type in the Identity Request, and allow
the Identity Response to encode an alternate language."

I find both the options above unsatifactory.  For example, the Identity
Request is for all intents optional, so overloading it with language/charset
negotiation seems inappropriate, and breaking existing implementations by
overloading the Notification Response doesn't seem right either.  OTOH, this
seems to be a case where it would be harmless (modulo appropriate defaults)
for an implementation to ignore or NAK an unknown Type, so I would suggest
that language/char set negotiation be done in a new type.  This could be
done via a preference-ordered set of TLVs sent by the client, w/the response
containing a single TLV representing the server's choice.

---

From: [email-masked] (Glen Zorn)
Date: Mon, 28 Oct 2002 00:01:13 -0800

> containing a single TLV representing the server's choice.

Whoops, I think I've got that backwards: should be a set of options from the
_server_, and a single client choice.

>
>
>
>
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>
>