Re: [idn] proposals and deadlines

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

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

> Users don't want to write "ask jane@aq--gobbledygook for info". Users
> don't want to see it in netstat output. Etc.
>
> > If you want to entice me to use the new resolver API, you're going
> > to have to offer more incentive. Having the resolver perform the ACE
> > conversions for me would do it.
>
> You are certainly free to try embedding ACE into your data, displaying
> it properly in all situations, managing clipboard representations of
> it (did they want the visual representation or the mailto link?),
> educating users on its syntax, and so forth. Not having to do any of
> that should be compelling enough.

I must have completely failed to make my argument understood, because
your response is unrelated to the point I was trying to make.  Let me
try again.

You said that in your proposed architecture, if the EDNS/UTF-8
lookup fails, then there is a fallback to DNS/ACE (at least in some
situations).  At first, I assumed that the fallback would happen inside
the resolver, but then you said it wouldn't, so that means the fallback
must happen inside the application, right?  In other words, you expect
these applications to include code that looks like this:

    start with a UTF-8 query
    look up using newAPI
    if that failed then begin
      ACE-encode the query
      look up using oldAPI
      ACE-decode the response
    end
    finish with a UTF-8 response

But they could instead use code that looks like this:

    start with a UTF-8 query
    ACE-encode the query
    look up using oldAPI
    ACE-decode the response
    finish with a UTF-8 response

The latter starts and ends with UTF-8 just like the former, but
is smaller and simpler.  You were recommending a fallback to be
used sometimes by some applications, and my point is that for those
applications it's easier to just use the "fallback" all the time.

If you want to help these applications to forget about ACE, you can do
that by hiding the fallback mechanism inside the resolver.  Then the
application can simply do:

    start with a UTF-8 query
    look up using newAPI
    finish with a UTF-8 response

AMC