Subject: Re: [idn] proposals and deadlines

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 15 Jul 2001 23:13:31 -0500

"Adam M. Costello" wrote:
> 
> "Eric A. Hall" <[email-masked]> wrote:
> 
> > If this [8-bit] data is passed to oldAPI, and then the resolver says
> > "oh goodie, UTF8!", converts it to ACE and then pushes it into the
> > query chain, unexpected results will absolutely occur.
> 
> Indeed.  But in my previous message I explicitly stated that I don't
> want the resolver to perform ACE transformations for calls to the old
> API.  I want the old API to continue to function just like it does
> today.  I would have the resolver perform ACE transformations only in
> conjuction with the new API.

Well then, you are halfway there. :)

> > Furthermore, the resolver must not perform the conversion because it
> > doesn't know what the application is going to do with the data.  If
> > a resolver answered in the affirmative to a probe-test, then the
> > application may wrongly perform a subsequent task (such as an
> > authentication request).
> 
> As long as the resolver and the application agree on the semantics of
> the new API, there is no problem.  The semantics I propose for the new
> resolver API are: "Please take this UTF-8 query and do your best to
> give me back a UTF-8 response, using any DNS versions/extensions you
> please."

This would break things that rely on the domain name being preserved. With
X.509 the client and the server have to agree on the domain name, for
example. If the resolver recombobulates a UTF-8 domain name from ACE
output, then the client and server are likely to have different ideas of
what the domain name should be.

One of the benefits to the dual-usage approach is that it is possible to
store raw ACE strings as UTF-8 strings. This means that the client and
server can use the new API to successfully resolve a legacy domain name
which has been manually encoded and stored as raw ACE data. This keeps
this kind of stuff from breaking.

and all for the low, low price of a wee bit of extra memory

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

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 16 Jul 2001 21:08:03 +0000

"Eric A. Hall" <[email-masked]> wrote:

> This would break things that rely on the domain name being preserved.
> With X.509 the client and the server have to agree on the domain name,
> for example.  If the resolver recombobulates a UTF-8 domain name from
> ACE output, then the client and server are likely to have different
> ideas of what the domain name should be.

Not so.  This is exactly what nameprep is for.  By definition, two names
X and Y are equal iff nameprep(X) and nameprep(Y) are byte-for-byte
equal.  The "recombobulated" name Y will always be equal to the original
name X according to this definition.  If an application works for X
but fails for Y then the application is broken, not the DNS.  Even
if DNS didn't use ACE, you never know when a domain name might get
transferred across some 7-bit protocol, so all applications must respect
this definition of equality.

AMC

---

From: Martin Duerst <[email-masked]>
Date: Tue, 17 Jul 2001 17:07:23 +0900

>this definition of equality.

Obviously ACE isn't needed here; the only condition is that you compare
them using the same encoding (UTF-8, today's choice of ACE, or whatever),
or you can compare characters directly.

And the above also shows the danger of doing too much folding in nameprep,
or at the wrong place. As much as possible, names should only be stored
in the namepreped version. In operational terms, it would be better if
a dn server would reject a zone file with non-namepreped names
(whether in ACE or in UTF-8 or whatever, as specified), and a nameprep
utility were available separately, than if everything would just get
namepreped without reflecting the errors back.

Regards,   Martin.