Re: [idn] Re: 7 bits forever!

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

[ietf removed from cc list]

Edmon Chung wrote:

> These are good ideas and should work well. But for a quicker and
> dirtier way, we could simply continue to let the client do all the
> heavy lifting, as is mandated by IDNA anyway, by failing the request
> anytime it hits a node that does not support UTF8 form and force the
> client to fallback to ACE resolution. This way, the servers dont even
> need to know how to do ACE conversions at all!

There are multiple "clients" in the process. The application client
shouldn't have to mess with fallback unless there is a really good reason
for it (a cache being unable to convert an ACE-only DNSSEC answer being
one of them). In those cases, an EDNS RCODE is a workable way to tell the
application that the original query needs to be reissued in ACE form if it
wants an answer.

For other situations, such as circumnavigating old servers which only
support ACE-ified i18n domain names, letting a resolving/caching server do
the convolutions makes some sense, since those boxes can cache the
canonical UCS answer and referral data, which will help future queries.

I guess what I'm saying is that forcing the application client to pick up
resolver and caching duties doesn't make a lot of sense to me personally
since it will preclude the benefits of caching data.

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