--On 2002-01-29 09.31 +0100 Dan Oscarsson <[EMAIL PROTECTED]> 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
