Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 31 Oct 2003 17:24:33 +0100

[email-masked] writes:
> So my question remains: are we doing the 3 billion asians a favor by 
> forcing them to be able to tell the difference between e-caron and 
> e-breve?

I got some advertising for www.renault-branchenloesungen.de the other 
day, because I'm part of the target group "clearly" expressed by that 
domain name.

Is Renault doing the people on this list, or those three billion Asians, 
a favour by using such an incomprehensible domain name? Not? But I 
don't think it's a problem either.

And I don't think the number of people who need to deal with e-macron, 
but don't know Lithuanian or Lettish, will be big. It'll be 
self-regulatingly small. People like you (Valdis), who might expose 
e-macron to us foreigners, tend to make our lives easier by changing 
the way you spell your names. Sure, if you were to insist that we (or 
those three billion) spell your name correctly, you'd cause some pain. 
But you don't, so that macron of yours isn't a problem for us.

(Btw, are those the right languages for e-macron? I'm fuzzy on that.)

--Arnt

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 03 Nov 2003 13:24:39 -0500

John:

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 representing them.

Jeffrey Altman

---

From: John C Klensin <[email-masked]>
Date: Mon, 03 Nov 2003 12:19:56 -0500

Folks,

I've just spent several hours reading my way through much of 
through the long and fascinating thread caused by the BOF 
announcement.  I should probably just remain silent, but the 
traffic causes me to have a few thoughts.  Some of them have 
been mentioned on the list in one form or another, but let me 
try to draw them together in the hope of separating them from 
the noise.

As a preface, sound bites are a lot of fun, especially among 
politicians and demagogues.  To the extent that our goal is good 
design and engineering, we need to do serious analysis and try 
to read and understand serious analysis.  I am appalled at the 
number of postings on this list that seem to indicate people 
willing to state positions, very strongly, without having read 
any of the relevant drafts.  Whatever is going on in the 
problem-statement list and WG, that may be a much more severe 
threat to the IETF's ability to do good work than anything 
[else] they have gotten fixated on.

First, I am strongly committed to interoperability.  Without it, 
much of what makes the network attractive to many of us 
disappears.  We don't then end up at the "500 one-way channels 
of pointless entertainment" that many of us fear, but every 
significant step taken away from global interoperability --not 
just of the bits, but of user-level applications-- costs us some 
of the properties and potential for an Internet that enables 
human communications.

While me may disagree on many things, including the best way to 
preserve interoperability, I am convinced that Paul, Adam, and 
Martin are also committed to that goal.  I hope the rest of you 
are too --I've singled them out only because their names are on 
documents that represent approaches to the email 
internationalization problem -- if you aren't, these discussions 
are pretty pointless.

Second, it is clear to me that there is a tradeoff between 
completely convenient localization and global interoperability. 
In a completely local environment, I can not only use local 
characters and character codings, but I don't even need to label 
them.  Identifying the codings in use, or even protocol variants 
in use, doesn't require international standards -- they are 
needed only if one wishes to get some (or considerable) 
localization while preserving some (or, I hope, considerable) 
global interoperability.

Third, while it would certainly make global interoperability 
easier, there is no way to prevent people from deciding to use 
local characters, and maybe even local codings, in local 
environments.  They will do it.  They will believe (probably 
correctly) that they have good reasons for doing it.  Our 
choices are between

	* Finding a rational, plausible, global way to let them
	do it while still preserving global interoperability or
	
	* Not doing that and ending up with a potentially large
	number of local solutions that won't interoperate or, at
	best, will require using different protocols for local/
	national/ in-language email and for global
	communication.

There is some superficial appeal to the second choice, i.e., to 
saying "the world will communicate using Roman characters; 
anyone who wants to do something else will need to use local 
systems among people who share the relevant language and 
character sets".  But it won't work, as anyone who has been 
through the age of information-losing gateways among Internet 
mail/ PROFS/ cc:mail/ MSMail/ X.400/ etc., etc., can attest. 
Bad idea.  Doesn't work well and often works very badly. 
Assume it is going to be an internationalization standard or a 
significant drop in interoperability.  No other choices.

Fourth, there was, and is, a case to be made that 
internationalization of domain names is unnecessary and dumb 
because, in that view, domain names are protocol elements that 
need absolutely maximum interoperability and can be hidden from 
users.  Those who advocated that position lost the argument -- 
probably as soon as the first user saw the first web URL.  But 
there is no such case to be made for email addresses except, 
possibly, among those who entertain the fantasy that "The 
Directory" will take over the Internet.   Well, it may be really 
sad, but that plan has been over for years and years.  Hasn't 
happened and, absent some miracle, isn't going to happen.   The 
argument for why one can't get away without internationalization 
(or at least localization) of email addresses is in my draft. 
If you care and haven't done so, go read it.  If you are not 
willing to read that, you probably aren't reading this either.

Finally, the difference between the proposal from Paul and Adam 
and mine hinges on some very fundamental principles about 
architecture and deployability.  One way to oversimplify the 
difference is that mine is better optimized for 
fully-internationalized local environments in the short term, 
and a fully-internationalized world in the longer term (where 
"fully-internationalized" contemplates an environment in which 
English is just another language).  The Paul/Adam proposal is 
much better optimized for environments in which a user who wants 
or needs non-ASCII characters is isolated in a mostly-ASCII 
environment.  And it involves tampering with far few pieces 
that, in my few, we cannot pretend to ignore.

Is it possible to focus on those differences, and on the 
question of what the best way is to accomplish 
internationalization _given_ that it is an issue we need to deal 
with, rather than spending energy debating whether the users 
involved really should want it?

thanks
    john

---

From: John C Klensin <[email-masked]>
Date: Mon, 03 Nov 2003 14:21:19 -0500

--On Monday, 03 November, 2003 13:24 -0500 Jeffrey Altman 
<[email-masked]> wrote:

> 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

Jeffrey,

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.

regards,
     john

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 03 Nov 2003 14:46:49 -0500

John C Klensin wrote:

> Jeffrey,
>
> 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.
>
> 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.
>
> regards,
>     john
>
John:

My primary concern with the i18n issues are those of wire representation 
leakage at the user interface layer.  The IDNA solution has resulted in 
some nasty implications for the security community because it mandates 
the leakage of ACE representations of IDNs to the end user when the 
local system architecture cannot support the appropriate i18n display 
and input mechanisms.  This decision is wonderful for short term 
interoperability because it allows the existing end-user application 
infrastructure to be used during the migration process. 

The problem it causes for the security community is that the primary 
goal of the authentication process is to mutually authenticate two 
entities to one another.  This usually usually means verifying a name in 
some fashion.  This can either be done by using the name as input to 
some cryptographic operation (SRP,Kerberos,...) or by associating the 
name with an information bundle protected by a cryptographic operation 
(X.509).  In either case, we have complicated the situation immensely by 
moving from a model in which each entity has one unique name to a model 
in which each entity may have multiple names.  Future revisions to the 
affected protocols can deal with the change in the model, but what of 
the existing deployments which cannot? 

I would much rather see an incompatible protocol or architecture which 
requires a short amount of severe pain than one that compromises the 
architecture for the lifetime of its future deployment.

Future versions of SASL and Kerberos are going to standardize on the use 
of a normalized form of Unicode represented in UTF-8 as the wire format 
for strings.  X.509 already can support Unicode.  If it were possible to 
insist that only Unicode aware applications could use i18n names then we 
would see a much more rapid transition to newer protocol implementations 
across the board.  From my perspective, applications should be free to 
provide their own mechanisms for displaying i18n names when the 
operation system or windowing system does not support them.  However, 
the wire representations should not be leaked through.  The applications 
should always be requires to convert to Unicode before passing the 
strings the various protocol libraries.  This would allow us to develop 
the network infrastructure independent of the user interface 
infrastructure.  It is unfortunate that this separation cannot be 
maintained.

Jeffrey Altman

---

From: John C Klensin <[email-masked]>
Date: Mon, 03 Nov 2003 15:03:20 -0500

--On Monday, 03 November, 2003 14:46 -0500 Jeffrey Altman 
<[email-masked]> wrote:

> John C Klensin wrote:
>
>> Jeffrey,
>>
>> 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
>> 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.
>>
>> regards,
>>     john
>>
> John:
>
> My primary concern with the i18n issues are those of wire
> representation leakage at the user interface layer.  The IDNA
> solution has resulted in some nasty implications for the
> security community because it mandates the leakage of ACE
> representations of IDNs to the end user when the local system
> architecture cannot support the appropriate i18n display and
> input mechanisms.  This decision is wonderful for short term
> interoperability because it allows the existing end-user
> application infrastructure to be used during the migration
> process.

Yes. I hope that, by the time the IDNA work drew to its end, 
everyone involved and supporting it understood that 
implication... even if I was not successful in getting it 
explicitly into the relevant documents.

> The problem it causes for the security community is that the
> primary goal of the authentication process is to mutually
> authenticate two entities to one another.  This usually
> usually means verifying a name in some fashion.  This can
> either be done by using the name as input to some
> cryptographic operation (SRP,Kerberos,...) or by associating
> the name with an information bundle protected by a
> cryptographic operation (X.509).  In either case, we have
> complicated the situation immensely by moving from a model in
> which each entity has one unique name to a model in which each
> entity may have multiple names.  Future revisions to the
> affected protocols can deal with the change in the model, but
> what of the existing deployments which cannot?
> I would much rather see an incompatible protocol or
> architecture which requires a short amount of severe pain than
> one that compromises the architecture for the lifetime of its
> future deployment.

This is, I think, a fairly persuasive argument for the "no 
internationalization of email addresses until your 
infrastructure is upgraded" approach in my draft.  It also 
argues, I think, that the option of having the domain name in a 
mailbox string in either UTF-8 or punycode should be eliminated, 
requiring UTF-8 only and that any of the localization variations 
that start from "@" is an ASCII character too" should be 
avoided, however regretfully.   Of course, as I have been trying 
to point out, this remains all about tradeoffs -- not only 
between options, but about where the pain is felt.   My hope is 
that we can analyze those carefully and make good and explicit 
decisions about them, avoiding any temptations to reach for the 
snake oil or pixie dust.

> Future versions of SASL and Kerberos are going to standardize
> on the use of a normalized form of Unicode represented in
> UTF-8 as the wire format for strings.  X.509 already can
> support Unicode.  If it were possible to insist that only
> Unicode aware applications could use i18n names then we would
> see a much more rapid transition to newer protocol
> implementations across the board.  From my perspective,
> applications should be free to provide their own mechanisms
> for displaying i18n names when the operation system or
> windowing system does not support them.  However, the wire
> representations should not be leaked through.  The
> applications should always be requires to convert to Unicode
> before passing the strings the various protocol libraries.
> This would allow us to develop the network infrastructure
> independent of the user interface infrastructure.  It is
> unfortunate that this separation cannot be maintained.

Ack.  See above.

    john

---

From: masataka ohta <[email-masked]>
Date: Wed, 05 Nov 2003 02:05:36 +0900

John;

> Third, while it would certainly make global interoperability easier, 
> there is no way to prevent people from deciding to use local characters, 
> and maybe even local codings, in local environments.  They will do it.

That something is technically possible does not mean it useful.

In this case of localized (not internationalization at all) email
addresses, it is not useful and will not be used widely to be
ignored safely.

> They will believe (probably correctly) that they have good reasons for 
> doing it.  Our choices are between
> 

Mails with localized addresses do not interoperate globally
just beause they use localized addresses that that is a
meaningless goal.

> Fourth, there was, and is, a case to be made that internationalization 
> of domain names is unnecessary and dumb

Right. Localized domain names are not useful and not used at all,
at least in Japan. Maybe, there are some names registered, as
protection purposes, but none are used.

Even if there is a few countries where such domain names are used,
it proves that the issue is purely local with no international
issues and no global interoperability is necessary.

You can argue that localized domain names was useful for registries
and registareres, as names registered for protection purposes
increased their revenues, though I guess, in Japan, that
outcome of advertisement fee on various media exceeded income
of registration.

But, even such argument is not applicable to email names.

						Masataka Ohta