Multilingual domain names could strain corporate nets

SAN DIEGO - Under pressure from non-English speaking users, the Internet engineering community is considering several proposals for supporting foreign language domain names that would all require significant network upgrades for multinational organizations.

The Internet Engineering Task Force (IETF) is weighing several proposals for supporting domain names written in foreign language characters. Some proposals require fundamental changes to the Domain Name System (DNS) infrastructure. An alternative, which is favored by many IETF participants, requires changing the applications that use DNS but not the DNS infrastructure.

All proposals require network managers to upgrade desktop applications that use domain names, including Web browsers, e-mail clients and operating systems.

"It is 150% clear that all the applications on the Internet need to be replaced to support internationalized domain names," says Patrik Faltstrom, co-chair of the IETF's applications area and co-author of the leading proposal. "We use domain names in so many places...Users are going to need to change all their client software to support [internationalized domain names]."

Indeed, IETF leaders warn that migrating to an internationalized domain name scheme will be more difficult than the much-debated and long-delayed move to IPv6, an upgrade to the Internet's primary communications protocol.

"If the IPv6 transition happens smoothly, users won't know," says John Klensin, chair of the IETF's Internet Architecture Board. Internationalized domain names, on the other hand, "will affect every single user on the Internet."

The IETF is considering several proposals that would convert foreign language characters into Unicode, a computer industry standard, and then encode them in ASCII for transmission over the Internet. But the proposals differ from there.

The most radical proposal would create a new class of the DNS to support internationalized domain names that also would repair many of the existing problems with the aging DNS infrastructure. Suggested by Klensin, this proposal raises political questions because it places responsibility for internationalized domain names outside the scope of the Internet Corporation for Assigned Names and Numbers.

Another proposal from Klensin would create a massive directory with internationalized resources between the DNS and DNS-based applications. The directory approach would add new features to the Internet, but it is considered risky because no directories of this scale have ever been built or operated.

A third proposal would involve upgrading all DNS servers on the Internet to support a new name type that would be internationalized. This approach would allow error messages to get back to users if their queries were sent to a server that wasn't upgraded. Users also could get different results for the same query depending on their locations.

The most popular proposal adds a presentation layer to the current DNS to display domain names to end users in their local languages. The IETF's working group on internationalized domain names prefers this proposal because it is simpler than the others and can be completed faster. However, some IETF leaders warn that this proposal solves only 80% of the problem and may cause more complications than proponents envision.

Now the IETF must decide whether to choose a long-term, architecturally clean fix that would require an upgrade to the Internet's entire naming infrastructure, or take a short-term view that requires changing only the application protocols. Another option is to change the applications now while continuing to work on a long-term strategy.

"Of the three more long-term solutions, I like the directory proposal best," says Paul Hoffman, co-author of several proposals including the popular presentation layer approach. "Having a universal directory for the Internet would be a phenomenal help to e-commerce. We just don't know how complicated it will be."

If the IETF chooses the presentation layer approach, a stable protocol could be developed in six months to a year, with product implementations available in 2002.

The long-term proposals could take two to five years before they are finalized, IETF participants estimate.