[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] UTF-8 / RACE
> > Some people seem to be arguing that using ACE requires no less (or
> > even more) upgrading of software than using UTF-8 without ACE.
>
> Some of us are arguing the cost of UTF8-with-ACE is only slightly greater
> than the cost of ACE-only.
this is probably true. but the biggest part of the 'cost' in adding
UTF8 support to an ACE solution is probably not the implementation
effort but the additional delay required to figure out how to make
the two work reliably and consistently together given the limitations
of presently-deployed DNS servers.
if getting the UTF8 part right would delay the adoption of a standard
ACE enough that there were significant deployment of nonstandard
IDN solutions, this might make it far more difficult to ever get a
standard solution (be it ACE, UTf-8 or whatever) in place.
this is why I favor moving forward with an ACE solution now.
> Some of us are also arguing that the cost of ACE-now-UTF8-later is 2x the
> cost of UTF8-with-ACE.
I think this presumes that UTF8-with-ACE can be deployed in the same
timeframe as ACE-now-UTF8-later, and I don't think that's the case.
My guess is six months to a year additional standards work just to figure
out how to make the the ACE and UTF-8 queries work consistently with
one another.
> > ACE affords incremental deployment much better than no-ACE.
>
> ACE is analogous to dipping your toe into the kiddie pool. Even if you
> find out that the water is comfortable, you won't be able to thoroughly
> enjoy it.
someone recently told me to be careful when using analogies, because it
tempts people to argue about whether then analogies are valid rather than
about the matter at hand.
I don't think it's fair to characterize ACE as a halfway solution.
Most applications that get upgraded to use ACE will get every bit as much
of a facelift as they would if they were upgraded to use UTF-8. The only
difference is that they will encode IDNs using ACE "on the wire" when
exchanging IDNs with applications that might not have been upgraded.
The real issue is not the difficulty in upgrading individual applications,
but the difficulty in upgrading all implementations of a given application.
And the latter is far easier if you can upgrade each component incrementally
without disrupting service.
> The international user community doesn't end at email and web. Think about
> the end-user networks out there with admins who are struggling with
> ASCII-based DHCP, lpd, and just about everything else that ACE doesn't
> help with.
I think that's a mischaracterization. The format that is used for
on-the-wire DNS queries is almost completely irrelevant to applications -
since the vast majority of applications will be using standard APIs
which convert between native character set and encoding and those
used on the wire. For this purpose, the application doesn't care
whether the format is UTF-8 or ACE. But the applications that currently
use DNS names are expecting ASCII names, ACE does help ease
the transition with these, and these applications do include DHCP and lpd
and anything else that uses DNS names.
> Worse, it makes embracing IDNS more difficult for them, since
> they have to go from using ASCII to a highly cryptic naming service that
> is outright user-hostile. It is highly unlikely that those services will
> ever be fixed until a UTF8 form is developed by us, embraced by the WG,
> and coded by the vendor community.
think of it another way - there's no way that the IDN WG can "fix" these
services, because each service has its own transition issues. each
protocol must be "fixed" by people who understand that protocol. the
IDN WG cannot simply say "all protocols will use UTF-8 IDNs". a statement
like that would be tantamount to saying that we cannot move to UTF-8
IDNs until we understand how to fix every major application - and that
would take decades.
> ACE is transitional, not a destination. The cost and time of getting to
> the real destination can be shortened by embracing it early.
The Internet itself is transitional. It continues to evolve, and in the
past we have not demonstrated a good ability to predict how it will evolve.
However we do have some experience that indicates that solutions which
require massive infrastructure upgrades are far less likely to succeed
than solutions which were designed to allow incremental upgrading.
Keith