|
|
||||||||||||||||||||
|
|
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Internationalized Domain Name (IDNs) FAQs
|
|||||||||||||||
|
|||||||||||||||
|
C. Web-Based Navigation System
|
|||||||||||||||
D. WHOIS
|
|||||||||||||||
|
What are internationalized domain names? Internationalized domain names are domain names represented by native language characters. The native language domain name will be followed by .com or .net for example:
What is an internationalized domain name registration? Registrants will be able to register second-level domain names in .com and .net, in available characters through ICANN-accredited and VeriSign GRS certified registrars.
How do I use an IDN? To use an IDN to navigate to a Web site, the user types the IDN in the browser's address bar or clicks an active link. If the user does not have the i-Nav plug-in, most browsers will require that the user type "www." or "http://" before the IDN. These prefixes will enable the browser to recognize the IDN as a DNS query. The IDN is resolved and the desired Web site appears in the browser. See our User Experience demonstration for more information.
Why is VeriSign Global Registry Services opening a testbed for non-English domain names? VeriSign Global Registry Services seeks to improve the international accessibility and functionality of the Internet by allowing users to register domain names in non-English languages. To that end, VeriSign Global Registry Services has opened the internationalized domain name testbed to catalyze the work of the Internet Engineering Task Force (IETF) in developing standards for internationalized DNS. The testbed will also enable us to confirm that the new internationalized domain name technology will work in both the Shared Registration System (SRS) and the generic Top Level Domain (gTLD) name server system.
When will the testbed be operational, and for how long? The testbed is currently operational. The end of the testbed has not yet been established, but it is anticipated that it will generally correspond with the final approval of Internet Engineering Task Force (IETF) standards for internationalized domain names.
What languages are supported? Since availability of languages is dependent upon Unicode, it would be best to answer this question in Unicode terms from the Unicode site. Many scripts (especially Latin) are used for a very large number of languages. The easiest answer is that Unicode covers all the languages that can be written in the following scripts: Latin; Greek; Cyrillic; Armenian; Hebrew; Arabic; Syriac; Thaana; Devanagari; Bengali; Gurmukhi; Oriya; Tamil; Telegu; Kannada; Malayalam; Sinhala; Thai; Lao; Tibetan; Myanmar; Georgian; Hangul; Ethiopic; Cherokee; Canadian-Aboriginal Syllabics; Ogham; Runic; Khmer; Mongolian; Han (Japanese, Chinese, Korean ideographs); Hiragana; Katakana; Bopomofo and Yi.
How will non-English domain names appear on my Web browser? All non-English domain names registered during the testbed period will become second level domain names
within .com and .net. For example, a Chinese domain name may appear as
Why is VeriSign Global Registry Services launching a testbed phase that allows registrations before internationalized domain name resolution is operational? The phased testbed enables the VeriSign Global Registry Services and registrars to work together to contribute to the standards development process of the Internet Engineering Task Force (IETF), and thereby more rapidly and effectively deploy an internationalized domain name capability.
During the testbed, will the domain names registered in non-English languages be added to the current root system? Initially all registered internationalized domain names will be placed on REGISTRY-HOLD and therefore will not be in the zone files. The registered domain names will be added to the current root system at some point during the resolution phase of the testbed. Domain names will be added in their ASCII text converted form.
What will happen to the names that are registered via the testbed after the conclusion of the testbed period? Domain names registered during the testbed will be treated just like any other ASCII domain name. However, revisions to the Internet draft documents may require encoding changes from the internal representation of the early testbed names to the internal representation of the final approved protocol. If conflicts or collisions occur upon encoding conversion, which may result in the loss of a registration, those problematic names will be handled on a case-by-case basis. Current assessment of the IETF Internet draft documents does not indicate that this will be a problem.
Will the internationalized domain name testbed support name server names? Yes, name server names may include native character set names preceding the .com or .net in the internationalized domain names testbed.
Can several domain names share the same IP address? Yes. There is no variation from the current capability for domain names to share IP addresses.
How will the VeriSign Global Registry Services handle trademark issues with regard to international domain names? As a registry, VeriSign Global Registry Services is not involved in the intellectual property disputes surrounding domain name registration. The VeriSign Global Registry Services will advise registrars that, during the testbed, registrars should consider deleting any internationalized second level domain name registration upon receipt of a formal (written) objection from any legitimate source received by that registrar for a limited period of time to be specified by the particular registrar. In addition, the VeriSign Global Registry Services is aware that accredited registrars may continue to use the Uniform Domain Name Dispute Resolution Policy (UDRP) to resolve disputes, including those involving internationalized domain names. |
|||||||||||||||
|
How will internationalized domain names be processed? The registrar will use Row-based ASCII-Compatible Encoding (RACE) and valid name prep checks to convert native language characters into ASCII-compliant codes. These ASCII strings will then be sent to the VeriSign Global Registry Services database via an internationalized domain name testbed protocol.
What is the encoding used for this process? Based on the currently proposed IDN Working Group Internet draft, the encoding will be Row-based ASCII-Compatible Encoding (RACE). Transition will be made in the near future to punycode (AMZ-ACE-Z) based upon the work of the Internet Engineering Task Force (IETF).
May hyphens be used in internationalized domain names? Yes. Hyphens may be used in internationalized domain names. However, just as current standards do not allow names to begin or end with a hyphen, the ASCII transformation cannot begin or end with a hyphen.
What is the maximum number of characters allowed for an internationalized domain name? The encoded form of the internationalized domain name (including the 4 characters for .com or .net) may contain up to 67 characters. The characters can be letters, numbers, and/or hyphens. Hyphens may not begin or end a domain name. The internationalized domain name transformation software will reject the name if the encoded conversion exceeds the limit.
How will internationalized domain names appear in the Zone file, as the actual name in the native character set, or as the ASCII transformation? When in the Zone file, internationalized domain names will appear as the encoded ASCII character string. For example, the RACE encoding of domain.com will be stored as bq--gde6djht.com.
What is the format of the domain name when it is entered into the VeriSign Global Registry Services database? Internationalized domain names are stored in the VeriSign Global Registry Services database as ASCII-compliant RACE codes with .com or .net suffixes.
Will there be separate RRP codes to indicate registration failures/errors for internationalized domain names and name servers? The registration failure/error codes for internationalized domain names and name servers are the same as those in the current RRP. Additional codes have been added to support errors specific to internationalized domain name conversion and encoding.
When will VeriSign support punycode in the IDN Testbed? VeriSign is committed to supporting punycode within 60 days after the punycode RFC is published by the IETF. VeriSign hopes to migrate to punycode as the supported ACE in the IDN Testbed during the first half of 2003, pending publication of the punycode RFC. Migrating all registrars to punycode might take longer than 60 days, however. VeriSign will initiate a comprehensive migration program to assist registrars in making the change to punycode.
|
|||||||||||||||
|
C. How does the VeriSign Web-based Navigation system work? For a high level explanation, view the Resolution Demo. For a more detailed explanation, please refer to the following diagram when reading the sequence of steps described below:
Why is VeriSign offering the Web-based Navigation system? VeriSign GRS is offering this system in response to market feedback from users, registrants, IDN registrars and other key stakeholders to improve the user experience for IDNs. The system will improve the user experience by promoting the distribution of the i-Nav plug-in. The i-Nav plug-in offers IDN support in browsers and other applications following the IDN in Applications (IDNA) model, one of the anticipated IETF standards for IDNs. VeriSign's position has always been to follow the eventual IETF standards for IDNs and believes that this system follows the model which will be chosen by the IETF IDN Working Group. The system is an interim solution that allows some IDN functionality for Web navigation and ultimately supports widespread adoption of software supporting the anticipated IETF standards.
When will the Web-based Navigation System be launched? The Web Navigation system will be deployed for general availability by the end of December 2002.
Is the IDN Testbed registration process changing to support the Web-based Navigation system? No. Even though we are generating variants in multiple encodings for all IDNs in the Testbed, the uniqueness of an IDN has always been and continues to be determined by its sequence of Unicode code points after name preparation.
Could the IDN sent by the browser match multiple variants? Yes. Variant "collisions" are possible. For example, the non-ASCII string corresponding to the UTF-8 representation of one IDN might also correspond to the Big5 representation of another IDN. If a Web browser sends this non-ASCII string in an HTTP Host header to a Web Navigation Server, the result is a match on multiple registered IDNs. In that case, the user is presented with a list of all matching IDNs and must select one to proceed.
Does The Web-based Navigation system support DNS resolution of IDNs? No. This service supports Web navigation only, not generic DNS resolution of IDNs. The com/net name servers respond to queries for illegal host names - domain names that could never be registered in com or net - with the address of the Web Navigation Servers. No attempt is made at the DNS protocol level to interpret the query and determine the intended IDN. All interpretation is done in a Web context, which allows the ambiguity issue described above (when the IDN representation sent by a browser matches multiple registered IDNs in the Testbed) to be handled gracefully, without guessing the user's intent.
Could you give more details about the change in behavior of the com/net name servers to support this service? The com/net name servers have added logic to detect queries with specific violations of host name syntax. In particular, for queries of type A, class IN, only the second-level label (i.e., the label to the immediate left of com or net) is examined. If this label contains any single ASCII character that is not an upper or lowercase letter, digit or hyphen, then the host name is considered illegal and the A record of the Web Navigation Servers is returned.
What about IDN-like queries from applications other than Web browsers? There is no way to determine, at the DNS protocol level, which kind of application sent a particular query. Since the service supports only Web navigation, network traffic from other applications is rejected: connection attempts to the Web Navigation Servers to TCP ports other than 80 (HTTP) and 25 (SMTP) are reset and any UDP packets sent result in an ICMP port unreachable response. This network-level behavior should cause most applications to display a reasonable error message to the user, but individual application behavior varies.
Will the Web Navigation system handle ftp or https queries? No. The system only handles http and some instances of SMTP as stated above.
Does the Web Navigation system support using IDNs in e-mail? The Web Navigation system specifically does not support using IDNs in e-mail, but we want to proIf the user declines to download the i-Nav plug-in, the Web Navigation Server redirects her browser to the desired Web site using the ACE (ASCII-compatible encoding) version of the IDN she originally entered.vide a reasonable user experience in response to e-mail sent to an IDN destination. The com/net name servers will continue to return NXDOMAIN (RCODE=3) responses to MX queries for illegally formed host names. Some mail transport agents (MTAs), however, also query for the A record of an e-mail destination and such queries will return an A record for the Web Navigation Servers. To accommodate such MTAs, the Web Navigation Servers run an SMTP server on the standard TCP port 25. This SMTP server bounces any messages it receives back to the sender with a brief explanatory message. Without this immediate bounce behavior, such e-mail could potentially be queued for several days on the originating MTA before being returned to the user.
How does this service, or even the i-Nav™ plug-in, work at all when there are no IDNs in the com and net zones? In advance of an IETF standard, VeriSign has chosen not to put the RACE representation of Testbed IDNs into the com and net zones. Instead, these IDNs are currently delegated from the mltbd.com and mltbd.net zones. Even though registrants register IDNs in the form <RACE>.com, these IDNs are delegated in the form <RACE>.mltbd.com. Registrants must configure their name servers to be authoritative for their IDN zone in the form <RACE>.mltbd.com, not <RACE>.com, and many registrants have done so. The i-Nav plug-in and the Web Navigation system translate IDNs in the form <IDN>.com to the form <RACE>.mltbd.com for DNS resolution.
How long will the Web Navigation system be active? VeriSign will support this system until software vendors begin releasing applications (such as Web browsers and e-mail clients) conforming to future IETF standards for IDNs.
|
|||||||||||||||
|
How will the internationalized domain name appear in WHOIS? In WHOIS, the internationalized domain name will appear as it is stored in the VeriSign Global Registry Services' database, which is RACE. Here is an example based on the currently proposed IDN Working Group Internet draft: bq--gde6djht.com As the protocol evolves, the beginning of the string (bq--) could change.
In addition to the domain name, will the remainder of the domain/name server record be recorded (in ASCII) in the WHOIS and Registry database? Yes. The domain name, registrar name, WHOIS server, referral URL, name server record, and updated date will be recorded using ASCII characters (the current standard).
Will the VeriSign Global Registry Services WHOIS accept queries using the native character set of the internationalized domain name? The RACE representation (and not the native character set) must be sent to the Registry WHOIS. At the beginning of the testbed, an internationalized domain name conversion tool will be available as a bridge until an internationalized domain name WHOIS capability is available to accept queries using native language character sets. The conversion tool will allow the entry of native characters and will return the accurate RACE string which can then be linked to WHOIS to return WHOIS information.
How can someone find out if a domain name has been registered in multiple languages? Domain names are unique registrations for each language. Therefore, a user must request registration information by initiating a WHOIS query for the domain name, in each language (native character set). |
|||||||||||||||
|
|
|||||||||||||||
|
Portions © VeriSign, Inc. Reprinted with permission. |
|||||||||||||||
|
|||||||||||||||
|
*All brands, products, trademarks, and service names mentioned are property of their respective owners.Please read our disclaimer. Copyright ©1998-2003 Domain Registration Services. All Rights Reserved. 3.0. Referred by [member]. |
|||||||||||||||
.com).
