The Search for Standards

The DNS is a critical component not just of the Web, but also of other Internet protocols, such as SMTP, telnet, and FTP. Paul Hoffman, director of the Internet Mail Consortium and technical advisor to the Internet Engineering Task Force (IETF) IDN Working Group, says, "The IETF needs an IDN solution that works for all protocols, not just Web browsers."

When it comes to developing such a solution, there are two schools of thought on how to proceed. One school wants to find a solution that leaves the DNS as is; the other suggests we take this opportunity to build a brand new DNS altogether.

But given that the DNS currently resolves about a billion domain names a day, changing the DNS is a little like changing a tire on your car while driving. Nobody can say for sure just how the DNS will react when it's asked to resolve IDNs on a massive scale; that's why the IETF is involved. The IETF has been studying IDNs for more than a year, and is trying to recommend a protocol that enables IDNs without threatening the health of the existing DNS.

John Klensin was one of the people involved in deciding which characters would be in the original DNS. Ever wonder why the underscore character isn't allowed in domain names? "We didn't want it to be confused with the hyphen," says Klensin, who is currently technical advisor to the IETF IDN Working Group and chair of the Internet Architecture Board.

The problem with the DNS, says Klensin, isn't so much the DNS itself, but our expectations of what it should accomplish. The DNS was never intended to be anything more than a machine identifier. Instead of trying to upgrade the DNS so that it successfully navigates all of these cultural, linguistic, political, and legal issues, which he views as "hopeless," he proposes creating a new layer for the DNS.

Possible Solutions

This added layer would function as a user-friendly directory, much like the RealNames servers, and would insulate the end user from the messy details of the DNS. "We've made a horrible mistake of exposing URLs and domain names to the man on the street," says Klensin. The DNS doesn't allow for ambiguity, only yes or no. With a directory layer, users would have a more user-friendly alternative. For example, if a user were to enter an incorrect domain name, this layer might present the user with a list of options, instead of an error page.

Although Klensin's solution certainly makes sense, it isn't certain how much work or time would be required to make it a reality. And it's doubtful that vendors and users will wait patiently until it's finished. As a result, the IETF is leaning toward a faster workaround solution, one that leaves the DNS as is. That solution is called Internationalized Domain Names for Applications (IDNA).

Because the DNS requires that a domain name use only ASCII characters, IDNA proposes that client applications, such as a Web browser, manage the character conversion internally. Says Hoffman, "IDNA makes the most sense of any of the proposed approaches. It requires no changes to DNS servers. More importantly, it puts no additional load on the DNS, particularly on the root servers."

In this sense, IDNA is not unlike the cur rent ACE conversion used in VeriSign and i-DNS.net's IDN system. But if IDNA were implemented as an Internet standard, software vendors would have to build this functionality into all Internet applications—not just Web browsers, but email, telnet, and FTP clients as well. The process would take some time, but because the underlying DNS should remain untouched, there should be no rude interruptions as these applications are revamped for IDNA compatibility.

Approach With Caution

Should your business wait for the IETF and ICANN to set standards for IDNs (potentially a long wait), or should you take your chances with one of the systems already in place? Many companies are choosing the latter. After all, the global markets are a vital source of revenue. Anything that makes your Web site more easily accessible to users could pay for itself very quickly.

But before you rush out to register your company's multilingual domain name, make sure you read the fine print. Buried in the FAQ pages of international domain registrar Register.com's site is the following warning: "International character domain names are not yet and may not be functional on the Internet and cannot be used for Web hosting."

In other words, register at your own risk. While vendors like Register.com and VeriSign are more than happy to take your money in exchange for an IDN, they can't guarantee that the name will still be valid once the IETF (or some other body) arrives at a standard. Verisign is quick to point out, however, that it will do its best to make sure that today's registrants don't lose their registered names when a new standard takes hold.

Ultimately, this issue is complex, and many different parties stand to gain or lose a lot based on the outcome. Much of the standardization of IDNs was supposed to have been completed by now, yet the industry and standards bodies alike remain undecided. But although the internationalization of domain names is complicated, messy, and uncertain, it also appears inevitable. Before the Internet can be truly accessible on a global scale, IDNs must provide the missing link.


John Yunker is author of Web Globalization Strategies: Beyond Borders, forthcoming in 2002 from New Riders Publishing. He can be reached at jyunker@bytelevel.com.