[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Document Status?
----- Original Message -----
From: "Dave Crocker" <dhc@dcrocker.net>
To: "Soobok Lee" <lsb@postel.co.kr>
Cc: <idn@ops.ietf.org>
Sent: Wednesday, September 04, 2002 1:34 PM
Subject: Re: [idn] Document Status?
> At 01:10 PM 9/4/2002 +0900, Soobok Lee wrote:
> >IDNA does not extend the LDH namespace, but just redefine xx--yyy subset of
> >the space to have new i18n meanings.
>
> Sorry, but IDNA very much does define an enhanced character space for
> domain names.
true in display and input (that is what i meant), but the norm is ACE in protocols.
of course, some new application protocols may negotiate to use native-encoding instead.
>
> Yes, it also defines a mapping for those enhanced characters onto the
> existing 7-bit ASCII domain name space, but it is important to distinguish
> between the Unicode domain name, versus the ASCII encoding.
>
>
> >Moreover, all the mess around i18n which does not belong
> >to "network standard" , was not addressed and just postponed or ignored.
>
> Please provide descriptions of specific usage scenarios that demonstrate
> technical failings that are special to IDNA.
I am not a vocal opponent of ACE princicple itself.
The most problems also lies in non-IDNA proposals as fas i know.
But, one severe problem special in IDNA is the troyan horse.
If some company don't want to trust and invite IDN and don't want to modify its applications,
but, IDN is encoded in trusted ASCII and penetrate into the applications and
get trusted by the unmodified applications as other trusted ASCII domains. IN protocol world,
Dynamic DNS updates protocols are affected directly by that holes.
Other one may find other special examples of IDN troyan horses.
Soobok Lee