With respect to the internationalization issue noted below, relating to draft-ietf-emu-eaptunnel-req-02.txt, Alexey Melnikov recently pointed out to me that BCP 18 (RFC 2277), section 4.2 says:
Protocols that transfer text MUST provide for carrying information about the language of that text. Protocols SHOULD also provide for carrying information about the language of names, where appropriate. Section 4.1 of that document explains the reason why. Here's an excerpt: Many operations, including high quality formatting, text-to-speech synthesis, searching, hyphenation, spellchecking and so on benefit greatly from access to information about the language of a piece of text. [WC 3.1.1.4]. Internationalization of usernames and passwords has been discussed at length on other lists. Nobody is suggesting in today's discussion that they should have language tags. That is problematic since usernames and passwords often aren't words in any language and the user often doesn't have control over the language settings of the system being used to enter the username and password. But the text being reviewed does not have anything to do with username and password language issues. The text under discussion in draft-ietf-emu-eaptunnel-req-03.txt says "Any strings sent by the server intended for display to the user MUST be sent in UTF-8 format and SHOULD be able to be marked with language information and adapted to the user's language preference." Notice the words "sent by the server intended for display to the user". That would not generally apply to usernames and passwords. Instead, it would apply to messages like "Please enter your password" or "Sorry, you can't sign in right now due to system maintenance". In order to provide for proper formatting and to allow blind users to have those messages properly converted to audio, it is a good idea for our protocol to include a standard place where the EAP authenticator can send language tags with such messages. It's also a good idea for the protocol to include a way for the EAP peer to indicate what the user's language preferences are (if known). That way, the authenticator can send its messages in the user's preferred language (if the software allows the administrator to enter messages in multiple languages and the administrator has chosen to do so). So I submit that the text currently in draft-ietf-emu-eaptunnel-req-03.txt on this topic is a good idea and that it should not be removed. As Joe noted below, there was not consensus on this issue in the EMU session at IETF 75. I suggest that we discuss it on the list. One concern that I heard expressed was that servers may decide to fail the entire exchange if they don't support any of the user's preferred languages. Apparently, some other protocols some seen this behavior when language preferences were sent. Maybe we should add text to the eventual protocol specification advising servers not to do that. Instead, they should fall back to a default language. Are there other concerns? Thanks, Steve > -----Original Message----- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On > Behalf Of Joseph Salowey (jsalowey) > Sent: Thursday, August 06, 2009 3:28 PM > To: emu@ietf.org > Subject: [Emu] Issue #18: Internationalization > > > #18: Internationalization > > Is the use of UTF-8 sufficient or is other tagging necessary. The > following cases need to be considered: > > 1. Usernames and passwords > 2. Prompts and error associated with username and password > authentication > 3. Other textual data > > > Section 4.3.6 > > > > " The payload MAY provide a standard attribute format > that supports > > international strings. This attribute format MUST support > encoding > > strings in UTF-8 [RFC3629] format. Any strings sent by > the server > > intended for display to the user MUST be sent in UTF-8 > format and > > SHOULD be able to be marked with language information and > > adapted to > > the user's language preference." > > > > If UTF-8 is supported, is it necessary to also mark the language? > > Why is language negotiation a SHOULD? > > > > EAP methods such as Identity & Notification don't support this. > > > > and > > > Section 4.5.2 > > > > " The password authentication exchange MUST support user names and > > passwords in international languages. It MUST support > encoding of > > user name and password strings in UTF-8 [RFC3629] format. Any > > strings sent by the server during the password exchange > > and intended > > for display to the user MUST be sent in UTF-8 format > and SHOULD be > > able to be marked with language information and adapted to > > the user's > > language preference. > > " > > Why is it useful to mark usernames and passwords with > > language information on the wire? > > Comment: > > In the Stockholm meeting it was suggested UTF-8 was sufficient, but > there did not appear to be consensus on this. > > -- > Ticket URL: <http://trac.tools.ietf.org/wg/emu/trac/ticket/18> > emu <http://tools.ietf.org/wg/emu/> > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
