Patrik F�ltstr�m <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]]
Sent: Monday, July 16, 2001 2:54 PM
To: [EMAIL PROTECTED]
Subject: Re: [idn] Reality Check
Russ Rolfe <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
