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

Re: [idn] Report from the ACE design team



Dan <Dan.Oscarsson@trab.se> wrote:

> I see a big need of UTF-8, transmitted normalised, not canonicalised,
> 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