doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc4290.txt b/doc/rfc/rfc4290.txt
new file mode 100644
index 0000000..c123ccc
--- /dev/null
+++ b/doc/rfc/rfc4290.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+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").
+
+   For non-ASCII names (so-called "internationalized domain names" or
+   "IDNs"), the problem is more complicated.  In the earlier situation
+   that led to the LDH (hostname) rules, all protocols, hosts, and DNS
+   zones used ASCII exclusively in practice, so the LDH restriction
+   could reasonably be applied uniformly across the Internet.  Support
+   for IDNs introduces a very large character repertoire, different
+   geographical and political locations, and languages that require
+   different collections of characters.  The optimal registration
+   restrictions are no longer a global matter; they may be different in
+   different areas and, hence, in different DNS zones.
+
+
+
+
+
+
+Klensin                      Informational                      [Page 3]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+   For some human writing systems, there are characters and/or strings
+   that have equivalent or near-equivalent usages.  If a name can be
+   registered with such a character or string, the registry might want
+   to automatically associate all of the names that have the same
+   meaning with the registered name.  The registry might also decide
+   whether the names that are associated with, or generated by, one
+   registration should, as a group or individually, go into the zone or
+   should be blocked from registration by different parties.
+
+   To date, the best-developed system for handling registration
+   restrictions for IDNs is the JET Guidelines for Chinese, Japanese,
+   and Korean [RFC3743], the so-called "CJK" languages.  The JET
+   Guidelines are limited to the CJK languages and, in particular, to
+   their common script base.  Those languages are also the best-known
+   and most widely-used examples of writing systems constructed on
+   "ideographic" or "pictographic" principles.  This document explores
+   the principles behind the JET guidelines.  It then examines some of
+   the issues that might arise in adapting them to alphabetic languages,
+   i.e., to languages whose characters primarily represent sounds rather
+   than meanings.
+
+   This document describes five things:
+
+   1.  The general background and considerations for non-ASCII scripts
+       in names.
+
+   2.  Suggested practices for describing character variants.
+
+   3.  A method for using a zone's character variants to determine which
+       names should be associated with a registration.
+
+   4.  A format for publishing a zone's table of character variants;
+       Such tables are referred to below simply as "language tables" or
+       simply "tables".
+
+   5.  A model algorithm for name registration given the presence of
+       language tables.
+
+1.2.  The Nature and Status of these Recommendations
+
+   The document makes recommendations for consideration by registries
+   and, where relevant, by those who coordinate them, and by those who
+   use their services.  None of the recommendations are intended to be
+   normative.  Instead, the intent of the document is to illustrate a
+   framework for developing variations to meet the needs of particular
+   registries and their processing of particular languages.  Of course,
+   if registries make similar decisions and utilize similar tools, costs
+
+
+
+
+Klensin                      Informational                      [Page 4]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+   and confusion may be reduced -- both between registries and for users
+   and registrars who have relationships with more than one domain.
+
+   Just as the JET Guidelines contain some suggestions that may not be
+   applicable to alphabetic scripts, some of the suggestions here,
+   especially the more specific ones, may be applicable to some scripts
+   and not others.
+
+1.3.  Terminology
+
+1.3.1.  Languages and Scripts
+
+   This document uses the term "language" in what may be, to many
+   readers, an odd way.  Neither this specification, nor IDNA, nor the
+   DNS are directly concerned with natural language, but only with the
+   characters that make up a given label.  In some respects, the term
+   "script", used in the character coding community for a collection of
+   characters, might be more appropriate.  However, different subsets of
+   the same script may be used with different languages, and the same
+   language may be written using different characters (or even
+   completely different scripts) in different locations, so "script" is
+   not precisely correct either.
+
+   Long-standing confusion has also resulted from the fact that most
+   scripts are, informally at least, named after one of the languages
+   written in them.  "Chinese" describes both a language and a
+   collection of characters that are also used in writing Japanese,
+   Korean, and, at least historically, some other languages.  "Latin"
+   describes a language, the characters used to write that language,
+   and, often, characters used to write a number of contemporary
+   languages that are derived from or similar to those used to write the
+   Latin language.  The script used to write the Arabic language is
+   called "Arabic", but it is also used (typically with some additions
+   or deletions) to write a number of other languages.  Situations in
+   which a script has a clearly-defined name that is independent of the
+   name of a language are the exception, rather than the rule; examples
+   include Hangul, used to write Korean, Katakana and Hiragana, used to
+   write Japanese, and a few others.  Some scholars have historically
+   used "Roman" or "Roman-derived" for the script in an attempt to
+   distinguish between a script and the Latin language.
+
+   The term "language" is therefore used in this document in the
+   informal sense of a written language and is defined, for this
+   purpose, by the characters used to write it, i.e., as a language-
+   specific subset of a script.  In this context, a "language" is
+   defined by the combination of a code (see Section 1.4.1) and an
+   authority that has chosen to use that code and establish a
+   character-listing for it.  Authorities are normally TLD (top-level
+
+
+
+Klensin                      Informational                      [Page 5]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+   domain) registries; see Section 7 and [IANA-language-registry].
+   However, it is expected that TLD registries will find appropriate
+   experts and that advice from language and script experts selected by
+   international neutral bodies will also become part of the
+   registration system.  In addition, as discussed below in Section 7,
+   registries may conclude that the best interests of registrants,
+   stakeholders, and the Internet community would be served by
+   constructing "language tables" that mix scripts and characters in
+   ways that conform to no known language.  Conventions should be
+   developed for such registrations that do not misleadingly reflect
+   specific language codes.
+
+1.3.2.  Characters, Variants, Registrations, and Other Issues
+
+   1.  Characters in this document are specified by their Unicode
+       codepoints in U+xxxx format, by their official names, or both.
+
+   2.  The following terms are used in this document.
+
+       *  String
+
+          A "string" is an sequence of one or more characters.
+
+       *  Base Character
+
+          This document discusses characters that may have equivalent or
+          near-equivalent characters or strings.  A "base character" is
+          a character that has zero or more equivalents.  In the JET
+          Guidelines, base characters are referred to as "valid
+          characters".  In a table with variants, as described in
+          Section 5, the base characters occupy the first column.
+          Normally (and always, if the recommendation of Section 6.3 is
+          adopted), the base characters will be the characters that
+          appear in registration requests from registrants; any other
+          character will invalidate the registration attempt.
+
+       *  Native Script
+
+          Native script is the form in which the relevant string would
+          normally be represented.  For example, it might use Lower
+          Slobbovian characters and the glyphs normally used to write
+          them.  It would not be punycode as a presentation form.
+
+       *  Variant Characters/Strings
+
+          The "variant(s)" are character(s) and/or string(s) that are
+          treated as equivalent to the base character.  Note that these
+          might not be exactly equivalent characters; a particular
+
+
+
+Klensin                      Informational                      [Page 6]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+          original character may be a base character with a mapping to a
+          particular variant character, but that variant character may
+          not have a mapping to the original base character.  Indeed,
+          the variant character may not appear in the base character
+          list, and hence may not be valid for use in a registration.
+          Usually, characters or strings to be designated as variants
+          are considered either equivalent or sufficiently similar (by
+          some registry-specific definition) that confusion between them
+          and the base character might occur.
+
+       *  Base Registration
+
+          The "base registration" is the single name that the registrant
+          requested from the registry.  The JET Guidelines use the term
+          "label string" for this concept.
+
+       *  Registered, Activated
+
+          A label (or "name") is described as "registered" if it is
+          actually entered into a domain (i.e., into a zone file) by the
+          registry, so that it can be accessed and resolved using
+          standard DNS tools.  The JET Guidelines describe a
+          "registered" label as "activated".  However, some domains use
+          a slightly different registration logic in which a name can be
+          registered with the registrar (if one is involved) and with
+          the registry, but not actually entered into the zone file
+          until an additional activation or delegation step occurs.
+          This document does not make that distinction, but is
+          compatible with it.
+
+          As specified in the IDNA Standard, the name actually placed in
+          the zone file is always the internal ("punycode") form.  There
+          is no provision for actually entering any other form of an IDN
+          into the DNS.  It remains controversial, with different
+          registrars and registries having adopted different policies,
+          as to whether the registration, as submitted by the
+          registrant, is in the form of:
+
+          o  The native-script name, either in UTF-8 or in some coding
+             specified by the registrar, or
+
+          o  the internal-form ("punycode") name, or
+
+          o  both forms of the name together, so that the registrar and
+             registry can verify the intended translation.
+
+
+
+
+
+
+Klensin                      Informational                      [Page 7]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+          If any of the approaches defined in this document is used, it
+          is almost certain to be necessary that the native-script form
+          of the requested string be available to the registry.
+
+       *  Registration Bundle
+
+          A "registration bundle" is the set of all labels that come
+          from expanding the base characters for a single name into
+          their variants.  The presence of a label in a registration
+          bundle does not imply that it is registered.  In the JET
+          Guidelines, a registration bundle is called an "IDN Package".
+
+       *  Reserved Label
+
+          A "reserved label" is a label in a registration bundle that is
+          not actually registered.
+
+       *  Registry"
+
+          A "registry" is the administrative authority for a DNS zone.
+          The registry is the body that enforces, and typically makes,
+          policies that are used in a particular zone in the DNS.
+
+       *  Coded Character Set
+
+          A "Coded Character Set" (CCS) is a list of characters and the
+          code positions assigned to them.  ASCII and Unicode are CCSs.
+
+       *  Language
+
+          A "language" is something spoken by humans, independent of how
+          it is written or coded.  ISO Standard 639 and IETF BCP 47 (RFC
+          3066) [RFC3066] list and define codes for identifying
+          languages.
+
+       *  Script
+
+          A "script" is a collection of characters (glyphs, independent
+          of coding) that are used together, typically to represent one
+          or more languages.  Note that the script for one language may
+          heavily overlap the script for another.  This does not imply
+          that they have identical scripts.
+
+       *  Charset
+
+          "Charset" is an IETF-invented term to describe, more or less,
+          the combination of a script, a CCS that encodes that script,
+
+
+
+
+Klensin                      Informational                      [Page 8]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+          and rules for serializing encoded bytes that are stored on a
+          computer or transmitted over the network.
+
+   The last four of these definitions are redundant with, but
+   deliberately somewhat less precise than, the definitions in
+   [RFC3536], which also provides sources.  The two sets of definitions
+   are intended to be consistent.
+
+1.3.3.  Confusion, Fraud, and Cybersquatting
+
+   The term "confusion" is used very generically in this document to
+   cover the entire range from accidental user misperception of the
+   relationship between characters with some characteristic in common
+   (typically appearance, sound, or meaning) to cybersquatting and
+   (other) deliberately fraudulent attempts to exploit those
+   relationships based on the nature of the characters.
+
+1.4.  A Review of the JET Guidelines
+
+1.4.1.  JET Model
+
+   In the JET Guidelines model, a prospective registrant approaches the
+   registry for a zone (perhaps through an intermediate registrar) with
+   a candidate base registration -- a proposed name to be registered --
+   and a list of languages in which that name is to be interpreted.  The
+   languages are defined according to the fairly high-resolution coding
+   of [RFC3066] or, if the registry considers it more appropriate, a
+   coding based on scripts such as those in [LTRU-Registry].  In this
+   way, Chinese as used on the mainland of the People's Republic of
+   China ("zh-cn") can, at registry option, consist of a somewhat
+   different list of characters (code points) and be represented by a
+   separate table compared to Chinese as used in Taiwan ("zh-tw").
+
+   The design of the JET Guidelines took one important constraint as a
+   basis: IDNA was treated as a firm standard.  A procedure that
+   modified some portion of the IDNA functions, or was a variant on
+   them, was considered a violation of those standards and should not be
+   encouraged (or, probably, even permitted).
+
+   Each registry is expected to construct (or obtain) a table for each
+   language it considers relevant and appropriate.  These tables list,
+   for the particular zone, the characters permitted for that language.
+   If a character does not appear as a base character (called a "valid
+   code point" in the JET document) in that table, then a name
+   containing it cannot be registered.  If multiple languages are listed
+   for the registration, then the character must appear in the tables
+   for each of those languages.
+
+
+
+
+Klensin                      Informational                      [Page 9]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+   The tables may also contain columns that specify alternate or variant
+   forms of the valid character.  If these variants appear, they are
+   used to synthesize labels that are alternatives to the original one.
+   These labels are all reserved and can be registered or "activated"
+   (placed into the DNS) only by the action or request of the original
+   registrant; some (the "preferred variant labels") are typically
+   registered automatically.  The zone is expected to establish
+   appropriate policies for situations in which the variant forms of one
+   label conflict with already-reserved or already-registered labels.
+
+   Most of these concepts were introduced because of concerns about
+   specific issues with CJK characters, beginning from the requirement
+   that the use of Simplified Chinese by some registrants and
+   Traditional Chinese by others not be permitted to create confusion or
+   opportunities for fraud.  While they may be applicable to registry
+   tables constructed for alphabetic scripts, the translation should be
+   done with care, since many analogies are not exact.
+
+   Some of the important issues are discussed in the sections that
+   follow, especially Section 3.  The JET model may be considered as a
+   variation on, and inspiration for, the model and method presented by
+   the rest of this document, although the JET model has been completely
+   developed only for CJK characters.  Other languages or scripts,
+   especially alphabetic ones, may require other variations.
+
+1.4.2.  Reserved Names and Label Packages
+
+   A basic assumption of the JET model is that, if the evolution of
+   specific characters or the properties of Unicode [Unicode]
+   [Unicode32] or IDNA cause two strings to appear similar enough to
+   cause confusion, then both should be registered by the same party or
+   one of them should become unregisterable.  The definition of "appear
+   similar enough" will differ for different cultures and circumstance,
+   and hence DNS zones, but the principle is fairly general.  In the JET
+   model, all of the variant strings are identified, some are registered
+   into the DNS automatically, and others are simply reserved and can be
+   registered, if at all, only by the original registrant.  Other zones
+   might find other policies appropriate.  For example, a zone might
+   conclude that having similar strings registered in the DNS was
+   undesirable.  If so, the list of variant strings would be used only
+   to build a list of names that would be reserved and prohibited from
+   being registered.
+
+
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 10]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+1.5.  Languages, Scripts, and Variants
+
+1.5.1.  Languages versus Scripts
+
+   Conversations about scripts -- collections of characters associated
+   with particular languages -- are common when discussing character
+   sets and codes.  However, the boundaries between one script and
+   another are not well-defined.  The Unicode Standard ([Unicode],
+   [Unicode32]), for example, does not define script boundaries at all,
+   even though it is structured in terms of usually-related blocks of
+   characters.  The issue is complicated by the common origin of most
+   alphabetic scripts in use in the world today (see, for example,
+   [Drucker] or the more scholarly [Daniels]).
+
+   Because of that history, certain characters (or, more precisely,
+   symbols representing characters) appear in the scripts associated
+   with multiple languages, sometimes with very different sounds or
+   meanings.  This differs from the CJK situation in which, if a
+   character appears in more than one of the relevant languages, it will
+   usually have the same interpretation in each one.  For the subset of
+   characters that actually are ideographs or pictographs, pronunciation
+   is expected to vary widely while meaning is preserved.  At least in
+   part because of that similarity of meaning, it made sense in the JET
+   case to permit a registration to specify multiple languages, to
+   verify that the characters in the label string (the requested "Base
+   registration") were valid for each, and then to generate variant
+   labels using each language in turn.  For many alphabetic languages,
+   it may be more sensible to prohibit the label string submitted for
+   registration from being associated with more than one language.
+   Indeed, "one label, one language" has been suggested as an important
+   barrier against common sources of "look-alike" confusion.  For
+   example, the imposition of that rule in a zone would prevent the
+   insertion of a few Greek or Cyrillic characters with shapes identical
+   to the Latin ones into what was otherwise a Latin-based string.  For
+   a particular table, the list of base characters may be thought of as
+   the script associated with the relevant language, with the
+   understanding that the table design does not prevent the same
+   character from appearing in the tables for multiple languages.
+
+   Indeed, this notion of a script that is local and specifically
+   identified can be turned around: so-called "language tables" are
+   associated with languages only insofar as thinking about the
+   character structure and word forms associated with a given language
+   helps to inform the construction of the table.  A country like
+   Finland, for example, might select among:
+
+   o  One table each for Finnish, Swedish, and English characters and
+      conventions, permitting a string to be registered in one, two, or
+
+
+
+Klensin                      Informational                     [Page 11]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+      all three languages.  However, a three-language registration would
+      necessarily prohibit any characters that did not appear in all
+      three languages, since the label would make little sense
+      otherwise.
+
+   o  One table each, but with a "one label, one language" rule for the
+      zone.
+
+   o  A combined table based on the observation that all three writing
+      systems were based on Roman characters and that the possibilities
+      for confusion of interest to the registry would not be reduced by
+      "language" differentiation.  This option raises an interesting
+      issue about language labeling as described in Section 1.4.1; see
+      the discussion in Section 7 below.
+
+   Regardless of what decisions were made about those languages and
+   scripts, they might have a separate table for registration of labels
+   containing Cyrillic characters.  That table might contain some
+   Roman-derived characters (either as base characters or as variants),
+   just as some CJK tables do.  See also Section 2, below.
+
+   Tables that present multiple languages, as described above, have
+   introduced confusion and discomfort among those who have failed to
+   understand these definitions.  The consequence of these definitions
+   is that use of a language or script code in a registration is a
+   mnemonic, rather than a normative statement about the language or
+   script itself.  When that confusion is likely to occur, it is
+   appropriate to simply use the registry identifier and a sequence
+   number to identify the registration.
+
+   As the JET Guidelines stress, no tables or systems of this type --
+   even if identified with a language as a means of defining or
+   describing the table -- can assure linguistic or even syntactic
+   correctness of labels with regard to that language.  That assurance
+   may not be possible without human intervention or at least dictionary
+   lookups of complete proposed labels.  It may even not be desirable to
+   attempt that level of correctness (see Section 2).
+
+   Of course, if any language-based tests or constraints, including "one
+   label, one language", are to be applied to limit the associated
+   sources of confusion, each zone must have a table for each language
+   in which it expects to accept registrations.  The notion of a single
+   combined table for the zone is, in the general case, simply
+   unworkable.  One could use a single table for the zone if the intent
+   were to impose only minimal restrictions, e.g., to force alphabetic
+   and numeric characters only, excluding symbols and punctuation.  That
+   type of restriction might be useful in eliminating some problems,
+   such as those of unreadable labels, but it would be unlikely to be
+
+
+
+Klensin                      Informational                     [Page 12]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+   very helpful with, e.g., confusion caused by similar-looking
+   characters.
+
+1.5.2.  Variant Selection
+
+   The area of character variants is rife with difficulties (and perhaps
+   opportunities).  There is no universal agreement about which base
+   characters have variants, or if they do, what those variants are.
+   For example, in some regions of the world and in some languages,
+   LATIN SMALL LETTER O WITH DIAERESIS (U+00F6) and LATIN SMALL LETTER O
+   WITH STROKE (U+00F8) are variants of each other, while in other
+   regions, most people would think that LATIN SMALL LETTER O WITH
+   STROKE has no variants.  In some cases, the list of variants is
+   difficult to enumerate.  For example, it required several years for
+   the Chinese language community to create variant tables for use with
+   IDNA, and it remains, at the time of this writing, questionable how
+   widely those tables will be accepted among users of Chinese from
+   areas of the world other than those represented by the groups that
+   created them.
+
+   Thus, the first thing a registry should ask is whether or not any of
+   the characters that they want to permit to be used have variants.  If
+   not, the registry's work is much simpler.  This is not to say that a
+   registry should ignore variants if they exist: adding variants after
+   a registry has started to take registrations will be nearly as
+   difficult administratively as removing characters from the list of
+   acceptable characters.  That is, if a registry later decides that two
+   characters are variants of each other, and there are actively-used
+   names in the zones that differ only on the new variants, the registry
+   might have to transfer ownership of one of the names to a different
+   owner, using some process that is certain to be controversial.
+
+   This situation in likely to be much easier for areas and zones that
+   use characters that previously did not occur in the DNS at all than
+   it will be for zones in which non-English labels have been registered
+   in ASCII characters for some time, presumably because the language of
+   interest uses additional "Latin" characters with some conventions
+   when only ASCII is available.  In the former case, the rules and
+   conventions can be established before any registrations occur.  In
+   the latter, there may be conflicts or opportunities for confusion
+   between existing registrations and now-permitted Roman-based
+   characters that do not appear in ASCII.  For example, a domain name
+   might exist today that uses the name of a city in Canada spelled as
+   "Montreal".  If the zone in which it occurs changes its rules to
+   permit the use of the character LATIN SMALL LETTER E WITH ACUTE
+   (U+00E9), does the name of the city, spelled (correctly) using that
+   character, conflict with the existing domain name registration?
+
+
+
+
+Klensin                      Informational                     [Page 13]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+   Certainly, if both are permitted, and permitted to be registered by
+   separate parties, there are many opportunities for confusion.
+
+   Of course, zone managers should inform all current registrants when
+   the registration policy for the zone changes.  This includes the
+   times when IDN characters are first allowed in the zone, when
+   additional characters are permitted, and when any change occurs in
+   the character variant tables.
+
+   Many languages contain two variants for a character, one of which is
+   strongly preferred.  A registry might restrict the base registration
+   to the preferred form, or it might allow any form for the base
+   registration.  If the variant tables are created carefully, the
+   resulting bundles will be the same, but some registries will give
+   special status to the base registration such as its appearance in
+   "Whois" databases.
+
+1.6.  Variants are not a Universal Remedy
+
+   It is worth stressing that there are many obvious opportunities for
+   confusion that variant systems, by virtue of being based on
+   processing of individual characters, cannot address.  For example, if
+   a language can be written with more than one script, or
+   transliterations of the language into another script are common,
+   variant models are insufficient to prevent conflicting registration
+   of the related forms.  Avoiding those types of problems would require
+   different mechanisms, perhaps based on phonetic or natural language
+   processing techniques for the entire proposed base registration.
+
+1.7.  Reservations and Exclusions
+
+1.7.1.  Sequence Exclusions for Valid Characters
+
+   The JET Guidelines are based on processing only single characters.
+   Pairs or longer sequences of characters can, at the option of the
+   registry, be handled through what the Guidelines describe as
+   "additional processing".  These registry-specific string processing
+   procedures are specifically permitted by the guidelines to supplement
+   the per-character processing that generates the variants.
+
+   A different zone with different needs could use a modified version of
+   the table structure, or different types of additional processing, to
+   prohibit particular sequences of characters by marking them as
+   invalid, and to accept characters by marking them as valid.  Other
+   modifications or extensions might be designed to prevent certain
+   letters from appearing at the beginning or end of labels.  The use of
+   regular expressions in the "valid characters" column might be one way
+
+
+
+
+Klensin                      Informational                     [Page 14]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+   to implement these types of restrictions, but there has been no
+   experience so far with that approach.
+
+   In particular, in some scripts derived from Roman characters,
+   sequences that have historically been typographically represented by
+   single "ligature" or "digraph" characters may also be represented by
+   the separate characters (e.g., "ae" for U+00E6 or "ij" for U+0133).
+   If it is desired to either prohibit these, or to treat them as
+   variants, some extensions to the single-character JET model may be
+   needed.  Some careful thinking about IDNA (especially nameprep) may
+   also be needed, since some of these combinations are excluded there).
+
+1.7.2.  Character Pairing Issues
+
+   Some character pairings -- the use of a character form (glyph) in one
+   language and a different form with the same properties in a related
+   one -- closely approximate the issues with mapping between
+   Traditional and Simplified Chinese, although the history is
+   different.  For example, it might be useful to have "o" with a stroke
+   (U+00F8) as a variant for "o" with diaeresis above it (U+00F6) (and
+   the equivalent upper-case pair) in a Swedish table, and vice versa in
+   a Norwegian one, or to prohibit one of these characters entirely in
+   each table.  In a German table, U+00F8 would presumably be
+   prohibited, while U+00F6 might have "oe" as a variant.  Obviously, if
+   the relevant language of registration is unknown, this type of
+   variant matching cannot be applied in any sensible way.
+
+1.8.  The Registration Bundle
+
+1.8.1.  Definitions and Structure
+
+   As one of its critical innovations, the JET model defines an "IDN
+   package", known in this document as a "registration bundle", which
+   consists of the primary registered string (which is used as the name
+   of the bundle), the information about the language table(s) used, the
+   variant labels for that string, and indications of which of those
+   labels are registered in the relevant zone file ("activated" in the
+   JET terminology).  Registration bundles are also atomic -- one can
+   not add or remove variant labels from one without unregistering the
+   entire package.  A label exists in only one registration bundle at a
+   time; if a new label is registered that would generate a variant that
+   matches one that appears in an existing package, that variant simply
+   is not included in the second package.  A subsequent de-registration
+   of the first package does not cause the variant to be added to the
+   second.  While it might be possible to change this in other models,
+   the JET conclusion was that other options would be far too complex to
+   implement and operate and would cause many new types of name
+   conflicts.
+
+
+
+Klensin                      Informational                     [Page 15]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+1.8.2.  Application of the Registration Bundle
+
+   A registry has three options for handling the case where the
+   registration bundle contains more than one label.  The policy options
+   are:
+
+   o  Register and resolve all labels in the zone, making the zone
+      information identical to that of the registered labels.  This
+      option will allow end users to find names with variants more
+      easily, but will result in larger zone files.  For some language
+      tables, the zone file could become so large that it could
+      negatively affect the ability of the registry to perform name
+      resolution.  If the base registration contains several characters
+      that have equivalents, the owner could end up having to take care
+      of large numbers of zones.  For instance, if DIGIT ONE is a
+      variant of LATIN SMALL LETTER L, the owner of the domain name all-
+      lollypops.example.com will have to manage 32 zones.  If the intent
+      is to keep the contents of those zones identical, the owner may
+      then face a significant administrative problem.  If other concerns
+      dictate short times to live and absolute consistency of DNS
+      responses, the challenges may be nearly impossible.
+
+   o  Block all labels other than the registered label so they cannot be
+      registered in the future.  This option does not increase the size
+      of the zone file and provides maximum safety against false
+      positives, but it may cause end users to not be able to find names
+      with variants that they would expect.  If the base registration
+      contains characters that have equivalents, Internet users who do
+      not know what base characters were used in the registration will
+      not know what character to type in to get a DNS response.  For
+      instance, if DIGIT ONE is a variant of LATIN SMALL LETTER L, and
+      LATIN SMALL LETTER L is a variant of DIGIT ONE, the user who sees
+      "pale.example.com" will not know whether to type a "1" or a "l"
+      after the "pa" in the first label.
+
+   o  Resolve some labels and block some other labels.  This option is
+      likely to cause the most confusion with users because including
+      some variants will cause a name to be found, but using other
+      variants will cause the name to be not found.  For example, even
+      if people understood that DIGIT ONE and LATIN SMALL LETTER L were
+      variants, a typical DNS user wouldn't know which character to type
+      because they wouldn't know whether this pair were used to register
+      or block the labels.  However, this option can be used to balance
+      the desires of the name owner (that every possible attempt to
+      enter their name will work) with the desires of the zone
+      administrator (to make the zone more manageable and possibly to be
+      compensated for greater amounts of work needed for a single
+
+
+
+
+Klensin                      Informational                     [Page 16]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+      registration).  For many circumstances, it may be the most
+      attractive option.
+
+   In all cases, at least the registered label should appear in the
+   zone.  It would be almost impossible to describe to name owners why
+   the name that they asked for is not in the zone, but some other name
+   that they now control is.  By implication, if the requested label is
+   already registered, the entire registration request must be rejected.
+
+2.  Some Implications of This Approach
+
+   Historically, DNS labels were considered to be arbitrary identifier
+   strings, without any inherent meaning.  Even in ASCII, there was no
+   requirement that labels form words.  Labels that could not possibly
+   represent words in any Romance or Germanic language (the languages
+   that have been written in "Latin" scripts since medieval times or
+   earlier) have actually been quite common.  In general, in those
+   languages, words contain at least one vowel and do not have embedded
+   numbers.  As a result, a string such as "bc345df" cannot possibly be
+   a "word" in these languages.  More generally, the more one moves
+   toward "language"-based registry restrictions, the less it is going
+   to be possible to construct labels out of fanciful strings.  While
+   fanciful strings are terrible candidates for "words", they may make
+   very good identifiers.  To take a trivial example using only ASCII
+   characters, "rtr32w", "rtr32x", and "rtr32z" might be very good DNS
+   labels for a particular zone and application.  However, given the
+   embedded digits and lack of vowels, they, like the "bc345df" example
+   given above, would fail even the most superficial of tests for valid
+   English (or German or French (etc.)) word forms.
+
+   It is worth noting that several DNS experts have suggested that a
+   number of problems could be solved by prohibiting meaningful names in
+   labels, requiring instead that the labels be random or nonsense
+   strings.  If methods similar to those discussed in this document were
+   used to force identifiers to be closer to meaningful words in real
+   languages, the result would be directly contradictory to those
+   "random name" approaches.
+
+   Interestingly, if one were trying to develop an "only words" system,
+   a rather different -- but very restrictive -- model could be
+   developed using lookups in a dictionary for the relevant language and
+   a listing of valid business names for the relevant area.  If a string
+   did not appear in either, it would not be permitted to be registered.
+   Models that require a prior national business listing (or
+   registration) that is identical to the proposed domain name label
+   have historically been used to restrict registrations in some
+   country-code top level domains, so this is not a new idea.  On the
+   other hand, if look-alike characters are a concern, even that type of
+
+
+
+Klensin                      Informational                     [Page 17]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+   rule (or restriction) would still not avoid the need to consider
+   character variants.
+
+   Consequently, registries applying the principles outlined in this
+   document should be careful not to apply more severe restrictions than
+   are reasonable and appropriate while, at the same time, being aware
+   of how difficult it usually is to add restrictions at a later time.
+
+3.  Possible Modifications of the JET Model
+
+   The JET model was designed for CJK characters.  The discussion above
+   implies that some extensions to it may be needed to handle the
+   characteristics of various alphabetic scripts and the decisions that
+   might be made about them in different zones.  Those extensions might
+   include facilities to process:
+
+   o  Two-character (or more) sequences, such as ligatures and
+      typographic spelling conventions, as variants.
+
+   o  Regular expressions or some other mechanism for dealing with
+      string positions of characters (e.g., characters that must, or
+      must not, appear at the beginning or end of strings).
+
+   o  Delimiter breaks to permit multiple languages to be used,
+      separately, within the same label.  E.g., is it possible to define
+      a label as consisting of two or more components, each in a
+      different language, with some particular delimiter to define the
+      boundaries of the components?
+
+4.  Conclusions and Recommendations About the General Approach
+
+   After examining the implications of the potential use of the full
+   range of characters permitted by IDNA in DNS labels, multiple groups,
+   including IESG [IESG-IDN] and ICANN [ICANN-IDN] [ICANN-IDN2], have
+   concluded that some restrictions are needed to prevent many forms of
+   user confusion about the actual structure of a name or the word,
+   phrase, or term that it appears to spell out.  The best way to
+   approach such restrictions appears to draw from the language and
+   culture of the community of registrants and users in the relevant
+   zone: if particular characters are likely to be surprising or
+   unintelligible to both of those groups, it is probably wise to not
+   permit them to be used in registrations.  Registration restrictions
+   can be carried much further than restricting permitted characters to
+   a selected Unicode subset.  The idea of a reserved "bundle" of
+   related labels permits probably-confusing combinations or sets of
+   characters to be bound together, under the control of a single
+   registrant.  While that registrant might still use the package in a
+   way that confused his or her own users (the approach outlined here
+
+
+
+Klensin                      Informational                     [Page 18]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+   will not prevent either ill-though-out ideas or stupidity), the
+   possibility of turning potential confusion into a hostile attack
+   would be considerably reduced.
+
+   At the same time, excessive restrictions may make DNS identifiers
+   less useful for their original purpose: identifying particular hosts
+   and similar resources on the network in an orderly way.  Registries
+   creating rules and policies about what can be registered in
+   particular zones -- whether those are based on the JET Guidelines or
+   the suggestions in this document -- should balance the need for
+   restrictions against the need for flexibility in constructing
+   identifiers.
+
+   The discussion above provides many options that could be selected,
+   defined, and applied in different ways in different registries
+   (zones).  Registrars and registrants would almost certainly prefer
+   systems in which they can predict, at least to a first order
+   approximation, the implications of a particular potential
+   registration.  Predictability of that sort probably requires more
+   standards, and less flexibility, than the model itself might suggest.
+
+5.  A Model Table Format
+
+   The format of the table is meant to be machine-readable but not
+   human-readable.  It is fairly trivial to convert the table into one
+   that can be read by people.
+
+   Each character in the table is given in the "U+" notation for Unicode
+   characters.  The lines of the table are terminated with either a
+   carriage return character (ASCII 0x0D), a linefeed character (ASCII
+   0x0A), or a sequence of carriage return followed by linefeed (ASCII
+   0x0D 0x0A).  The order of the lines in the table may or may not
+   matter, depending on how the table is constructed.
+
+   Comment lines in the table are preceded with a "#" character (ASCII
+   0x2C).
+
+   Each non-comment line in the table starts with the character that is
+   allowed in the registry and expected to be used in registrations,
+   which is also called the "base character".  If the base character has
+   any variants, the base character is followed by a vertical bar
+   character ("|", ASCII 0x7C) and the variant string.  If the base
+   character has more than one variant, the variants are separated by a
+   colon (":", ASCII 0x3A).  Strings are given with a hyphen ("-", ASCII
+   0x2D) between each character.  Comments beginning with a "#" (ASCII
+   0x2C), and may be preceded by spaces (" ", ASCII 0x20).
+
+
+
+
+
+Klensin                      Informational                     [Page 19]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+   The following is an example of how a table might look.  The entries
+   in this table are purposely silly and should not be used by any
+   registry as the basis for choosing variants.  For the example, assume
+   that the registry:
+
+   o  allows the FOR ALL character (U+2200) with no variants
+
+   o  allows the COMPLEMENT character (U+2201) which has a single
+      variant of LATIN CAPITAL LETTER C (U+0043)
+
+   o  allows the PROPORTION character (U+2237) which has one variant
+      which is the string COLON (U+003A) COLON (U+003A)
+
+   o  allows the PARTIAL DIFFERENTIAL character (U+2202) which has two
+      variants: LATIN SMALL LETTER D (U+0064) and GREEK SMALL LETTER
+      DELTA (U+03B4)
+
+   The table contents (after any required header information, see
+   [IANA-language-registry] and the discussion in Section 7 below) would
+   look like:
+
+       # An example of a table
+       U+2200
+       U+2201|U+0043
+       U+2237|U+003A-U+003A # Note that the variant is a string
+       U+2202|U+0064:U+03B4 # Two variants for the same character
+
+   Implementers of table processors should remember that there are tens
+   of thousands of characters whose codepoints are greater than 0xFFFF.
+   Thus, any program that assumes that each character in the table is
+   represented in exactly six octets ("U", "+", and four octets
+   representing the character value) will fail with tables that use
+   characters whose value is greater than 0xFFFF.
+
+6.  A Model Label Registration Procedure: "CreateBundle"
+
+   This procedure has three inputs:
+
+   1.  the proposed base registration,
+
+   2.  the language (or script, if the registration is script-based, but
+       "language" is used for convenience below) for the proposed base
+       registration, and
+
+   3.  the processing table associated with that language.
+
+   The output of the process is either failure (the base registration
+   cannot be registered at all), or a registration bundle that contains
+
+
+
+Klensin                      Informational                     [Page 20]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+   one or more labels (always including the base registration).  As
+   described earlier, the registration bundle should be stored with its
+   date of creation so that issues with overlapping elements between
+   bundles can later be resolved on a first-come, first-served basis.
+
+   There are two steps to processing the registration:
+
+   1.  Check whether the proposed base registration exists in any
+       bundle.  If it does, stop immediately with a failure.
+
+   2.  Process the base registration with the mechanism described as
+       "CreateBundle" in Section 6.1, below.
+
+   Note that the process must be executed only once.  The process must
+   not be performed on any output of the process, only on the proposed
+   base registration.
+
+6.1.  Description of the CreateBundle Mechanism
+
+   The CreateBundle mechanism determines whether a registration bundle
+   can be created and, if so, populates that bundle with valid labels.
+
+   During the processing, a "temporary bundle" contains partial labels,
+   that is, labels that are being built and are not complete labels.
+   The partial labels in the temporary bundle consist of strings.
+
+   The steps are:
+
+   1.  Split the base registration into individual characters, called
+       "candidate characters".  Compare every candidate character
+       against the base characters in the table.  If any candidate
+       character does not exist in the set of base characters, the
+       system must stop and not register any names (that is, it must not
+       register either the base registration or any labels that would
+       have come from character variants).
+
+   2.  Perform the steps in IDNA's ToASCII sequence for the base
+       registration.  If ToASCII fails for the base registration, the
+       system must stop and not register any label (that is, it must not
+       register either the base registration or labels that might have
+       been created from variants of characters contained in it).  If
+       ToASCII succeeds, place the base registration into the
+       registration bundle.
+
+   3.  For every candidate character in the base registration, do the
+       following:
+
+
+
+
+
+Klensin                      Informational                     [Page 21]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+       o  Create the set of characters that consists of the candidate
+          character and any variants.
+
+       o  For each character in the set from the previous step,
+          duplicate the temporary bundle that resulted from the previous
+          candidate character, and add the new character to the end of
+          each partial label.
+
+   4.  The temporary bundle now contains zero or more labels that
+       consist of Unicode characters.  For every label in the temporary
+       bundle, do the following:
+
+       o  Process the label with ToASCII to see if ToASCII succeeds.  If
+          it does, add the label to the registration bundle.  Otherwise,
+          do not process this label from the temporary bundle any
+          further; it will not go into the registration bundle.
+
+   The result of the processing outlined above is the registration
+   bundle with the base registration and possibly other labels.
+
+6.2.  The "no-variants" Case
+
+   It is clear that, for many scripts, registries will choose to create
+   tables without variants, either because variants are clearly not
+   necessary or because they are determined to cause more confusion and
+   overhead than is justified by the circumstances.  For those
+   situations the table model of Section 5 becomes a trivial listing of
+   base characters and only the first two steps of CreateBundle
+   (verifying that all candidate character are in the base ("valid")
+   character list and verifying that the resulting characters will
+   succeed in the ToASCII operation) are applicable.  Even the second of
+   those steps becomes pro forma if the advice in the next subsection is
+   followed.
+
+6.3.  CreateBundle and Nameprep Mapping
+
+   One of the functions of Nameprep, and IDNA more generally, is to map
+   a large number of Unicode characters (code points) into a smaller
+   number to avoid a different but overlapping set of confusion
+   problems.  For example, when a non-ASCII script makes distinctions
+   between "upper case" and "lower case", nameprep maps the upper case
+   characters to the lower case ones in order to simulate the DNS
+   protocol's rule that ASCII characters are interpreted in a case-
+   insensitive way.  Unicode also contains many code points that are
+   typographic variants on each other (e.g., forms with different widths
+   and code points that designate font variations for mathematical
+   uses), the Unicode standard explicitly identifies them that way, and
+   Nameprep maps these onto base characters.
+
+
+
+Klensin                      Informational                     [Page 22]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+   While having these mapping functions available during lookup may be
+   quite helpful to users who type equivalent forms, registrations are
+   probably best performed in terms of the IDNA base characters only,
+   i.e., those characters that nameprep will not change.  This will have
+   two advantages.
+
+   o  Registrants will never find themselves in the rather confusing
+      position of having submitted one string for registration and
+      finding a different string in the registry database (which could
+      otherwise occur even if the relevant language table does not
+      contain variants).
+
+   o  Those who are interested in what characters are permitted by a
+      given registry will only need to examine the relevant tables,
+      rather than simulating the IDNA algorithm to determine the result
+      of processing particular characters.
+
+7.  IANA Considerations
+
+   Under ICANN (not IETF) direction and management, the IANA has created
+   a registry for language variant tables.  The authoritative
+   documentation for that registry is in [IANA-language-registry].
+   Since the registry exists and is being managed under ICANN direction,
+   the material that follows is a review of the theory of this registry,
+   rather than new instructions for IANA.
+
+   As described above and suggested in the JET Guidelines, the
+   registration rules generally require only that:
+
+   o  The application be submitted or endorsed by a TLD registry, to
+      ensure that someone cares about the particular table.
+
+   o  The table be identified by the following:
+
+      *  the name -- usually the top-level domain name -- of the
+         submitting or endorsing registry;
+
+      *  one of: a language designation (consistent with [RFC3066] or
+         with some other system approved by the IANA), a script
+         designation, a combination of the two, or a sequence number
+         acceptable to IANA for this purpose;
+
+      *  a version number; and
+
+      *  a date.
+
+   o  Characters listed in the table be identified by Unicode code
+      points, as discussed above.
+
+
+
+Klensin                      Informational                     [Page 23]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+   o  The table format may correspond to that identified in [RFC3743],
+      or in Section 5 above, or may be some variation on those themes
+      appropriate to the local processing model (with or without
+      variants).
+
+   This raises some issues that will need to be worked out as
+   experiences accumulate.  For example, more standardization of table
+   formats would be desirable to allow processing by the same computer
+   tools for different registries and languages.  But standardization
+   seems premature at this time due to differences in languages,
+   processing, and requirements and lack of experience with them.
+   Similarly, if a registry concludes that it should use a table that
+   contains characters from several scripts, it is not clear how such a
+   table should be designated.  Identifying it with a language code
+   (either according to [RFC3066] or an independent code registered with
+   IANA) is likely to just introduce more confusion, especially given
+   other Internet uses of the language codes.  It appears that some
+   other convention will be needed for those cases, and it should be
+   developed (if it has not already been established by the time this
+   document is published).
+
+8.  Internationalization Considerations
+
+   This document specifies a model mechanism for registering
+   Internationalized Domain Names (IDNs) that can be used to reduce
+   confusion among similar-appearing names.  The proposal is designed to
+   facilitate internationalization while permitting a balance between
+   internationalization concerns and concerns about keeping the Internet
+   global and domain name system references unique in the perception of
+   the user as well as in practice.
+
+9.  Security Considerations
+
+   Registration of labels in the DNS that contain essentially
+   unrestricted sequences of arbitrary Unicode characters may introduce
+   opportunities for either attacks or simple confusion.  Some of these
+   risks, such as confusion about which character (of several that look
+   alike) is actually intended, may be associated with the presentation
+   form of DNS names.  Others may be linked to databases associated with
+   the DNS, e.g., with the difficulty of finding an entry in a "Whois
+   file" when it is not clear how to enter or to search for the
+   characters that make up a name.  This document discusses a family of
+   restrictions on the names that can be registered.  Restrictions of
+   the type described can be imposed by a DNS zone ("registry").  The
+   document also describes some possible tools for implementing such
+   restrictions.
+
+
+
+
+
+Klensin                      Informational                     [Page 24]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+   While the increased number and types of characters made available by
+   Unicode considerably increases the scale of the potential problems,
+   the problems addressed by this document are not new.  No plausible
+   set of restrictions will eliminate all problems and sources of
+   confusion: for example, it has often been pointed out that, even in
+   ASCII, the characters digit-one ("1") and lower case L ("l") can
+   easily be confused in some display fonts.  But, to the degree to
+   which security may be aided by sensible risk reduction, these
+   techniques may be helpful.
+
+10.  Acknowledgements
+
+   Discussions in the process of developing the JET Guidelines were
+   vital in developing this document and all of the JET participants are
+   consequently acknowledged.  Attempts to explain some of the issues
+   uncovered there to, and feedback from, Vint Cerf, Wendy Rickard, and
+   members of the ICANN IDN Committee were also helpful in the thinking
+   leading up to this document.
+
+   An effort by Paul Hoffman to create a generic specification for
+   registration restrictions of this type helped to inspire this
+   document, which takes a somewhat different, more language-oriented,
+   approach than his initial draft.  While the initial version of that
+   draft indicated that multiple languages (or multiple language tables)
+   for a single zone were infeasible, more recent versions [Hoffman-reg]
+   shifted to inclusion of language-based approaches.  The current
+   version of this document incorporates considerable text, and even
+   more ideas, from those drafts, with Paul Hoffman's generous
+   permission.
+
+   Feedback was provided by several registry operators (of both country
+   code and generic TLDs), including Edmon Chung and Ram Mohan of
+   Afilias, and by ICANN and IANA staff, notably Tina Dam and Theresa
+   Swinehart.  This feedback about issues encountered in registering
+   tables and designing IDN implementations resulted in the addition of
+   significant clarifying text to the current version of the document.
+
+   The opinions expressed here are the sole responsibility of the
+   author.  Some of those whose ideas and comments are reflected in this
+   document may disagree with the conclusions the author has drawn from
+   them.  The first draft version of this document was posted in June
+   2003.
+
+
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 25]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+11.  Informative References
+
+   [Daniels]     P.T. Daniels and W. Bright, The World's Writing
+                 Systems, Oxford: Oxford University Press: 1996.
+
+   [Drucker]     Drucker, J., "The Alphabetic Labyrinth: The Letters in
+                 History and Imagination", 1995.
+
+   [Hoffman-reg] Hoffman, P., "A Method for Registering
+                 Internationalized Domain Names", Work in Progress,
+                 October 2003.
+
+   [IESG-IDN]    Internet Engineering Steering Group, IETF, "IESG
+                 Statement on IDN", IESG Statement available from
+                 http://www.ietf.org/IESG/STATEMENTS/IDNstatement.txt,
+                 February 2003.
+
+   [ICANN-IDN]   Internet Corporation for Assigned Names and Numbers
+                 (ICANN), "Guidelines for the Implementation of
+                 Internationalized Domain Names, Version 1.0", June
+                 2003.
+
+   [ICANN-IDN2]  Internet Corporation for Assigned Names and Numbers
+                 (ICANN), "Guidelines for the Implementation of
+                 Internationalized Domain Names, Version 2.0", September
+                 2005.
+
+   [IANA-language-registry]
+                 Internet Assigned Numbers Authority (IANA), "IDN
+                 Language Table Registry", April 2004.
+
+   [LTRU-Registry]
+                 Phillips, A., Ed. and M. Davis, Ed., "Tags for
+                 Identifying Languages", Work in Progress, October 2005.
+
+   [RFC952]      Harrenstien, K., Stahl, M., and E. Feinler, "DoD
+                 Internet host table specification", RFC 952, October
+                 1985.
+
+   [RFC1035]     Mockapetris, P., "Domain names - implementation and
+                 specification", STD 13, RFC 1035, November 1987.
+
+   [RFC3066]     Alvestrand, H., "Tags for the Identification of
+                 Languages", BCP 47, RFC 3066, January 2001.
+
+   [RFC3490]     Faltstrom, P., Hoffman, P., and A. Costello,
+                 "Internationalizing Domain Names in Applications
+                 (IDNA)", RFC 3490, March 2003.
+
+
+
+Klensin                      Informational                     [Page 26]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+   [RFC3491]     Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
+                 Profile for Internationalized Domain Names (IDN)", RFC
+                 3491, March 2003.
+
+   [RFC3492]     Costello, A., "Punycode: A Bootstring encoding of
+                 Unicode for Internationalized Domain Names in
+                 Applications (IDNA)", RFC 3492, March 2003.
+
+   [RFC3536]     Hoffman, P., "Terminology Used in Internationalization
+                 in the IETF", RFC 3536, May 2003.
+
+   [RFC3743]     Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
+                 Engineering Team (JET) Guidelines for Internationalized
+                 Domain Names (IDN) Registration and Administration for
+                 Chinese, Japanese, and Korean", RFC 3743, April 2004.
+
+   [Unicode]     The Unicode Consortium, "The Unicode Standard --
+                 Version 3.0", January 2000.
+
+   [Unicode32]   The Unicode Consortium, "Unicode Standard Annex #28:
+                 Unicode 3.2", March 2002.
+
+Author's Address
+
+   John C Klensin
+   1770 Massachusetts Ave, #322
+   Cambridge, MA  02140
+   USA
+
+   Phone: +1 617 491 5735
+   EMail: john-ietf@jck.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 27]
+
+RFC 4290               IDN Registration Practices          December 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78 and at www.rfc-editor.org/copyright.html, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 28]
+