Re: [idn] IDN rechartering rev 3

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

Dave Crocker wrote:

> >Also note that this decoding will require changes to some parts of
> >the infrastructure in order for it to be a successful encoding,
> >probably at the authoritative servers for a zone and possibly at the
> >resolver depending on depth of adoption.
> 
> The only changes need to be up the stack, towards user interactions.

> That means the DNS client and the DNS Administration interfaces that
> creates DNS entries.  No other part of the system needs to change.

This is patently false.

Under the current spec, hostile redirects are trivially easy. To use your
favorite phrase, the proposal is "incomplete" without guidance and at
least a recommendation on these and other critical issues. At best, it
will require application involvement, which is substantially more effort
than simple display decoding. The depth to which application interfaces go
in this and other efforts will also affect whether or not resolvers need
to be changed.

It was illustrated last week that answer data cannot be properly encoded
in all cases. There are only a couple of ways to solve this problem, one
of which is ensuring that all of the authoritative servers for a zone
follow the same default recommendation. New servers.

Quite simply, if IDNA only served the principle goal for which it was
designed -- backwards compatibility with hostnames as transferred in
application data -- then it would work without any other changes. Because
it goes beyond this scope into display decodes and zone data, it is by
definition no longer serving the single goal for which it was designed,
and it inherits the problems associated with those turfs.

Your failing to notice these problems doesn't mean they do not exist.

You have made it clear that you despise basic science, but it should be
equally clear that it is far too early to be annointing anything the
winner in this process. Doing so can serve no purpose which is beneficial
to this WG or the Internet community.

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