Re: [idn] proposals and deadlines

["Eric A. Hall" <ehall@ehsco.com>]

"Adam M. Costello" wrote:
> 
> "Eric A. Hall" <ehall@ehsco.com> 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/