Hi Joseph,
Joseph Salowey (jsalowey) wrote:
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.
Correct. RFC 4013, while not perfect, was specifically designed for
usernames/textual passwords.
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.
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
in a comparison. What is typically done to deal with these ambiguities?
RFC 4013 only applies to textual passwords.
For other text that is meant for display to a user we should indicate
language according to RFC 4646.
Yes.
This would include the client
expressing its language preference. Would it also include tags to
indicate the language of the sent text?
Yes.
Thanks,
Joe
-----Original Message-----
From: Alexey Melnikov [mailto:[email protected]]
Sent: Thursday, August 06, 2009 1:46 PM
To: Stephen Hanna
Cc: Joseph Salowey (jsalowey); [email protected]
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 protected] [mailto:[email protected]] On
Behalf Of
Joseph Salowey (jsalowey)
Sent: Thursday, August 06, 2009 3:28 PM
To: [email protected]
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 protected]
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
