[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] Debunking the ACE myth



Adam M. Costello wrote:

>> 1) All names are transmitted in a form/semantic insensitive format
>> (that is what nameprep is for) so that names can be compared using
>> binary matching.

>> 1) is the IDNA case and also in Microsofts draft-skwan-utf8-dns.  This
>> results in that for example upper case characters cannot be used in
>> responses from DNS.
>
>For the UTF-8 case, as I've pointed out before, it is not necessary
>for DNS queries and DNS responses to use the same rules.  It would
>be perfectly reasonable to use nameprep'd UTF-8 in queries and
>non-nameprep'd UTF-8 in responses.
>
>For the ACE case, as I've pointed out before, mixed-case ACE can easily
>be used to represent mixed-case Unicode.  You would lose things like
>circled-digit-one (which becomes a regular digit-one), but mixed case
>can be conveyed in ACE.
>
>By the way, it would be pointless to combine ACE with option 2 (no
>nameprep).

1) above is used to allow only binary matching to be done on a DNS server.
This means that the client is required to send nameprepped names to
the server, if they are going to match. If we allow a response to
have non-namprepped names (ACE or UTF-8), only a IDN aware client can
use that name to send new queries because only those will do nameprep
before sending the query. So all other clients may fail when using
a name returned from DNS.

You can allow non-nameprepped answers if you require the DNS server
to do nameprep on names in queries (if needed). For those who
think it is too expensive to do nameprep in the server (it is not for
areas like latin, greek or cyrillic) to have most names in queries
being nameprepped might reduce the burden on the server. That depend
on if a already nameprepped name can quickly be checked.

   Dan