GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4290

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4290.txt · Last modified: 2005/12/22 17:30 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki