Subject: Re: [Emu] Issue #18: Internationalization

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 8 Sep 2009 18:14:01 -0700

So if I understand correctly the recommendation for usernames and
passwords is to follow something like SASLPrep [RFC4013] or Net-UTF-8
[RFC5198], but they do not require language tags.  I haven't looked at
RFC 5198 yet, but RFC 4013 seems uncertain as to when it is applicable.
For example it is often common for an email address to be used as a
username, but this seems to be out of scope of 4013.  Also how do you
know if passwords are treated as character data or binary data when used
in a comparison.  What is typically done to deal with these ambiguities?

For other text that is meant for display to a user we should indicate
language according to RFC 4646.  This would include the client
expressing its language preference. Would it also include tags to
indicate the language of the sent text?  

Thanks,

Joe

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]] 
> Sent: Thursday, August 06, 2009 1:46 PM
> To: Stephen Hanna
> Cc: Joseph Salowey (jsalowey); [email-masked]
> Subject: Re: Issue #18: Internationalization
> 
> Hi Stephen,
> 
> Stephen Hanna wrote:
> 
> >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.
> >
> Correct. UTF-8 usernames/password need some normalization 
> instead (e.g. 
> SASLPrep [RFC4013] or Net-UTF-8 [RFC5198]).
> 
> >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."
> >  
> >
> As a side note: this would need a reference to RFC 4646.
> 
> >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).
> >  
> >
> Right.
> 
> >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.
> >
> Agreed.
> 
> >Are there other concerns?
> >
> >Thanks,
> >
> >Steve
> >  
> >
> >>-----Original Message-----
> >>From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of 
> >>Joseph Salowey (jsalowey)
> >>Sent: Thursday, August 06, 2009 3:28 PM
> >>To: [email-masked]
> >>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
> >>[email-masked]
> >>https://www.ietf.org/mailman/listinfo/emu
> >>    
> >>
> 
>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Sep 2009 10:57:06 +0100

Hi Joseph,

Joseph Salowey (jsalowey) wrote:

>[RFC5198], but they do not require language tags.
>
Correct. RFC 4013, while not perfect, was specifically designed for 
usernames/textual passwords.

>I haven't looked at
>username, but this seems to be out of scope of 4013.
>
RFC 4013 was deliberately vague on this (and I disagreed with the author 
on this), but it is frequently used for email-like usernames. This is 
how it is used in SASL.

>Also how do you know if passwords are treated as character data or binary data when used
RFC 4013 only applies to textual passwords.

>language according to RFC 4646.
>
Yes.

>This would include the client
Yes.