add site
services
publishers
database
health videos
toolbar
stats
live show
health store
more stuff
JOIN/LOGIN
| advertise add site services publishers database health videos
| | about toolbar stats live show health store more stuff JOIN/LOGIN |
Cytoplasmic domain p75 antibody, cytoplasmic domain p75NTR antibody osenses.com | myhosting.com Parked Domain | Domain Hosting & Email Hosting Services brisbanedentist.com | - Domain Names - Pain related domain names for sale painclinic.org | Health Domains – Premium Medical Domains for Sale einsteinmedical.com |
 An internationalized domain name (IDN) is an Internet domain name that contains at least one label that is displayed in software applications, in whole or in part, in a language-specific script or alphabet, such as Chinese, Russian or the Latin-based languages with diacritics, such as French. These writing systems are encoded by computers in multi-byte Unicode. Internationalized domain names are stored in the Domain Name System as ASCII strings using Punycode transcription. The Domain Name System, which performs a lookup service to translate user-friendly names into network addresses for locating Internet resources, is restricted to the use of ASCII characters, a technical limitation that initially set the standard for acceptable domain names. The internationalization of domain names is a technical solution to translate names written in language-native scripts into an ASCII text representation that is compatible with the Domain Name System. Internationalized domain names can only be used with applications that are specifically designed for such use, and they require no changes in the infrastructure of the Internet. IDN was originally proposed in December 1996 by Martin Dürst[1][2] and implemented in 1998 by Tan Juay Kwang and Leong Kok Yong under the guidance of T.W. Tan. After much debate and many competing proposals, a system called Internationalizing Domain Names in Applications (IDNA) [3] was adopted as a standard, and has been implemented in several top-level domains. In IDNA, the term internationalized domain name means specifically any domain name consisting only of labels to which the IDNA ToASCII algorithm (see below) can be successfully applied. In March 2008, the IETF formed a new IDN working group to update[4] the current IDNA protocol. In October 2009, the Internet Corporation for Assigned Names and Numbers (ICANN) approved the creation of country code top-level domains (ccTLDs) in the Internet that use the IDNA standard for native language scripts.[5][6] [edit] Internationalizing Domain Names in ApplicationsInternationalizing Domain Names in Applications (IDNA) is a mechanism defined in 2003 for handling internationalized domain names containing non-ASCII characters. While much of the Domain Name System can technically support non-ASCII characters, applications such as e-mail and web browsers restrict domain names to what can be used as a hostname. Rather than redesigning the existing DNS infrastructure, it was decided that non-ASCII domain names should be converted to a suitable ASCII-based form by web browsers and other user applications; IDNA specifies how this conversion is to be done. IDNA was designed for maximum backward compatibility with the existing DNS system, which was designed for use with names using only a subset of the ASCII character set. An IDNA-enabled application is able to convert between the restricted-ASCII and non-ASCII representations of a domain, using the ASCII form in cases in which it is needed (such as for DNS lookup), but being able to present the more readable non-ASCII form to users. Applications that do not support IDNA will not be able to handle domain names with non-ASCII characters, but will still be able to access such domains if given the (usually rather cryptic) ASCII equivalent. ICANN issued guidelines for the use of IDNA in June 2003, and it was already possible to register .jp domains using this system in July 2003 and .info[7] domains in March 2004. Several other top-level domain registries started accepting registrations in 2004 and 2005. IDN Guidelines were first created[8] in June 2003, and have been updated[9] to respond to phishing concerns in November 2005. An ICANN working group focused on country code domain names at the top level was formed in November 2007[10] and promoted jointly by the country code supporting organization and the Governmental Advisory Committee. Mozilla 1.4, Netscape 7.1, Opera 7.11 were among the first applications to support IDNA. A browser plugin is available for Internet Explorer 6 to provide IDN support. Internet Explorer 7.0[11][12] and Windows Vista's URL APIs provide native support for IDN.[13] [edit] ToASCII and ToUnicodeThe conversions between ASCII and non-ASCII forms of a domain name are accomplished by algorithms called ToASCII and ToUnicode. These algorithms are not applied to the domain name as a whole, but rather to individual labels. For example, if the domain name is www.example.com, then the labels are www, example, and com. ToASCII or ToUnicode are applied to each of these three separately. The details of these two algorithms are complex, and are specified in RFC 3490. The following gives an overview of their function. ToASCII leaves unchanged any ASCII label, but will fail if the label is unsuitable for the Domain Name System. If given a label containing at least one non-ASCII character, ToASCII will apply the Nameprep algorithm, which converts the label to lowercase and performs other normalization, and will then translate the result to ASCII using Punycode[14] before prepending the four-character string "xn--". This four-character string is called the ASCII Compatible Encoding (ACE) prefix, and is used to distinguish Punycode encoded labels from ordinary ASCII labels. The ToASCII algorithm can fail in several ways; for example, the final string could exceed the 63-character limit of a DNS name. A label for which ToASCII fails cannot be used in an internationalized domain name. The function ToUnicode reverses the action of ToASCII, stripping off the ACE prefix and applying the Punycode decode algorithm. It does not reverse the Nameprep processing, since that is merely a normalization and is by nature irreversible. Unlike ToASCII, ToUnicode always succeeds, because it simply returns the original string if decoding fails. In particular, this means that ToUnicode has no effect on a string that does not begin with the ACE prefix. [edit] Example of IDNA encodingMain article: Punycode IDNA encoding may be illustrated using the example domain Bücher.ch. “Bücher” is German for “books”, and .ch is the ccTLD of Switzerland. This domain name has two labels, Bücher and ch. The second label is pure ASCII, and is left unchanged. The first label is processed by Nameprep to give bücher, and then converted to Punycode to result in bcher-kva. It is then prepended with xn-- to produce xn--bcher-kva. The final domain suitable for use in the DNS is therefore xn--bcher-kva.ch. [edit] Top-level domain implementation
The ICANN board approved the establishment of an internationalized top-level domain name working group within the Country Code Names Supporting Organisation (ccNSO) in December 2006.[15] They resolved in June 2007 inter alia to proceed and asked the IDNC Working Group to prepare a proposal, which the group delivered in June 2008, "to recommend mechanisms to introduce a limited number of non-contentious IDN ccTLDs, associated with the ISO 3166-1 two-letter codes in a short time frame to meet near term demand." The group proposed a methodology using ICANN's Fast Track Process[16] based on the ICANN charter to work with the Internet Assigned Numbers Authority (IANA): 1) Identify technical basis of the TLD strings and country code specific processes, select IDN ccTLD personnel and authorities, and prepare documentation; 2) Perform ICANN due diligence process for technical proposal and publish method; 3) Enter delegation process within established IANA procedures. Starting November 16, 2009, nations and territories may apply for IDN ccTLDs, which may be expected to be operational in mid-2010.[6] Non-Latin alphabet scripts are used by more than half of the world's 1.6 billion Internet users.[6] ICANN expects that Arabic, Chinese, and Russian domains are likely to be the first implementations.[6] ... .مصر .Miṣr Egypt (.eg) [edit] Timeline
[edit] Top-level domains known to accept IDN registration
[edit] Non-IDNA or non-ICANN registries that support non-ASCII domain namesThere are other registries that support non-ASCII domain names. The company ThaiURL.com in Thailand supports .com registrations via its own modified domain name system, ThaiURL. Because these companies, and other organizations that offer modified DNS systems, do not subject themselves to ICANN's control, they must be regarded as alternate DNS roots. Domains registered with them will therefore not be supported by most Internet service providers, and as a result most users will not be able to look up such domains without manually configuring their computers to use the alternate DNS. [edit] ASCII spoofing concernsMain article: IDN homograph attack The use of Unicode in domain names makes it potentially easier to spoof web sites visited by World Wide Web users as the visual representation of an IDN string in a web browser may appear identical to another, depending on the font used. For example, Unicode character U+0430, Cyrillic small letter a, can look identical to Unicode character U+0061, Latin small letter a, used in English. In December 2001 Evgeniy Gabrilovich and Alex Gontmakher, both from the Technion Institute of Technology in Israel, published a paper titled "The Homograph Attack",[29] which described an attack that used Unicode URLs to spoof a website URL. To prove the feasibility of this kind of attack, the researchers successfully registered a variant of the domain name microsoft.com which incorporated Russian language characters. These kind of problems were anticipated before IDN was introduced, and guidelines were issued[citation needed] to registries to try to avoid or reduce the problem. For example, it was advised that registries only accept characters from the Latin alphabet and that of their own country, not all of Unicode characters, but this advice was neglected by major TLDs.[citation needed] On February 7, 2005, Slashdot reported that this exploit was disclosed at the hacker conference Shmoocon.[30] Web browsers supporting IDNA appeared to direct the URL http://www.pаypal.com/, in which the first a character is replaced by a Cyrillic а, to the site of the well known payment site Paypal, but actually led to a spoofed web site with different content. Starting with version 7, Internet Explorer was capable of using IDNs, but it imposes restrictions on displaying non-ASCII domain names based on a user-defined list of allowed languages and provides an anti-phishing filter that checks suspicious Web sites against a remote database of known phishing sites.[citation needed] On February 17, 2005, Mozilla developers announced that the next software version still has IDN support enabled, but displaying the Punycode URLs instead, thus thwarting some attacks exploiting similarities between ASCII and non-ASCII characters, while still permitting access to web sites in an IDN domain. Since then, both Mozilla and Opera have announced that they will be using per-domain whitelists to selectively switch on IDN display for domain run by registries which are taking appropriate homograph spoofing attack precautions.[31] As of September 9, 2005, the most recent version of Mozilla Firefox as well as the most recent Internet Explorer display the spoofed Paypal URL as "http://www.xn--pypal-4ve.com/", clearly different from the original. Safari's approach is to render problematic character sets as Punycode. This can be changed by altering the settings in Mac OS X's system files.[32] [edit] See also[edit] References
[edit] External links
|
| ↑ top of page ↑ | about thumbshots |
