Re: [idn] UTF-8 / RACE

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

Patrik Fältström wrote:

> Difference is that in UTF-8 you need to replace all intermediate
> servers, while with ACE, the enduser can upgrade his applications,
> and only that, to be able to see IDN's. I.e. an enduser can start
> using IDN's even though his systems manager have not upgraded the
> system software on the servers (for DNS, HTTP and SMTP etc) he use.

Let's keep this in perspective. With either ACE or UTF8, the end-user
applications have to be upgraded before the targeted functionality (local
representation of IDNs) is fully working. We are already talking about a
forklift upgrade of the entire Internet before email addresses, URLs and
other IDN occurances work right. In that context, upgrading the remaining
boxes is not exactly a show-stopper.

Also, if upgrading the servers means that the admin gets native language
support across their entire network instead of only getting it at the
end-user presentation time, I feel certain they would choose that
solution. Given the choice between encoded IDNs which were even more
user-hostile than ASCII domain names, or direct native language support
for slightly more cost, which would you choose?

Moreover, with ACE-only, they do not get this choice. They *cannot* get
native language support across all of their applications. In fact, asking
end-users to upgrade once for ACE and upgrade again later for UTF8 is
essentially asking for two forklift upgrades, which is the most expensive
solution of all.

So options and cost-of-deployments are:

   do nothing:     low-cost     low-functionality
   ACE only:       high-cost    low-functionality
   UTF8/ACE:       higher-cost  high-functionality
   ACE then UTF8:  2X-cost      high-functionality

Furthermore, given the overlap in functionality and deployment costs, I
think that it would be easiest on the development community to do UTF-8
and ACE at the same time, since they have the same basic core requirements
WRT nameprep and such. It would be much more expensive to do one upgrade
for ACE and then come back and repeat the development project for UTF-8,
since it would be two complete development cycles.

So cost-of-deployment for the user is not significantly greater to do
UTF8/ACE, but cost-of-development for the industry *IS* higher to do ACE
and UTF8 on separate development tracks.

One other point: Going to UTF8/ACE means that we can upgrade applications
as/when the WGs want to do it. ACE-only means the WGs cannot use rich IDNs
even if they wanted to.

I will also point out that there is one potential downside to doing ACE
and UTF8 together, and that is the issue of managing duplicate encodings
within the namespace (the ACE and raw domain names both have to be
provided at different times, so they both have to be maintained). That may
be resolvable through protocol, however, although I did want to bring it
up as a potential issue.

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