RE: [idn] Reality Check

["Russ Rolfe" <rrolfe@windows.microsoft.com>]

Patrik Fältström <paf@cisco.com> wrote:

> I am extremely worried that what I see on this list is IDNA (which 
> include nameprep) or "just send UTF-8 without nameprep".

In my example, it was an over site not to include NamePrep.  I do see the importance of this feature and believe it is import no matter what encoding we choose.

Regards, Russ
Microsoft

-----Original Message-----
From: Adam M. Costello [mailto:amc@cs.berkeley.edu] 
Sent: Monday, July 16, 2001 2:54 PM
To: idn@ops.ietf.org
Subject: Re: [idn] Reality Check


Russ Rolfe <rrolfe@windows.microsoft.com> wrote:

> I see no wrong asking users to take some of the responsibility of 
> moving to a new technology (i.e. having two addresses, adding a line 
> as part of the signature pointing to non-IDN address, requesting 
> System-Operators to upgrade)?

In other words, you'd rather create technical difficulties for users in order to ease the technical burden on engineers (by freeing them from ACE).  I'll concede that it may be possible to do so, but in my opinion it's the wrong tradeoff.  Users are far more numerous than engineers, and less able to deal with technical challenges.  I think it makes more sense to increase the technical burden on the engineers in order to make things easier for the users.

> IMHO if we go with an ACE only solution, it will never go away in the 
> long run.

If the engineers really hate ACE, they will move toward other mechanisms at every opportunity, and ACE will become less common over time.  If the engineers don't mind using ACE, then there's no problem with it remaining common forever.

In either case, I think the desire of users to see the native characters will be sufficient pressure to make ACEs very rarely visible to users. After that, users won't care whether ACE is truly gone or merely hidden.

Patrik Fältström <paf@cisco.com> wrote:

> I am extremely worried that what I see on this list is IDNA (which 
> include nameprep) or "just send UTF-8 without nameprep".

Nitpick:  The problem isn't sending non-nameprep'd UTF-8.  The problem is receiving UTF-8 and neglecting to run nameprep on it before comparing it with something.  Even with ACE, after a receiver decodes the ACE to obtain a Unicode name X, it must verify that X == nameprep(X), otherwise it's susceptible to spoofing.  But you still have a point: The ACE-decoding function is likely to have the nameprep check built in, whereas nameprep is more likely to be forgotten if UTF-8 is received. Still, I don't think we could stop new protocols from using UTF-8, and I don't think we'd even want to, so we just have to emphasize the importance of using nameprep for comparing IDNs.

AMC