Subject: Re: [idn] Future difficulties because of IDNA

From: Dan Oscarsson <[email-masked]>
Date: Tue, 29 Jan 2002 15:54:23 +0100

This include comments to what Patrik Fältström, Erik Nordmark and
Dave Crocker 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:

As Erik said, "if" is better then "when" and from the what I can see
I think it is possible that it will be ACE forever until DNS is replaced
with DNS-NG (at least that should happen some day). While I very much
dislike solutions layered on top of ASCII due to inefficiency and
due to the big problem with application developers that never
understands that you always must translate from the ASCII layer to
native encoding before interacting with users.

As Patrik said, there is no consensus on the namedroppers list.
Actually there is very little response except from 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.

Yes, as Patrik says EDNS will result in the above.
But if you use UCS and EDNS you may get one additional query.
I know Dave do not think this is right, so I will try to give a quick
comment on why:
If you only allow IDN by having UCS aware servers, all clients
can send a query using either ACE or UCS and get the correct answer.
If you also allow IDNA servers, the IDNA servers can only give the
correct anser if the query is in ACE. This means that a UCS client
who want to send a UCS query, have to know if the server handles UCS
or not. If the answer is not, the UCS client have to send the query
using ACE. To test if the server can handle UCS, a separate query
must be sent. Here is the overhead.

>> 
>> 2) DNSSEC will probably be much more complex to handle due to
>>    having both ACE encoded and native UCS labels.
>> 

The complexity here is what I found out from my talk with Erik. You
might get away from most of it. In short this is because DNSSEC
signs RR-sets and with both UCS and ACE you have two representations
of the same label. The signing will be different depending on which you
use (unless you say signing should always be done on for example the
ACE form, but this looks wrong as an UCS client should never see
any records with ACE if they are sent from a UCS server).

   Dan

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Jan 2002 07:43:29 -0800

At 03:54 PM 1/29/2002 +0100, Dan Oscarsson wrote:
>  While I very much

MIME has not suffered the fate you claim is inevitable, yet is the same 
design approach as IDNA.

>Actually there is very little response except from Erik.

Lack of response on a mailing list usually means that people do not feel 
that the issue being raised is worth responding to.  In other words, it is 
an implicit vote of no confidence for the concern or suggestion being raised.

>If you also allow IDNA servers,

There will be no IDNA servers.

DNS servers do not need to be modified to support IDNA.  IDNA is supported 
by the software that creates the string and the software that does the 
query.  The software that services DNS requests and holds DNS data does not 
need modification.

>the IDNA servers can only give the
>correct anser if the query is in ACE.

This is not correct.

>signs RR-sets and with both UCS and ACE

Oh.  You mean that IDNA adds complexity, when (and if) we try to introduce 
an encoding that is more efficient.  (Please remember that 8-bit unicode is 
still an encoding.)

You are therefore making that claim that it is more complex to have an 
"interim" scheme.  Well, duh.

It is the nature of transitions that they incur "inefficiencies", if the 
transition is done in a way that preserves the installed base.

So the bottom line is that IDNA does not, itself, creates any special 
concerns for DNSSec, contrary to you claim.

At 09:31 AM 1/29/2002 +0100, Dan Oscarsson wrote:
>I see a risk that IDNA will kill native support for internationalisation
>of DNS.

Apparently you are unaware that 8-bit unicode is not at all more "native" 
than IDNA.  Both are encodings.  One is a bit more efficient, but requires 
creating an entirely new infrastructure.  The other works on the existing 
infrastructure.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464