Re: [idn] Reality Check

["Adam M. Costello" <amc@cs.berkeley.edu>]

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