Unfortunately, if you don't speak English, the DNS isn't nearly as user friendly. Consider the dilemma of the French car manufacturer, Citro‘n. If a Web user tries to visit Citro‘n's Web site by entering www.citro‘n.com, that user will be disappointed. The DNS doesn't recognize European characters like ‘, �, or —. As a result, users must type www.citroen.com. While this may seem like a trivial detail to many English speakers, it's anything but trivial to French speakers.
The current DNS allows for only a subset of the ASCII character set, specifically the letters A through Z (both upper and lower case), the digits 0 through 9, and the hyphen. Citro‘n is relatively fortunate, because most of the characters in its name are included in ASCII. Consider how frustrating it must be for companies with names in languages that use no ASCII characters at all, like Thai and Arabic. And consider the host of trademark issues that arise for companies that can't register their company names as domain names.
According to the Aberdeen Group, only 48 percent of Internet users are English speakers. By 2003, the number of native English speakers is expected to drop to 32 percent. Because of this trend, a growing number of companies have begun to view the creation of a system of internationalized domain names (IDNs) as a goal of increasing importance.
Enter the Entrepreneurs
In 1999, a start-up company named i-DNS.net began registering the first IDNs. Although the DNS only supports ASCII domain names, i-DNS.net developed software that converts IDNs into ASCII-compatible encodings (ACEs). Within six months the company announced that it had registered more than 50,000 names, and was expanding its services from Asian countries to include more than 30 languages worldwide.
Users who register IDNs are actually only registering the ACE conversions of the IDNs, such as bq--3bs6kzzmqivhu6q.jp for Japan Air Lines. Try typing a couple of ACEs into your browser, and see what you get. With the i-DNS.net system, each IDN is translated into its corresponding ACE using a browser plug-in (called iClient), which then passes on the ACE to be resolved by traditional domain name servers.
This solution isn't elegant, but it's catching on. In November 2000, Verisign also began registering IDNs using an ACE conversion scheme, and now claims to have registered a million IDNs. All the same, resolving IDNs through ACE translation is far from perfect.
For one thing, once a user inputs an IDN, let's suppose it's the IDN for Japanese game-maker Sega, the Sega Web page appears. However, the browser address window displays the ACE, not the IDN—this is known as name leak. In addition, so far, users can't take advantage of IDNs until they download the iClient plug-in.
The RealNames Alternative
"Plug-ins are not a broad-based solution," says Chris Dobbrow, senior vice president of global application sales for RealNames. Instead, Dobbrow's company offers a proprietary Web addressing system known as Keywords. Keywords are marketed as a more user-friendly form of domain names, because they don't require technical details like http:// or .com.
With the Keywords system, users can simply enter a company's name, Yahoo for example, and be taken directly to that organization's Web site. Keywords work as a sort of intermediary to the DNS system. RealNames has built its own network of servers that resolve the Keywords to their IP addresses. And because RealNames designed its software to support Unicode characters, it can register multilingual Keywords, unlike traditional DNS.
Like IDNs, Keywords aren't without their drawbacks, however. A company first has to register a Keyword with the RealNames service before users can take advantage of it. And Web surfers must be using the Internet Explorer browser. RealNames doesn't work with Netscape.
To address the second issue, Dobbrow points out that Explorer is already the dominant Web browser, both inside and outside of the U.S. Yet, RealNames won't go so far as to declare our international domain name problems solved. All of the vendors in the international domain name business freely admit that these systems are little more than test beds for an eventual, permanent solution.
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 current 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.
對不起﹐此頁暫時無中文版。
不便之處﹐盡請原諒。
