Subject: [idn] Do we need ACE?

From: Dan Oscarsson <[email-masked]>
Date: Fri, 27 Jul 2001 09:01:37 +0200 (MEST)

John Klensin have written a draft for using a separate class to handle
IDNs. This to really separate the IDN world from the old.

As software following the current rules on what characters are
allowed in a host name should reject queries and responses when
an invalid host name is used, could we get this separation between
old and new by just using UTF-8 in DNS?

If the DNS queries and responses having forbidden characters in host names
are ignored/rejected, an old software will not be able to lookup or
receive records with non-ASCII host names. I know that at least
some resolver routines (it is all in the client, DNS does not forbid
the characters) rejects PTR responses with non-ASCII in them.
If it is like this, the new IDN world will be hidden for all old clients.
This would the result in the old clients will not get any host names
through DNS that they cannot handle. Of course they will still get
invalid names by cut and past between new and old applications, but that
problem we have in all cases.
This way we would get the separate IDN and old DNS world without a new
class, instead we would get it because old software will see IDNs as
invalid.

But I have the feeling that most do not want the break with the old, instead
they want the old software to in some way to be able to handle IDNs too?
Though with all the mess it sometimes feels like, a break with the old
might be better.

   Dan

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 27 Jul 2001 12:09:51 -0500

> old and new by just using UTF-8 in DNS?

I don't think this is a safe assumption, due to the fact that there are
likely to be many applications generating lookups for IDNs based on a
local encoding. Windows-1252, MacRoman, and other charsets that use the C1
codepoint space are able to generate byte sequences that look like UTF-8,
and it would be pretty difficult to test these sequences given that the
label length can be very small.

There's also the consideration that we need to know if an IDN is valid.
Just because an IDN shows up in UTF-8 doesn't mean that it has been
validated through nameprep and application-specific rules.

IOW, we need to reject malformed queries, especially those that look valid
but aren't. In order to do that, we have to tag the queries at the source.
There's no just no other way around it that I can see.

There's also an upside to using the extended label type tags, which is
that future generations can add more tags if they want to. If a UCS-3 CES
were to emerge for the unified 21-bit codepoint space and become
sufficiently popular, then that format can be added with another tag.

One other related point--we may want to encourage implementors to reject
legacy queries that contain eight-bit characters. This would force failure
with applications that are eight-bit "friendly" when they shouldn't be.
I've been looking through the RR types and so far I haven't come up with
anything that requires eight-bit names. I've only found some names that
don't comply with the LDH rules (SRV uses underscore, for example) but
they are still seven-bit ASCII.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/