Re: [idn] iDNS transition: end-system vs. infrastructure?

[Keith Moore <moore@cs.utk.edu>]

> > we cannot use pure UTF-8 because non-IDN-aware applications
> > will still  need to be able to lookup ACE-encoded IDNs.
> 
> Keith,
> 
> While I agree -- for the reasons mentioned by Adam and that I'm
> sure will be repeated and expanded upon by others-- that "just
> send UTF-8" is a bad idea, I'm not sure the above follows.
> 
> We have approaches --the "use a different DNS Class" idea is
> certainly one example-- which would prevent a non-IDN-aware
> application from ever encountering an IDN in a context in which
> being able to resolve it is a reasonable expectation.  

people have suggested such approaches.  I personally do not believe
that they are viable.  in particular, we cannot implement such an
approach without adding explicit negotiation for IDN-compatibility
to every protocol which currently carries a DNS name - including
protocols such as internet mail (rfc2822/mime) and html which are
exchanged via many different bearer protocols.  it's simply not
feasible to add IDN-capability negotiation to each of these.  Nor,
absent conversion to some sort of ascii equivalent,  do there appear 
to be any acceptable modes of operation for the case when the 
negotiation reveals that the destination is not IDN-capable. 

> And
> having an application that is completely non-IDN-aware handle
> ACE-type IDNs correctly (with IDNA or otherwise), is likely, but
> not certain, to bypass unanticipated problems.

I think we've established there there will be some problems no
matter which approach is chosen.  We can still hope to minimize
them.

So in summary, I agree with your categorization of the design 
choices that this group has to make, but for me, both:
(i) just send native IDNs to non-aware applications , and
(iii) preventing non-aware applications from seeing native IDNs
are non-starters, at least for a general approach to retrofitting
existing applications.   (some new applications could perhaps
reasonably employ a type iii solution if they never exchanged
IDNs with other applications)

I disagree with the categorization of type iii as "no risk",
because to me it appears that there is considerable risk 
associated with adding IDN capability negotiation to the 
large number of existing applications that use DNS names.
This risk might not be so much that existing applications
are exposed to IDNs, but instead that updating a large
number of applications to explicitly support IDN negotiation
will introduce new failure modes that are not easily understood 
by users, and require changes to software that will sometimes 
require major restructuring and thereby introduce bugs that
will cause operational errors.

Keith