Re: [idn] proposals and deadlines

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

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

> Even though we could do this [put ACE conversions in the resolver]
> for the DNS parts, the applications will still have to perform
> conversions.

Are you resigned to have applications contain ACE conversion code
forever?  If so, why should it bother you if DNS likewise uses ACE
forever?  On the other hand, if you'd like to see applications evolve
away from ACE (by upgrading old protocol formats, or replacing old
protocols by new protocols), then you need to give them a way to avoid
ACE in DNS lookups too, and that means giving them a UTF-8 resolver
interface that makes a best effort, not one that gives up too easily and
expects the application to do the fallback to ACE.

> This would be somewhat easier on the server infrastructure, but it
> wouldn't save the applications any labor...

Yes it would.  There will definitely be some applications that want a
UTF-8 response to a UTF-8 query.  If newAPI tries EDNS/UTF-8 and gives
up on failure, then these applications can do their lookup in either of
two ways:

    look up using newAPI
    if that failed then begin
      ACE-encode query
      look up using oldAPI
      ACE-decode response
    end

or:

    ACE-encode query
    look up using oldAPI
    ACE-decode response

The latter is less code to write and maintain.  I can't see a reason
why any programmer would opt for the more complex method given those
two choices.  I also can't think of any scenario where an EDNS/UTF-8
lookup failure should not be followed by an attempt with DNS/ACE.  Which
means I can't think of a single scenario where a programmer would want
to use newAPI at all.  That's my point.  I don't see an incentive for a
programmer to call newAPI if newAPI only makes a half-hearted attempt.
If it makes a best-effort attempt, then it becomes attractive.

> this approach does not provide a migration path to a UTF8-aware DNS
> infrastructure.  We would still have to store the raw zone data in ACE
> format, we would have to invent ACE editors, we would have to educate
> the administrative masses on ACE encoding syntax, and there would be
> less impetus to move to UTF8 end-to-end in higher-layer protocols.

Zone files can be stored in the local charset, or UTF-8, and the DNS
server can do ACE encoding when it starts up and reads the file.  No
need for ACE editors, or for administrators to even see ACE.

If the UTF-8 resolver interface is best-effort, then there is greater
impetus to move to UTF-8 in higher layers, not less, because then
applications can be completely free of ACE.  If the resolver interface
is half-hearted, then applications will always have to do their own
fallback, and will therefore never be free of ACE, so why should they
bother migrating the upper layers away from ACE?

> There is also a technical consideration here, in that this approach
> does not provide a way to distinguish between spurious 8bit data and
> IDNs.  An older application that encounters an 8bit domain name may
> pass it into the stream when it shouldn't (there is at least one
> application out there now that passes UTF8 into the DNS).  With the
> dual-message model, at least we can tell that this is an old client
> and the malformed data can be compared to LDH and rejected, while
> EDNS messages should only be coming from modernized applications that
> (hopefully) follow the normalization rules.

I don't see how this conflicts with anything I've proposed.  I have not
proposed putting 8-bit data into old-style DNS messages.

AMC