Re: [idn] proposals and deadlines

["Adam M. Costello" <amc@cs.berkeley.edu>]

"Eric A. Hall" <ehall@ehsco.com> wrote:

> No, only until ACE can be deprecated.  This will happen on a per-app
> basis where it happens, or with entirely new applications that avoid
> using ACE altogether.  But when it happens, the app should end up with
> a native UTF8 environment, rather than being stuck with ACE.

Okay, now let's think about this hypothetical new application that
uses UTF-8 natively.  It uses UTF-8 to talk to its peers, and UTF-8 to
interact with the user, data files, etc.  Absolutely everything it ever
does with domain names uses UTF-8.  Except one thing: DNS lookups, which
sometimes use UTF-8 and sometimes use ACE.  Why?  Because the UTF-8
resolver interface you have postulated gives up when EDNS fails.  Our
application has no control over whether the local DNS server supports
EDNS, or whether any particular caching DNS server between the local
server and the target supports EDNS.  Therefore, the application will
need to do its own fallback to the old resolver interface, which means
the application will need to be able to perform ACE encoding, so it is
not completely free of ACE.

But your stated goal is to avoid having the application stuck with ACE.
If there were a UTF-8 resolver interface that would make a best effort,
instead of giving up when EDNS is unavailable, then the application
could truly eliminate all traces of ACE within itself.  Isn't that what
you want?

> In any event, the application *MUST* perform the conversion, since it
> is the only thing that knows all of the ramifications from failure.

I'm not trying to assert that providing a best-effort UTF-8 resolver
interface will magically free applications from doing ACE conversions.
Of course it won't, because there are many reasons unrelated to DNS that
applications might need to use ACE.  But even after applications manage
to eliminate all those other reasons, they still cannot completely free
themselves of ACE unless this best-effort UTF-8 resolver interface
exists.

> You are also working on the assumption that fallback will happen
> frequently.

No I am not.  I am working under the assumption that, for an application
programmer, it doesn't matter whether the fallback happens frequently
or rarely, either way the programmer still needs to write code for
doing it.  The only way to avoid that code in the application is if the
fallback happens *never* (that is, never in the application, but instead
in the resolver).

> Your proposal does not provide this differentiator, and allows corrupt
> data to enter the query chain on the same footing as legitimate data.

What do you think my proposal is?  I have not suggested that calls to
the old resolver interface should ever perform EDNS queries or ACE
transformations; the old interface should continue to do exactly what it
does today.  I have not suggested that DNS servers should ever put 8-bit
data into old-style responses.  I have not suggested that resolvers
falling back from EDNS to DNS should ever put 8-bit data into old-style
queries.  I don't see how I'm allowing corrupt data to enter anything.
If you still think I am, you'll have to walk me through a concrete
scenario.

> If [applications] know they don't have access to UTF8 IDNs, they will
> not negotiate the use of UTF8 protocol-specific extensions, and will
> not generate UTF8 queries.

Just because my local DNS server doesn't support EDNS, that doesn't mean
I should speak ACE to my application-layer peer.  If that peer and I
both support UTF-8, then we should speak UTF-8 to each other, regardless
of the capabilities of my name server, in order to reduce the risk of
ACE leakage.

AMC