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: 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
