Subject: Re: [idn] Report from the ACE design team

From: Dan <[email-masked]>
Date: Thu, 28 Jun 2001 12:19:57 +0200 (MEST)

>
>>If ACE is intended to be used forever
>
>if transition is long, then long ~= forever.
>
>>(also probably meaning that
>>we will hav 63 byte limit forever), compression is most important.
>
>so we are in agreement!, compression is most important ;-)))
>

Not at all. Simplicity is most important. By making ACE not being perfect
we give everybody a good reason to switch to UTF-8.

I see a big need of UTF-8, transmitted normalised, not canonicalised,
over the DNS protocol. ACE+nameprep (as defined today) will destroy data
in names, that is unacceptable for me and breaks current semantics of DNS.

Also, the ACE+nameprep solution do not cover the parts of the DNS protocol
that contains character data outside "host names".

While ACE+nameprep is ok as a backward compatibility is is not a working
solution for an internationalised DNS. Even if the IDN working group
has its focus on "host names", I think it must promote a solution
for the entire problem of DNS internationalisation, not just a
backward compatibility solution for having non-ascii host names.

   Dan

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 28 Jun 2001 22:52:14 +0000

Dan <[email-masked]> wrote:

> over the DNS protocol.

Let's distinguish between IDNs used as DNS queries versus IDNs appearing
in resource records (like PTR and CNAME records) in DNS responses.
Using canonical IDNs in request queries has the advantage that the DNS
server doesn't need to do per-request canonicalization, it suffices
to canonicalize each name once when the zone file is loaded.  And the
client loses nothing if the resolver performs canonicalization before
sending the request, because the application still has the original
name.

In DNS responses, the query should (must?) be copied exactly from the
request, but for resource records like PTR and CNAME it costs the server
almost nothing to remember the original non-canonical name and send that
back, which might be nicer for the user.

So for the UTF-8 protocol, I see nothing wrong with requiring nameprep'd
UTF-8 in queries but allowing non-nameprep'd UTF-8 in resource records.

In general, I suspect that most application protocols should not require
nameprep'd UTF-8 on the wire, but should allow any UTF-8, and let
the receiver apply nameprep if it needs to compare the name.  A few
protocols (like DNS) may require the sender to apply nameprep in some
cases as an optimization.

> ACE+nameprep (as defined today) will destroy data in names, that is
> unacceptable for me and breaks current semantics of DNS.

Many of the proposed ACEs (including DUDE) are capable of supporting
mixed-case annotation: the use of uppercase letters in the ACE to
suggest toupper() conversions in the Unicode string.  This feature is
controversial among the ACE design team, but it sounds like you would
favor it.

AMC