Re: [idn] proposals and deadlines

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

"Adam M. Costello" wrote:
> 
> "Eric A. Hall" <ehall@ehsco.com> wrote:
> 
> >  3) Resolvers present two separate APIs: one for legacy names, one for
> >     IDNs.
> >
> >  5) The UTF8 IDN resolver calls would generate messages with an EDNS
> >     extended label type.
> >
> >  7) In those cases where the extended lookup failed, the client would
> >     have to convert the UTF8 IDN to ACE
> 
> It would not only ACE-encode IDNs in DNS queries, but also ACE-decode
> IDNs in DNS responses (because the application is using the UTF-8 API
> and expects a UTF-8 answer), right?
> 
> This looks like it would work, but if I'm writing a resolver, and I'm
> supposed to implement ACE-encode, ACE-decode, and EDNS, I'm probably
> going to think to myself, "Hmmm, if I just pretend that the EDNS lookup
> always fails, then I won't have to bother implementing EDNS, and the
> application will never know the difference."

Couple of things:

a) the resolver doesn't encode anything, it just passes whatever the
client application passed to it via one of the APIs

b) the fall-back mechanisms for UTF8-to-ACE would need to be specified for
each application. How ESMTP chooses to deal with a failed UTF8 lookup will
be different from how HTTP chooses to deal with it, and so forth.

c) I am going to assume that there will be libraries for most OSes that
provide ACE-encode and ACE-decode functions, since those are already
required for ACE presentation services

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