--On Monday, 03 November, 2003 13:24 -0500 Jeffrey Altman
Thank you for your continued rationality.
I do not have a strong opinion on what the solution to this
problem should look like. However, I am concerned about some
related problems. Local mail parts are often derived from or
are usernames. Administrators like the ability to be able to
assign a single name to an end user for the purpose of user
identity. It is my hope that whatever conclusion is reached
will ensure that the i18n mechanism will allow this single
single name to be compatible with existing naming conventions
utilized with Kerberos, SASL, X.509, etc. It would I believe
detrimental to everyone if the various protocols which must
manipulate user identities did not have a common way of
I think this is an important point. The question is what to do
about it. One extreme view is that we should, because of those
issues, say "usernames must be confined to simple, IA5, strings
because that is the only way to get guaranteed interoperability
with all of these things with a single string". I don't think
that is going to fly in the areas in which people are really
determined to internationalize usernames and email addresses.
Nor do I think that those folks are going to accept an encoding
that causes user names to look as expected in some contexts and
a hard-to-verify form in others -- users won't see it as the
same, or common, representation of their names. So, at worst,
we should be sure that people understand the tradeoffs,
regardless of what i18n system is adopted: localization versus
global interoperability, localization versus a single identifier
as username, mailbox address, and Kerberos/ SASL/ X.509
certification or credential name.
I'll try to work some words to that effect into -02 of my email
document so it doesn't get lost.
Much more than that we probably can't do, any more than saying
"I18n Bad" or "I18n risky" or "I18n less interoperable" is going
to prevent anyone who thinks they are needed from deploying
_something_ for very long.