> 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:
Dan, 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 native UCS. 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. Erik > 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. > > Dan > >
