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

Re: [idn] Future difficulties because of IDNA



--On 2002-01-29 09.31 +0100 Dan Oscarsson <Dan.Oscarsson@trab.se> wrote:

> 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:
> 
> 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.

What you object to is the transport encoding used, and I don't understand
why you see that as such big deal from a DNS perspective.

The _real_ problem is leakage from the DNS to various applications. If we
go for some compressed binary encoding (which is the best from DNS
perspective, and not UTF-8, UCS2 or whatever else already exists) like
Punycode without the base32 at the end, then you definitly will see that
binary stuff inside application layer protocols aswell.

Regarding your bullets above, (1) will be something needed anyway when you
introduce EDNS0 or whatever other signalling which will be introduced
anyways, because of various needs and (2) no, I don't agree for a second.

Neither of your arguments above have any real impact on calculation costs
etc.

And, no, there is _no_ consensus on the namedroppers list as your mail on
this list might envision. The discussion there is basically a discussion
between you and Erik, which is the responsible AD for this group, and the
two of you don't agree.

   paf