RFC 4290: Suggested Practices for Registration of Internationalized Domain Names (IDN) | RFC Editor

Skip to content Primary navigationThe RFC SeriesFor AuthorsAbout UsHomeRFC 4290 View as: Plain Text, Compact HTML Info RFC 4290: Suggested Practices for Registration of Internationalized Domain Names (IDN)DNSIDNDecember 2005. J. KlensinInformationalSubscribe15 subscribed Add to Set Read aloud Network Working Group J. Klensin Request for Comments: 4290 December 2005 Category: Informational Suggested Practices for Registration of Internationalized Domain Names (IDN) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). IESG Note This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information. Abstract This document explores the issues in the registration of internationalized domain names (IDNs). The basic IDN definition allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar- looking names. To avoid this confusion, the IDN registration process must impose rules that disallow some otherwise-valid name combinations. This document suggests a set of mechanisms that registries might use to define and implement such rules for a broad range of languages, including adaptation of methods developed for Chinese, Japanese, and Korean domain names. Klensin Informational [Page 1] RFC 4290 IDN Registration Practices December 2005 Table of Contents 1. Introduction ....................................................3 1.1. Background .................................................3 1.2. The Nature and Status of these Recommendations .............4 1.3. Terminology ................................................5 1.3.1. Languages and Scripts .................................5 1.3.2. Characters, Variants, Registrations, and Other Issues ................................................6 1.3.3. Confusion, Fraud, and Cybersquatting ..................9 1.4. A Review of the JET Guidelines .............................9 1.4.1. JET Model .............................................9 1.4.2. Reserved Names and Label Packages ....................10 1.5. Languages, Scripts, and Variants ..........................11 1.5.1. Languages versus Scripts .............................11 1.5.2. Variant Selection ....................................13 1.6. Variants are not a Universal Remedy .......................14 1.7. Reservations and Exclusions ...............................14 1.7.1. Sequence Exclusions for Valid Characters .............14 1.7.2. Character Pairing Issues .............................15 1.8. The Registration Bundle ...................................15 1.8.1. Definitions and Structure ............................15 1.8.2. Application of the Registration Bundle ...............16 2. Some Implications of This Approach .............................17 3. Possible Modifications of the JET Model ........................18 4. Conclusions and Recommendations About the General Approach .....18 5. A Model Table Format ...........................................19 6. A Model Label Registration Procedure: "CreateBundle" ...........20 6.1. Description of the CreateBundle Mechanism .................21 6.2. The "no-variants" Case ....................................22 6.3. CreateBundle and Nameprep Mapping .........................22 7. IANA Considerations ............................................23 8. Internationalization Considerations ............................24 9. Security Considerations ........................................24 10. Acknowledgements ..............................................25 11. Informative References ........................................26 Klensin Informational [Page 2] RFC 4290 IDN Registration Practices December 2005 1. Introduction 1.1. Background The IDNA (Internationalized Domain Names in Applications) specification [RFC3490] defines the basic model for encoding non- ASCII strings in the DNS. Additional specifications [RFC3491] [RFC3492] define the mechanisms and tables needed to support IDNA. As work on these specifications neared completion, it became apparent that it would be desirable for registries to impose additional restrictions on the names that could actually be registered (e.g., see [IESG-IDN] and [ICANN-IDN]) to reduce potential confusion among characters that were similar in some way. This document explores these IDN (international domain name) registration issues and suggests a set of mechanisms that IDN registries might use. Registration restrictions are part of a long tradition. For example, while the original DNS specifications [RFC1035] permitted any string of octets in a DNS label, they also recommended the use of a much more restricted subset. This subset was derived from the much older "hostname" rules [RFC952] and defined by the "LDH" convention (for the three permitted types of characters: letters, digits, and the hyphen). Enforcement of this restricted subset in registrations was the responsibility of the registry or domain administrator. The definition of the subset was embedded in the DNS protocol itself, although some applications protocols, notably those concerned with electronic mail, did impose and enforce similar rules. If there are no constraints on registration in a zone, people can register characters that increase the risk of misunderstandings, cybersquatting, and other forms of confusion. A similar situation existed even before the introduction of IDNA, as exemplified by domain names such as example.com and examp1e.com (note that the latter domain contains the digit "1" instead of the letter "l").