[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] Some thoughts...



> So, to a first-order approximation, my guess is that "change app
> to decode ACE and present multilingual characters", "change app
> to call something besides 'gethostbyname' where the new interface
> does multilingual and maybe directory things", "change app to
> decode UTF-8 and present glyphs corresponding to IS 10646",
> "change app to call directory interface before calling
> 'gethostbyname'", or mixtures of them, all have the same
> time-to-deploy periods.  It is too bad, really, but I don't find
> any of the "this can be deployed a lot faster than that"
> arguments very persuasive.

I suspect you're right about this.  What I find persuasive about 
ACE-based solutions is not that they're easier to retrofit into
existing application codes than other solutions, but that they're 
friendlier to unmodified applications.

In other words, if we use an ACE-based solution, we can deploy
IDN-compatible clients, servers, etc. one at a time without 
massive breakage - the non-upgraded components will just present
the ASCII version rather than the encoded version.  This is ugly
but far preferable to the alternative. 

With ACE solutions existing applications continue to "work" in some 
fashion. To the extent that users perceive the display of ACE 
encodings rather than the appropriate glyphs as "failure" the 
nature of the problem is fairly obvious.  With other kinds of 
encodings applications will break in random ways, and the failure
of one component to properly handle an IDN may cause an observed
failure in a different component - masking the source of the problem. 

Furthermore, with ACE based solutions the incentive for deployment 
of upgraded applications is in the right place - those who find 
display of the ACE forms of IDNs annoying can upgrade their 
software and immediately fix the problem.  This is precisely
because ACE lets all existing applications protocols and formats
which transport domain names work without change - the only
changes needed are at the endpoints.  Encodings which are not
syntactically compatible with existing ASCII DNS names will 
require each application protocol or format that carries DNS names
to be specially adapted for IDNs.

So I conclude that whatever representation for IDNs is used in name
lookup queries and responses (and this representation probably doesn't
matter much), we will still need an ACE for use in applications
and formats that transport DNS names.  Otherwise integrating IDNs into
our hosts and applications will take many times longer than integrating IPv6. 

Keith