[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Future difficulties because of IDNA
> From the discussions I have had on the namedroppers list I see
> that at least two things will be more difficult when we introduce
> native UCS in DNS because of IDNA:
Your summary of that discussion makes the unstated assumption
that the issue is "when".
I think the issue is "if" it makes sense to have what you call native UCS
in the DNS packets.
So far nobody has managed to convince me that the benefit of that improved
encoding efficiency in the DNS packets outweigh the costs relating to
transition combined with DNSsec; what you list here are some of those issues
with an ACE to native UCS transition.
Staying with ACE encoded strings in DNS packets forver avoids this complexity.
If we can get the application protocols to move towards native UCS support
that would be very good. But that doesn't require the DNS packets to contain
BUT: the WG should now really go off and read the documents in WG last call
carefully to make sure that they are as clear as they can be.
> 1) Additional overhead.
> This is because of IDNA, a UCS client MUST first query the server
> if the server can handle UCS, and then send the real query.
> Without IDNA the client could send the query without knowing
> if the server supports UCS or not.
> 2) DNSSEC will probably be much more complex to handle due to
> having both ACE encoded and native UCS labels.
> I see a risk that IDNA will kill native support for internationalisation
> of DNS.