RFC 3743
Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean
Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean 🎀
- Network Working Group 🦋
- RFC 3743 (Request for Comments: 3743) 💖
- Category: Informational 🌸
- Date: April 2004 📅
- Authors: K. Konishi, K. Huang, H. Qian, Y. Ko 👑
- Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🧚
Status of this Memo ✨
Okay bestie, first things first: this memo is informational 💅. It gives info to the Internet community and does NOT specify an Internet standard of any kind. Distribution of it is unlimited, so share away 🫶.
Copyright Notice 🌈
Copyright (C) The Internet Society (2004). All Rights Reserved. 🔒
IESG Note 💜
Okay, so the IESG (the folks who steer the IETF) wants to give a massive shoutout to the Joint Engineering Team (JET) 👏 for building mechanisms that let them enforce the policy they want. 😭 The Language Variant Table (LVT) mechanisms described here let JET enforce language-based preferences for character variants, and honestly they set a great example for anyone else who wants to use variant tables for their own policy enforcement 🔥.
The IESG encourages people to follow this example, and to take JET's diligence as inspiration, along with its technical work ✨. If you want to follow their lead, registration authorities may need to spell out their policy, come up with procedures and mechanisms for enforcing it, and document how the two fit together 📝. JET's LVT mechanism should be adaptable to different policies, and it can be considered during that development process 🦋.
One important reminder: the IETF does not dictate policy, and it doesn't require any particular mechanisms for putting these policies into practice 🙅♀️. Those are matters of sovereignty and contract, so that's not our call, bestie 💅.
Abstract 🌸
Getting internationalized access to domain names is seriously complicated 🙈. It's not just about the basic protocol design stuff, like how names get represented on the network, compared, and converted into the right forms. It also brings up issues and options for deployment, transition, registration, and administration 💀.
The IETF Standards for Internationalized Domain Names, known as "IDNA" 🌍, focus on accessing domain names in a range of scripts that's way broader than the original ASCII. During development, it became clear that characters with similar appearances and/or interpretations could cause confusion, and could make deployment and transition harder 😬. The conclusion was that, while those issues matter, they're best handled administratively rather than with restrictions baked into the protocols 🧠. This document defines a set of guidelines for applying restrictions of that type for Chinese, Japanese and Korean (CJK) scripts and the zones that use them 🎀. It might also be the beginning of a framework for thinking about other zones, languages, and scripts 🧚.
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions, Context, and Notation . . . . . . . . . . . . . . 5
2.1. Definitions and Context. . . . . . . . . . . . . . . . . 5
2.2. Notation for Ideographs and Other Non-ASCII CJK
Characters . . . . . . . . . . . . . . . . . . . . . . . 9
3. Scope of the Administrative Guidelines . . . . . . . . . . . . 9
3.1. Principles Underlying These Guidelines . . . . . . . . . 10
3.2. Registration of IDL. . . . . . . . . . . . . . . . . . . 13
3.2.1. Using the Language Variant Table . . . . . . . . 13
3.2.2. IDL Package. . . . . . . . . . . . . . . . . . . 14
3.2.3. Procedure for Registering IDLs . . . . . . . . . 14
3.3. Deletion and Transfer of IDL and IDL Package . . . . . . 19
3.4. Activation and Deactivation of IDL Variants . . . . . . 19
3.4.1. Activation Algorithm . . . . . . . . . . . . . . 19
3.4.2. Deactivation Algorithm . . . . . . . . . . . . . 20
3.5. Managing Changes in Language Associations. . . . . . . . 21
3.6. Managing Changes to Language Variant Tables. . . . . . . 21
4. Examples of Guideline Use in Zones . . . . . . . . . . . . . . 21
5. Syntax Description for the Language Variant Table. . . . . . . 25
5.1. ABNF Syntax. . . . . . . . . . . . . . . . . . . . . . . 25
5.2. Comments and Explanation of Syntax . . . . . . . . . . . 25
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 27
7. Index to Terminology . . . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . 30
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Authors' Addresses . . . . . . . . . . . . . . . . . . . 31
10.2. Editors' Addresses . . . . . . . . . . . . . . . . . . . 32
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 331. Introduction ✨
Okay so domain names are the fundamental naming architecture of the Internet 🌐. Like, countless Internet protocols and applications rely on them, not just for stability and continuity but also to avoid ambiguity 💅. They were designed to be identifiers with no language context at all 🤖. BUT, as domain names have become visible to end users through Web URLs and e-mail addresses, the strings in domain-name labels are increasingly being read as names, words, or phrases 👀. It's likely users will do the same thing with languages that use different character sets, like Chinese, Japanese and Korean (CJK), where lots of words or concepts are written with short sequences of characters 🎀.
The introduction of what are called Internationalized Domain Names (IDN) makes two things harder: putting names into identifiers, and the confusion that already exists between scripts and languages 😭. Characters that look identical (or actually are identical), or that have similar or identical meanings but are assigned different code points, make the confusion even worse 🙈. DNS internationalization also touches a bunch of Internet protocols and applications, and adds layers of complexity to technical administration and services 🧩. With a much broader range of characters than the original small ASCII subset, precautions are necessary when deploying IDNs, so that confusion and fraud get minimized 🚨.
The IETF IDN Working Group [IDN-WG] tackled how to encode and decode Unicode strings into and out of Domain Name System (DNS) labels 🧁. Their goal was that the solution would not put the operational DNS at any risk 🛡️. Their work produced one primary protocol and three supporting ones:
- Internationalizing Host Names in Applications [IDNA]
- Preparation of Internationalized Strings [STRINGPREP]
- A Stringprep Profile for Internationalized Domain Names [NAMEPREP]
- Punycode [PUNYCODE]
IDNA is the one that calls on the others 💖. It normalizes and transforms strings that are meant to be used as IDNs ✨. Together, the four provide the minimum functions needed for internationalization, like performing case mappings, eliminating character differences that would cause severe problems, and specifying matching (equality) 🔥. They also convert between the resulting Unicode code points and an ASCII-based form that's better suited for storing in actual DNS labels 🦋. So yeah, the IDNA transformations improve a user's chances of getting to the correct IDN 🎯.
Now, about those differing character sets: a big consideration and administrative challenge is region-specific definitions, interpretations, and the meaning of strings used in IDNs 🌏. A Unicode string can mean a specific name, word, or phrase in one language, but that meaning can vary depending on the country, region, culture, or other context where it's used 🤔. It can also have different interpretations in different languages that share some or all of the same characters 💅. So individual zones and zone administrators may find it necessary to impose restrictions and procedures, to reduce the likelihood of confusion and instability of reference within their own environments 🫶.
Over the centuries, CJK characters have evolved, and they're used differently across languages, and even across regions where the same language is spoken 🏯. That history gave rise to the idea of "variants", where one conceptual character can be identified with several different Code Points in character sets for computer use 🌸. This document provides a framework for handling such variants while minimizing the possibility of serious user confusion when obtaining or using domain names 🎀. BUT the concept of variants is complex and may require many layers of solutions 😵💫. This guideline offers only one of those solution components. It isn't sufficient by itself to solve the whole problem, even with zone-specific tables as described below 💀.
Also, because of local language and writing-system differences, it's impossible to create universally accepted definitions for which potential variants are the same and which aren't 🙃. It's even harder to define a technical algorithm that generates variants which are linguistically accurate, meaning the variant forms make as much sense in the language as the originally specified forms 📚. It's also possible that generated variants have no meaning in the associated language or languages 🤷♀️. The intention isn't to generate meaningful "words" 🙅♀️. The goal is to generate similar variants to be reserved 🔒. So even though the method described in this document may not always be linguistically accurate (and it doesn't need to be!), it increases the chances of getting the right variants, while accepting the inherent limitations of the DNS and the complexities of human language 🌈.
This document outlines a model of conventions for zones where labels containing CJK characters are to be registered, plus a system for implementing that model 🧚. It provides a mechanism that lets each zone define its own local rules for permitted characters and sequences, and for handling IDNs and their variants 💜.
The document is the product of the Joint Engineering Team (JET), a group made up of members of CNNIC, TWNIC, KRNIC, and JPNIC, along with other individual experts 👑. It offers guidelines for zone administrators, including but not limited to registry operators and registrars, and information for all domain name holders about administering domain names that contain characters drawn from Chinese, Japanese, and Korean scripts 🍓. Other language groups are encouraged to develop their own guidelines as needed, based on these guidelines if that's helpful 🦋.
2. Definitions, Context, and Notation 🔍
2.1. Definitions and Context 💅
This document uses a number of special terms 📖. In this section, the definitions and explanations are grouped by topic 🗂️. Some readers may prefer to skip over this material and come back to it when needed, perhaps via the index to terminology in section 7 💖.
2.1.1. IDN 🌸
Okay so "IDN" is lowkey the most confusing abbreviation ever 💀 because it can mean like eight different things. Here's the whole list:
- (a) as an abbreviation for "Internationalized Domain Name";
- (b) as a fully qualified domain name that contains at least one label with characters not appearing in ASCII, specifically not in the subset of ASCII recommended for domain names (the so-called "hostname" or "LDH" subset, see RFC1035 [STD13]);
- (c) as a label of a domain name that contains at least one character beyond ASCII;
- (d) as a Unicode string to be processed by Nameprep;
- (e) as a string that is an output from Nameprep;
- (f) as a string that is the result of processing through both Nameprep and conversion into Punycode;
- (g) as the abbreviation of an IDN (more properly, IDL) Package, in the terminology of this document;
- (h) as the abbreviation of the IETF IDN Working Group;
- (g) as the abbreviation of the ICANN IDN Committee; and
- (h) as standing for other IDN activities in other companies/organizations.
Because it's so messy, this document uses "IDN" as an abbreviation for Internationalized Domain Name and, specifically, in the second sense described in (b) above. ✨ For anything else, it uses "IDL," which you'll meet right below. 🦋
2.1.2. IDL 💜
IDL means Internationalized Domain Label, and this is the term the document actually runs on 🫶. The guideline is applied on a per-zone basis, one label at a time, so the more general "IDN" (or its equivalents) doesn't fit as well. The processing specifications may also be applied, in some zones, to ASCII characters, but only if those characters are specified as valid in a Language Variant Table (see below). So yeah, in some zones an IDL might contain or consist entirely of "LDH" characters 👀.
2.1.3. FQDN 🎀
FQDN stands for fully qualified domain name: a name that explicitly contains all of its labels, including a Top-Level Domain (TLD) name. Here, a TLD name is one whose label appears in a nameserver record in the root zone 👑. The term "Domain Name Label" refers to any label of a FQDN.
2.1.4. Registrations 🧚
"Registration" is the process where a potential domain name holder asks for a label to be placed in the DNS, either as an individual name within a domain or as a subdomain delegation from another domain name holder. If it works, the label or delegation records get placed in the relevant zone file. More specifically, they get "activated" or made "active," and extra IDLs may be reserved as part of an "IDL Package" (see below) ✨. The guidelines here are recommended for all zones, at any hierarchy level, where CJK characters are going to appear, and not just for domains at the first or second level 🌈.
2.1.5. RFC3066 🍓
RFC3066 is a system that's widely used across the Internet for coding and representing names of languages [RFC3066]. It's based on an International Organization for Standardization (ISO) standard for coding language names [ISO639], but it expands on that to give extra precision 🫶.
2.1.6. ISO/IEC 10646 💅
ISO/IEC 10646 is the international standard universal multiple-octet coded character set ("UCS") [IS10646]. Its Code Point definitions are identical to those of corresponding versions of the Unicode standard (more on that below), so the characters and their coding are often just called "Unicode characters" 🔥.
2.1.7. Unicode Character 🦋
"Unicode character" here means a character chosen from the Unicode Standard Version 3.2 [UNICODE] (and therefore from ISO/IEC 10646). In this document, characters are identified by their positions, which are called "Code Points." For example, U+12AB means the character at position 12AB (hexadecimal) in the Unicode 3.2 table. For characters in positions above FFFF, meaning ones that need more than sixteen bits to represent, a five to eight-character string is used. Like U+112AB is the character in position 12AB of plane 1 💖.
2.1.8. Unicode String 🌸
"Unicode string" refers to a string of Unicode characters. The Unicode string is identified by the sequence of its Unicode characters, no matter what encoding scheme is used 🙈.
2.1.9. CJK Characters 🇨🇳
CJK characters are characters commonly used in the Chinese, Japanese, or Korean languages. That includes, but isn't limited to, the ones defined in the Unicode Standard as ASCII (U+0020 to U+007F), Han ideographs (U+3400 to U+9FAF and U+20000 to U+2A6DF), Bopomofo (U+3100 to U+312F and U+31A0 to U+31BF), Kana (U+3040 to U+30FF), Jamo (U+1100 to 11FF and U+3130 to U+318F), Hangul (U+AC00 to U+D7AF and U+3130 to U+318F), and the respective compatibility forms 🌈. Which characters are actually permitted in a given zone gets specified in that zone's Language Variant Table(s) ✨.
2.1.10. Label String 💀
"Label string" is a generic term for a string of characters that's a candidate for registration in the DNS, or that same string once it's registered. A label string may or may not be valid under the rules of this specification, and it might even be invalid for IDNA use 🙅. The term "label," by itself, refers to a string that has been validated and may be formatted to appear in a DNS zone file 🫶.
2.1.11. Language Variant Table 💜
This is where the key mechanisms of the spec live. It uses a three-column table, called a Language Variant Table, for each language that's permitted to be registered in the zone 📚. The three columns are "Valid Code Point," "Preferred Variant," and "Character Variant," which get defined separately below. The Language Variant Tables are critical to the success of the guideline in this document. However, the principles for generating the tables aren't in scope here, so each registry should work them out separately (perhaps by adopting or adapting the work of some other registry) 🧠. In this document, "Table" and "Variant Table" are used as short forms for Language Variant Table 💅.
2.1.12. Valid Code Point 🎀
In a Language Variant Table, the Valid Code Point column is the list of Code Points permitted for that language. Any other Code Points, or any string containing them, will be rejected by this specification 🚫. This list shows up as the first column of the Language Variant Table.
2.1.13. Preferred Variant 👑
In a Language Variant Table, the Preferred Variant column is a list of Code Points that correspond to each Valid Code Point and provide possible substitutions for it. These substitutions are "preferred" in the sense that the variant labels generated with them are normally registered in the zone file, or "activated" ✨. The Preferred Code Points sit in column 2 of the Language Variant Table, and "Preferred Code Point" is used interchangeably with this term 🌸.
2.1.14. Character Variant 🦋
In a Language Variant Table, the Character Variant column is a second list of Code Points that correspond to each Valid Code Point and provide possible substitutions for it. Unlike Preferred Variants, substitutions based on Character Variants are normally reserved but not actually registered (or "activated") 🔒. Character Variants sit in column 3 of the Language Variant Table, and "Code Point Variants" is used interchangeably with this term 💜.
2.1.15. Preferred Variant Label 🍓
A Preferred Variant Label is a label generated by use of Preferred Variants (or Preferred Code Points) 💖.
2.1.16. Character Variant Label 🧚
A Character Variant Label is a label generated by use of Character Variants 🌈.
2.1.17. Zone Variant 🔥
A Zone Variant is a Preferred or Character Variant Label that's actually going to be entered (registered) into the DNS, meaning into the zone file for the relevant zone 🎯. Zone Variants are also called Zone Variant Labels or Active (or Activated) Labels ✨.
2.1.18. IDL Package 👑
An IDL Package is a collection of IDLs determined by these Guidelines. All labels in the package are "reserved," which means nobody other than the holder of the Package can register them 🔐. These reserved IDLs may be "activated," meaning they're actually entered into a zone file as a "Zone Variant." The IDL Package also identifies the language(s) associated with the registration process. The IDL and its variant labels form a single, atomic unit 💅.
2.2. Notation for Ideographs and Other Non-ASCII CJK Characters. 🀄
For clarity, especially in the examples, Han ideographs show up in several places in this document. But they don't appear in the ASCII version of the document 😭. So that readers of the ASCII version (and readers who aren't familiar with recognizing and distinguishing Chinese characters) can follow along, most uses of these characters are paired with both their Unicode Code Points and an "asterisk tag" with its corresponding Chinese Romanization [ISO7098]. The tone mark is represented by a number from 1 to 4 🎶. Those tags have no meaning outside this document. They're just a quick visual and reading reference that helps with the combinations and transformations of characters in the guideline and table excerpts 🫶.
3. Scope of the Administrative Guidelines ✨
Zone administrators are responsible for administering the domain name labels under their control 👩💻. An administrator might be in charge of a large zone, like a top-level domain (TLD) whether generic or country code, or a smaller one, like a typical second- or third-level domain. A large zone is often more complex than its smaller counterpart. But the actual technical administrative tasks (addition, deletion, delegation, and transfer of zones between domain name holders) are similar for all zones 🧁.
This document provides guidelines for how CJK characters should be handled within a zone, for how language issues should be considered and incorporated, and for how Domain Name Labels containing CJK characters should be administered (including registration, deletion, and transfer of labels) 💖.
Other IDN policies are outside the scope of this document too 🙅. That includes the creation of new top-level domains (TLDs), the cost structure for registrations, and how the processes described here get split between registrar and registry if the zone makes that distinction 💸.
Technical implementation issues aren't discussed here either 🛠️. For example, deciding which guidelines should be implemented as registry actions and which should be registrar actions is left to zone administrators, and it may differ from zone to zone 🌸.
3.1. Principles Underlying These Guidelines 💅✨
Okay bestie, so this part is basically the rulebook for how IDLs (Internationalized Domain Labels) are supposed to work 🎀. First up: whenever people fight over who owns a name (or really, a DNS label string), this doc just assumes "first-come, first-served" (FCFS) as the resolution policy 🙈. FCFS isn't even on the principles list below, which is kinda iconic of it. If your zone already has its own priority or "rights" policies, you can still use these guidelines by swapping every FCFS mention for your zone's policy 🦋. Some guidelines might not fit other rights-to-labels policies, and options like UDRP [UDRP] or mutual exclusion might barely touch the rest 💖.
(a) Some Unicode strings are pure identifiers, a mix of characters from loads of languages and scripts 🌈. But IDLs are likely to be "words" or "names" or "phrases" with a specific meaning in a language 📖. A zone might or might not require "meaning" as a registration criterion, but meaning could be a super useful tool for avoiding user confusion 🧚.
Each IDL to be registered should be associated administratively with one or more languages.
Language associations should either be predetermined by the zone administrator and applied to the entire zone, or be chosen by the registrants on a per-IDL basis. The per-IDL way may be necessary for some zones, but it makes administration harder and bumps up the likelihood of conflicts in variant forms 😭.
A zone might have multiple languages attached, or no language at all. Skipping language specification can open extra chances for user confusion, so it is NOT recommended 🙅♀️.
(b) Each language only uses a subset of Unicode characters 🍓. So if an IDL is associated with a language, it's not permitted to contain any Unicode character outside that language's valid subset 🚫.
Each IDL to be registered must be verified against the valid subset of Unicode for the language(s) associated with the IDL.
That subset is specified by the list of characters in the first column of the language and zone-specific tables, which we'll get to later 📋.
If the IDL fails this test for any of its associated languages, the IDL is not valid for registration. Rip 💀.
Okay but here's the tea: this verification isn't necessarily linguistically accurate 👀. Some languages have special rules, like restricting the order certain combinations of characters can show up in. So characters that are valid for the language (and therefore allowed by this spec) might still not form valid words or even strings in that language 🙃.
(c) When an IDL is associated with a language, it may have Character Variants that depend on that language, in addition to any Preferred Variants 🌸. These are potential sources of confusion with the Code Points in the original label string, so the labels generated from them should be unavailable to registrants of other names, words, or phrases 🔒.
During registration, all labels generated from the Character Variants for the associated language(s) of the IDL should be reserved.
IDL reservations of this type normally do not appear in the distributed DNS zone file. In other words, these reserved IDLs may not resolve 🫥. Domain name holders could request that these reserved IDLs be placed in the zone file and made active and resolvable ✨.
Zones will need local policies about how they get made active 📜. Specifically, many zones (especially at the top level) have prohibited or restricted the use of "CNAME"s DNS aliases, especially CNAMEs that point to nameserver delegation records (NS records) 🚧. Also, long-term use of long-term aliases for domain hierarchies, rather than single names ("DNAME records"), is considered problematic because of the recursion they can introduce into DNS lookups 🌀. Not a vibe.
(d) When an IDL is a "name", "word", or "phrase", it will have Character Variants depending on the associated language 🎀. Plot twist: one or more of those Character Variants will get used way more than the others, for linguistic, political, or other reasons 👑.
These more commonly used variants are distinguished from ordinary Character Variants and are known as Preferred Variant(s) for the particular language 💖.
To increase the likelihood of correct and predictable resolution of the IDN by end users, all labels generated from the Preferred Variants for the associated language(s) should be resolvable 🦋.
In other words, the Preferred Variant Labels should appear in the distributed DNS zone file 🧚♀️.
(e) IDLs associated with one or more languages may have a huge number of Character Variant Labels or Preferred Variant Labels 😵💫. Some of those labels may include combinations of characters that are meaningless or invalid linguistically 🙈. So it may be appropriate for a zone to adopt procedures that include only linguistically acceptable labels in the IDL Package 🫶.
A zone administrator may impose additional rules and other processing to limit the number of Character Variant Labels or Preferred Variant Labels that are actually reserved or registered 🧹.
These extra rules and processing are based on policies and/or procedures imposed per zone, so they are not within the scope of this document 🤷♀️. Such policies might restrict the number of Preferred Variant Labels actually reserved, or prevent certain words from being registered at all 🚫.
(f) Some Character Variant Labels and Preferred Variant Labels are associated with each IDL 💜. These labels are considered "equivalent" to each another, so to avoid confusion, they all should be assigned to a single domain name holder 🫂.
The IDL and its variant labels should be grouped together into a single atomic unit, known in this document as an "IDL Package" 📦.
The IDL Package is created upon registration and is atomic. Transfer and deletion of an IDL is performed on the IDL Package as a whole. An IDL within the IDL Package may not be transferred or deleted individually. Any re-registration, transfers, or other actions that impact the IDL should also affect the other variants 🔁.
Heads up: the name-conflict resolution policy for this zone could clash with the principle of IDL Package atomicity 😬. If that happens, the policy must be defined to make the precedence clear ⭐.
3.2. Registration of IDL 🧚
To conform to the principles described in 3.1, this document introduces two concepts: the Language Variant Table and the IDL Package 🌈. These are described in the next two subsections, followed by a description of the algorithm used to interpret the table and generate variant labels 🎀.
3.2.1. Using the Language Variant Table 📋
For each zone that uses a given language, each language should have its own Language Variant Table 🍓. The table has a header section that identifies references and version information, followed by a section with one row for each Code Point that is valid for the language, across three columns 💅.
- (1) The first column contains the subset of Unicode characters that is valid to be registered ("Valid Code Point") 🔍. This is used to verify the IDL to be registered (see 3.1b). As in the registration procedure described later, this column works as an index to examine characters that appear in a proposed IDL to be processed 🧐. The collection of Valid Code Points in the table for a particular language can be thought of as defining the script for that language, although the normal definition of a script would not include, for example, ASCII characters with CJK ones 🀄.
- (2) The second column contains the Preferred Variant(s) of the corresponding Unicode character in column one ("Valid Code Point") 👑. These variant characters are used to generate the Preferred Variant Labels for the IDL, and those labels should be resolvable (see 3.1d) ✨. Under normal circumstances, all of those Preferred Variant Labels will be activated in the relevant zone file, so they'll resolve when the DNS is queried for them 🦋.
- (3) The third column contains the Character Variant(s) for the corresponding Valid Code Point 🫧. These are used to generate the Character Variant Labels of the IDL, which are then to be reserved (see 3.1c) 🔒. Registration, or activation, of labels generated from Character Variants will normally be a registrant decision, subject to local policy 🙋♀️.
Each entry in a column consists of one or more Code Points, expressed as a numeric character number in the Unicode table and optionally followed by a parenthetical reference 🔢. The first column (Valid Code Point) may have only one Code Point specified in a given row, but the other columns may have more than one 🌸.
Any row may be terminated with an optional comment, starting with "#" 💬.
The formal syntax of the table and more-precise definitions of some of its organization appear in Section 5 🧾.
The Language Variant Table should be provided by a relevant group, organization, or body 🏛️. However, who is relevant or has the authority to create this table (and the rules that define it) is beyond the scope of this document 🤐.
3.2.2. IDL Package 📦✨
The IDL Package is created on successful registration and consists of:
- the IDL registered 💖
- the language(s) associated with the IDL 🌍
- the version of the associated character variant table 🔖
- the reserved IDLs 🔒
- active IDLs, that is, "Zone Variant Labels" that are to appear in the DNS zone file 🚀
3.2.3. Procedure for Registering IDLs 📋
okay so this is the step-by-step recipe for registering an IDL, and each step gets a little explanation after it 💅 (the original says the same thing, I'm just being extra about it).
Step 1. IN <= IDL to be registered and
{L} <= Set of languages associated with INStart the process with the label string (prospective IDL) you want to register, plus the language(s) it's associated with. That's your input, bestie 🫶
Step 2. Generate the Nameprep-processed version of the IN,
applying all mappings and canonicalization required by
IDNA.The prospective IDL gets run through Nameprep to apply the normalizations and exclusions that are globally required to use IDNA ✨ If Nameprep processing fails, then the IDL is invalid and the registration process must stop 💀 no cap, it's over at that point.
Step 2.1. NP(IN) <= Nameprep processed IN
Step 2.2. Check availability of NP(IN). If not available, route to
conflict policy.Next up, the Nameprep-processed IDL gets checked against the zone file and any IDL Packages that already exist 👀 If it's already registered or reserved, that's a conflict, and it has to be resolved using whatever policy applies to the zone. For example, if FCFS is used, the registration process terminates unless the conflict resolution policy gives another option 🙈
Step 3. Process each language.
For each language (AL) in {L}Step 3 goes through every language associated with the proposed IDL. It checks each character (after Nameprep has been applied) for validity in each of those languages, and then applies the Preferred Variants (column 2 values) and the Character Variants (column 3 values) to generate candidate labels 🦋
Step 3.1. Check validity of NP(IN) in AL. If failed, stop
processing.In step 3.1, the IDL gets validated by checking that every Code Point in the Nameprep-processed IDL is allowed by the "Valid Code Point" column of the Character Variant Table for the language. This gets repeated for any other languages (and therefore any other Language Variant Tables) specified in the registration 🌸 If one or more Code Points aren't valid, the registration process terminates.
Step 3.2. PV(IN,AL) <= Set of available Nameprep-processed Preferred
Variants of NP(IN) in ALStep 3.2 generates the list of Preferred Variant Labels for the IDL. It does this by combining (see Step 3.2A below) all the possible variants listed in the "Preferred Variant(s)" column for each Code Point in the Nameprep-processed IDL 🧚 The generated Preferred Variant Labels must be processed through Nameprep. If Nameprep processing fails for any Preferred Variant Label (this is unlikely to happen if the Preferred Variants were run through Nameprep before going into the table), then that variant label gets removed from the list. The remaining Preferred Variant Labels are then checked to see whether they're already registered or reserved. If any are, the conflict resolution policy applies. In general, this won't stop the originally requested IDL from being registered, unless the policy prevents that registration. For example, if FCFS is applied, the conflicting variants get removed from the list, but the originally requested IDL and any remaining variants will be registered (see steps 5 and 8 below) 💖
Step 3.2A Generating variant labels from Variant Code Points.Okay, this part is the main character moment 👑 Steps 3.2 and 3.3 both need the Preferred Variants and Character Variants combined with the original IDL to form sets of variant labels. Conceptually, you start with the original, Nameprep-processed, IDL and look at each of its characters in turn. If a character has a matching Preferred Variant or Character Variant, a new variant label is produced with the Variant Code Point swapped in for the original one. If variant labels already exist from processing characters that showed up earlier in the original IDL, the substitutions get made in those too, which gives you even more generated variant labels 🌈 This operation is repeated separately for the Preferred Variants (in Step 3.2) and the Character Variants (in Step 3.3). Of course, you could get equivalent results by processing the original IDL's characters in order and building the Preferred Variant Label set and the Character Variant Label set side by side 🎀
This process can sometimes generate a huge number of labels 😭 For example, say only two of the characters in the original IDL have Preferred Variants, and the first of those characters has three Preferred Variants while the second has two. Then you end up with 12 variant labels to be placed in the IDL Package and, normally, in the zone file. Repeating the process for Character Variants, if any exist, would increase the number of labels even more. And if more than one language is specified for the original IDL, then repeating the process for additional languages (see step 4, below) could increase the size of the set even further 💅
For illustrative purposes, the "combination" process could be achieved by a recursive function similar to the following pseudocode:
Function Combination(Str)
F <= first codepoint of Str
SStr <= Substring of Str, without the first code point
NSC <= {}
If SStr is empty then
for each V in (Variants of code point F)
NSC = NSC set-union (the string with the code point V)
End of Loop
Else
SubCom = Combination(SStr)
For each V in (Variants of code point F)
For each SC in SubCom
NSC = NSC set-union (the string with the
first code point V followed by the string SC)
End of Loop
End of Loop
Endif
Return NSCStep 3.3. CV(IN,AL) <= Set of available Nameprep-processed Character
Variants of NP(IN) in ALThis step generates the list of Character Variant Labels by combining (see Step 3.2A above) all the possible variants listed in the "Character Variant(s)" column for each Code Point in the Nameprep-processed original IDL ✨ Just like with the Preferred Variant Labels, the generated Character Variant Labels must be processed by Nameprep and be acceptable to it. If Nameprep processing fails for a Character Variant Label, that variant label gets removed from the list. The remaining Character Variant Labels are then checked to make sure they're not registered or reserved. If one or more are, the conflict resolution policy gets applied. As with Preferred Variant Labels, a conflict that gets resolved in favor of the earlier registrant doesn't, in general, stop the IDL from being registered, or stop the remaining variants from being reserved in step 6 below 🦋
Step 3.4. End of LoopStep 4. Let PVall be the set-union of all PV(IN,AL)Step 4 generates the Preferred Variants Label for all languages. In this step, and again in step 6 below, the zone administrator can impose additional rules and processing activities to limit the number of Preferred Label Variants (tentatively to be reserved and activated) and Character Label Variants (tentatively to be reserved). These additional rules and processing activities are specific to each zone's policy, so this document doesn't specify them 🔥
Step 5. {ZV} <= PVall set-union NP(IN)Step 5 generates the initial Zone Variants. The set includes all Preferred Variants for all languages, plus the original Nameprep-processed IDL. Unless further processing excludes them, these Zone Variants get activated, which means they're placed into the DNS zone 🌸 Note that the "set-union" operation eliminates any duplicates, so no double-dipping 💜
Step 6. Let CVall be the set-union of all CV(IN,AL), set-minus
{ZV}Step 6 generates the Reserved Label Variants (the Character Variant Label set). These labels are normally reserved but not activated. The set includes all Character Variant Labels for all languages, but not the Zone Variants from the previous step. The set-union and set-minus operations eliminate any duplicates 🫧
Step 7. Create IDL Package for IN using IN, {L}, {ZV} and CVallIn Step 7, the "IDL Package" gets created using the original IDL, its associated language(s), the Zone Variant Labels, and the Reserved Variant Labels 🧁 If zone-specific additional processing or filtering is going to be applied to remove linguistically inappropriate or other forms, it should happen before the IDL Package is actually assembled.
Step 8. Put {ZV} into zone fileThe activated IDLs get converted via ToASCII with UseSTD13ASCIIRules [IDNA] before they go into the zone file 💫 This conversion turns the IDLs into the actual IDNA ("Punycode") form used in zone files. Up until this point they've been carried around in Unicode form. If ToASCII fails for any of the activated IDLs, that IDL must not be placed into the zone file. And if the IDL is a subdomain name, it will be delegated 🎀
3.3. Deletion and Transfer of IDL and IDL Package 🗂️
In traditional domain administration, every Domain Name Label is independent of every other Domain Name Label. Registration, deletion, and transfer happen on a per-label basis 🙃 But with these guidelines, each IDL is tied to specific languages, and all of its label variants, both active (zone) and reserved, live together in an IDL Package. This is very deliberately meant to rule out labels that mix enough characters from different scripts that they couldn't work as words in any given language 🚫 If a zone decides not to impose that restriction, meaning it lets labels be built by picking characters from several different languages and scripts, then the guidelines described here wouldn't be appropriate for it.
As stated earlier, the IDL package should be treated as a single atomic unit, and all variants of the IDL should belong to a single domain-name holder 🫶 If the local policy for handling disagreements requires a particular IDL to be transferred and deleted independently of the IDL Package, the conflict policy takes precedence. In that case, the conflict policy should include a transfer or delete procedure that takes the nature of IDL Packages into account 👑
When an IDL Package is deleted, all of its Zone and Reserved Label Variants become available again 🌈 Deleting one IDL Package doesn't change any other IDL Packages ✨
3.4. Activation and Deactivation of IDL variants 🔁
Because an IDL package contains both active (registered) IDLs and inactive (reserved but not registered) IDLs, there need to be processes for activating or deactivating IDL variants within an IDL Package 💜
3.4.1. Activation Algorithm 🎀
Okay bestie, activation is basically a recipe, so let's walk through it step by step 📝
Step 1. Start with IN <= IDL to be activated and PA <= IDL Package. So you grab the IDL you want to activate and the IDL Package it belongs to ✨
Step 2. NP(IN) <= Nameprep processed IN. Run the IDL through Nameprep. This step should never cause a problem, or even a change, since every label that becomes part of the IDL Package already got Nameprep-processed in Step 3.2 or 3.3 of the Registration procedure (section 3.2.3) 🧼
Step 3. If NP(IN) not in CVall then stop. Check that the Nameprep-processed version of the IDL shows up as a still-unactivated label in the IDL Package, which means the list of Reserved Label Variants, CVall. If it isn't there, you stop right there. It might be a useful "sanity check" to also make sure it's not already in the zone file 🙈
Step 4. CVall <= CVall set-minus NP(IN) and {ZV} <= {ZV} set-union NP(IN). Inside the IDL Package, the Nameprep-processed version gets removed from the Reserved Label Variants and added to the list of active (zone) label variants. Glow up! 🦋
Step 5. Put {ZV} into the zone file. This is where you actually register (activate) the Zone Variant Labels 🚀
3.4.2. Deactivation Algorithm 🍓
Deactivation is basically activation in reverse, and it's just as iconic 💜
Step 1. Start with IN <= IDL to be deactivated and PA <= IDL Package. Same as before: the IDL you're deactivating, plus the IDL Package it lives in ✨
Step 2. NP(IN) <= Nameprep processed IN. Get the Nameprep-processed version of the name. (See the discussion in the previous section, bestie 🫶)
Step 3. If NP(IN) not in {ZV} then stop. Verify that the Nameprep-processed version of the IDL shows up as an activated (zone) label variant in the IDL Package. Again, it might be a useful "sanity check" to also confirm that it actually appears in the zone file 👀
Step 4. CVall <= CVall set-union NP(IN) and {ZV} <= {ZV} set-minus NP(IN). Inside the IDL Package, the Nameprep-processed version gets removed from the list of Active (Zone) Label Variants and added to the list of Reserved (but inactive) Label Variants. It's giving "back to the bench" energy 🌸
Step 5. Put {ZV} into the zone file. Update the zone file so the change actually takes effect 🧚
3.5. Managing Changes in Language Associations 💅
Okay, so the IDL Package is an atomic unit, and its list of variants can't be changed after it's created. Because of that, this document doesn't have a way to add or delete language associations inside an IDL Package. Instead, it recommends deleting the whole IDL Package and then registering it again with the new set of languages. Zone administrators may find it desirable to come up with procedures that stop other parties from grabbing the labels in the IDL Package during these operations. That's a whole vibe check, honestly 🕵️♀️
3.6. Managing Changes to the Language Variant Tables 🌈
Language Variant Tables can change over time, and those changes may or may not be backward compatible. It's possible that updated tables will produce a different set of Preferred Variants and Reserved Variants 🔄
To keep the IDL Package atomic, when a Language Variant Table changes, IDL Packages that were created using the previous version of the table must not be updated or affected. Hands off the old ones, periodt 🙅♀️💖
4. Examples of Guideline Use in Zones 🧁
Okay, so to give you some real examples, we need some Language Variant Tables. For the purpose of these examples, assume the following four Language Variant Tables are defined:
Note: these tables are not a representation of the actual tables, and they do not contain sufficient entries to be used in any actual implementation. IANA maintains a voluntary registry of actual tables [IANA-LVTABLES] which may be consulted for complete examples.
a) Language Variant Table for zh-cn and zh-sg
Reference 1 CP936 (commonly known as GBK)
Reference 2 zVariant, zTradVariant, zSimpVariant in Unihan.txt [UNIHAN]
Reference 3 List of Simplified character Table (Simplified column)
Reference 4 zSimpVariant in Unihan.txt [UNIHAN]
Reference 5 variant that exists in GB2312, common simplified hanzi
Version 1 20020701 # July 2002
56E2(1);56E2(5);5718(2) # sphere, ball, circle; mass, lump
5718(1);56E2(4);56E2(2),56E3(2) # sphere, ball, circle; mass, lump
60F3(1);60F3(5); # think, speculate, plan, consider
654E(1);6559(5);6559(2) # teach
6559(1);6559(5);654E(2) # teach, class
6DF8(1);6E05(5);6E05(2) # clear
6E05(1);6E05(5);6DF8(2) # clear, pure, clean; peaceful
771E(1);771F(5);771F(2) # real, actual, true, genuine
771F(1);771F(5);771E(2) # real, actual, true, genuine
8054(1);8054(3);806F(2) # connect, join; associate, ally
806F(1);8054(3);8054(2),8068(2) # connect, join; associate, ally
96C6(1);96C6(5); # assemble, collect togetherb) Language Variant Table for zh-tw
Reference 1 CP950 (commonly known as BIG5)
Reference 2 zVariant, zTradVariant, zSimpVariant in Unihan.txt
Reference 3 List of Simplified Character Table (Traditional column)
Reference 4 zTradVariant in Unihan.txt
Version 1 20020701 # July 2002
5718(1);5718(4);56E2(2),56E3(2) # sphere, ball, circle; mass, lump
60F3(1);60F3(1); # think, speculate, plan, consider
6559(1);6559(1);654E(2) # teach, class
6E05(1);6E05(1);6DF8(2) # clear, pure, clean; peaceful
771F(1);771F(1);771E(2) # real, actual, true, genuine
806F(1);806F(3);8054(2),8068(2) # connect, join; associate, ally
96C6(1);96C6(1); # assemble, collect togetherc) Language Variant Table for ja
Reference 1 CP932 (commonly known as Shift-JIS)
Reference 2 zVariant in Unihan.txt
Reference 3 variant that exists in JIS X0208, commonly used Kanji
Version 1 20020701 # July 2002
5718(1);5718(3);56E3(2) # sphere, ball, circle; mass, lump
60F3(1);60F3(3); # think, speculate, plan, consider
654E(1);6559(3);6559(2) # teach
6559(1);6559(3);654E(2) # teach, class
6DF8(1);6E05(3);6E05(2) # clear
6E05(1);6E05(3);6DF8(2) # clear, pure, clean; peaceful
771E(1);771E(1);771F(2) # real, actual, true, genuine
771F(1);771F(1);771E(2) # real, actual, true, genuine
806F(1);806F(1);8068(2) # connect, join; associate, ally
96C6(1);96C6(3); # assemble, collect togetherd) Language Variant Table for ko
Reference 1 CP949 (commonly known as EUC-KR)
Reference 2 zVariant and K-source in Unihan.txt
Version 1 20020701 # July 2002
5718(1);5718(1);56E3(2) # sphere, ball, circle; mass, lump
60F3(1);60F3(1); # think, speculate, plan, consider
654E(1);654E(1);6559(2) # teach
6DF8(1);6DF8(1);6E05(2) # clear
771E(1);771E(1);771F(2) # real, actual, true, genuine
806F(1);806F(1);8068(2) # connect, join; associate, ally
96C6(1);96C6(1); # assemble, collect togetherNow for the fun part, the examples! 🎉
Example 1 🌟
IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
{L} = {zh-cn, zh-sg, zh-tw}
NP(IN) = (U+6E05 U+771F U+6559)
PV(IN,zh-cn) = (U+6E05 U+771F U+6559)
PV(IN,zh-sg) = (U+6E05 U+771F U+6559)
PV(IN,zh-tw) = (U+6E05 U+771F U+6559)
{ZV} = {(U+6E05 U+771F U+6559)}
CVall = {(U+6E05 U+771E U+6559),
(U+6E05 U+771E U+654E),
(U+6E05 U+771F U+654E),
(U+6DF8 U+771E U+6559),
(U+6DF8 U+771E U+654E),
(U+6DF8 U+771F U+6559),
(U+6DF8 U+771F U+654E)}Example 2 🌸
IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
{L} = {ja}
NP(IN) = (U+6E05 U+771F U+6559)
PV(IN,ja) = (U+6E05 U+771F U+6559)
{ZV} = {(U+6E05 U+771F U+6559)}
CVall = {(U+6E05 U+771E U+6559),
(U+6E05 U+771E U+654E),
(U+6E05 U+771F U+654E),
(U+6DF8 U+771E U+6559),
(U+6DF8 U+771E U+654E),
(U+6DF8 U+771F U+6559),
(U+6DF8 U+771F U+654E)}Example 3 🙈
IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
{L} = {zh-cn, zh-sg, zh-tw, ja, ko}
NP(IN) = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
Invalid registration because U+6E05 is invalid in L = koExample 4 🦋
IDL = (U+806F U+60F3 U+96C6 U+5718)
*lian2 xiang3 ji2 tuan2*
{L} = {zh-cn, zh-sg, zh-tw}
NP(IN) = (U+806F U+60F3 U+96C6 U+5718)
PV(IN,zh-cn) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-sg) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-tw) = (U+806F U+60F3 U+96C6 U+5718)
{ZV} = {(U+8054 U+60F3 U+96C6 U+56E2),
(U+806F U+60F3 U+96C6 U+5718)}
CVall = {(U+8054 U+60F3 U+96C6 U+56E3),
(U+8054 U+60F3 U+96C6 U+5718),
(U+806F U+60F3 U+96C6 U+56E2),
(U+806f U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+56E2),
(U+8068 U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+5718)Example 5 💜
IDL = (U+8054 U+60F3 U+96C6 U+56E2)
*lian2 xiang3 ji2 tuan2*
{L} = {zh-cn, zh-sg}
NP(IN) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-cn) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-sg) = (U+8054 U+60F3 U+96C6 U+56E2)
{ZV} = {(U+8054 U+60F3 U+96C6 U+56E2)}
CVall = {(U+8054 U+60F3 U+96C6 U+56E3),
(U+8054 U+60F3 U+96C6 U+5718),
(U+806F U+60F3 U+96C6 U+56E2),
(U+806f U+60F3 U+96C6 U+56E3),
(U+806F U+60F3 U+96C6 U+5718),
(U+8068 U+60F3 U+96C6 U+56E2),
(U+8068 U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+5718)}Example 6 ❌
IDL = (U+8054 U+60F3 U+96C6 U+56E2)
*lian2 xiang3 ji2 tuan2*
{L} = {zh-cn, zh-sg, zh-tw}
NP(IN) = (U+8054 U+60F3 U+96C6 U+56E2)
Invalid registration because U+8054 is invalid in L = zh-twExample 7 👑
IDL = (U+806F U+60F3 U+96C6 U+5718)
*lian2 xiang3 ji2 tuan2*
{L} = {ja,ko}
NP(IN) = (U+806F U+60F3 U+96C6 U+5718)
PV(IN,ja) = (U+806F U+60F3 U+96C6 U+5718)
PV(IN,ko) = (U+806F U+60F3 U+96C6 U+5718)
{ZV} = {(U+806F U+60F3 U+96C6 U+5718)}
CVall = {(U+806F U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+5718),
(U+8068 U+60F3 U+96C6 U+56E3)}5. Syntax Description for the Language Variant Table 🧠
The formal syntax for the Language Variant Table is written in the IETF "ABNF" metalanguage [ABNF]. Some comments on the syntax appear right after it, so keep reading 👀
5.1. ABNF Syntax ✨
LanguageVariantTable = 1*ReferenceLine VersionLine 1*EntryLine
ReferenceLine = "Reference" SP RefNo SP RefDesciption [ Comment ] CRLF
RefNo = 1*DIGIT
RefDesciption = *[VCHAR]
VersionLine = "Version" SP VersionNo SP VersionDate [ Comment ] CRLF
VersionNo = 1*DIGIT
VersionDate = YYYYMMDD
EntryLine = VariantEntry/Comment CRLF
VariantEntry = ValidCodePoint ";"
PreferredVariant ";" CharacterVariant [ Comment ]
ValidCodePoint = CodePoint
RefList = RefNo 0*( "," RefNo )
PreferredVariant = CodePointSet 0*( "," CodePointSet )
CharacterVariant = CodePointSet 0*( "," CodePointSet )
CodePointSet = CodePoint 0*( SP CodePoint )
CodePoint = 4*8DIGIT [ "(" Reflist ")" ]
Comment = "#" *VCHARYYYYMMDD is an integer, written in alphabetic form, that represents a date. YYYY is the 4-digit year, MM is the 2-digit month, and DD is the 2-digit day. So 20020701 is July 1, 2002, and that's the vibe we're going for 📅💖
5.2. Comments and Explanation of Syntax ✨
okay so anything that starts with "#", or comes after it on a line, is a comment 💬 Comments don't matter at all when the tables get processed, and there are zero rules for what you put between the # and the end of the line 🙈 Blank lines in the tables get ignored completely, so go wild with spacing 🫶
Every language should have its own Language Variant Table 🌸 A relevant group, organization, or other body makes it, and it's usually based on some established standard or standards. The group that makes the table should list its references at the very top, each one tagged with the word "Reference", then an integer (the reference number), then the description. Like this:
Reference 1 CP936 (commonly known as GBK)
Reference 2 zVariant, zTradVariant, zSimpVariant in Unihan.txt
Reference 3 List of Simplified Character Table (Simplified column)
Reference 4 zSimpVariant in Unihan.txt
Reference 5 Variant that exists in GB2312, common simplified HanziEvery table also needs a version number and a release date 📅 That's the word "Version", then an integer, then the date in the format YYYYMMDD. YYYY is the 4-digit year, MM is the 2-digit month, and DD is the 2-digit day of the table's publication date. Example:
Version 1 20020701 # July 2002 Version 1The table has three columns separated by semicolons: "Valid Code Point"; "Preferred Variant(s)"; and "Character Variant(s)" 💖
The "Valid Code Point" is the subset of Unicode characters that are allowed to be registered. Main character energy 👑
There can be more than one Preferred Variant, so the "Preferred Variant(s)" column can hold multiple entries 🦋 If that column is empty, there's no matching Preferred Variant. The Preferred Variant is null, there's no corresponding preferred variant code point, and no processing happens to add labels for preferred variants." Unless local policy says otherwise, the steps above only end up with the labels that match the valid code point being activated (registered) into the zone file 🍓
The "Character Variant(s)" column has every Character Variant of the Code Point 💅 A Code Point is always a variant of itself, so to avoid repeating stuff, it's assumed to be part of "Character Variant(s)" and you don't need to write it there again 🧚
If a variant in either "Preferred Variant(s)" or "Character Variant(s)" is a sequence of Code Points, you list them separated by a space ✨ If there are several variants in either column, each one gets separated by a comma 🌈
Any Code Point in the "Preferred Variant(s)" column must be allowed by the rules for the relevant language before it can be registered 🔥 This isn't a requirement for the "Character Variant(s)" entries though. Some of those might not be allowed to be registered at all, and that's fine 💀
Every Code Point in the table should have a reference number (matching the references) to back up the entry 📚 You put the reference number in parentheses after the Code Point. If there's more than one reference, the numbers all go inside a single set of parentheses, separated by commas 🎀
6. Security Considerations 🚨
okay bestie, this part is SERIOUS 😭 As we talked about in the Introduction, letting people use basically anything they want in international (non-ASCII) characters inside domain name labels can confuse users and invite all kinds of attacks 💀 With CJK languages especially, an attacker can sneakily divert or confuse people, because different characters (or, more specifically, assigned code points) can have the same or super similar meanings 🙈
These Guidelines help a bit with those risks. They give us a framework for blocking inappropriate characters from being registered at all, and for letting "variant" characters get grouped together and reserved, so they can only be registered in the DNS by the same owner 🫶 But the system here is no better or worse than the per-zone and per-language tables this document describes how to format and use 🍓 Specific tables and any extra local processing will reflect each zone's choices about balancing risk against flexibility in registrations ⚖️ And of course, if those tables are built wrong, the protection can get a LOT weaker 😭🔥
7. Index to Terminology 📖
As a little favor to the reader, this section lists all the special terminology used in this document, with a pointer to the section where each term is defined 🧚
Activated Label 2.1.17
Activation 2.1.4
Active Label 2.1.17
Character Variant 2.1.14
Character Variant Label 2.1.16
CJK Characters 2.1.9
Code point 2.1.7
Code Point Variant 2.1.14
FQDN 2.1.3
Hostname 2.1.1
IDL 2.1.2
IDL Package 2.1.18
IDN 2.1.1
Internationalized Domain Label 2.1.2
ISO/IEC 10646 2.1.6
Label String 2.1.10
Language name codes 2.1.5
Language Variant Table 2.1.11
LDH Subset 2.1.1
Preferred Code Point 2.1.13
Preferred Variant 2.1.13
Preferred Variant Label 2.1.15
Registration 2.1.4
Reserved 2.1.18
RFC3066 2.1.5
Table 2.1.11
UCS 2.1.6
Unicode Character 2.1.7
Unicode String 2.1.8
Valid Code Point 2.1.12
Variant Table 2.1.11
Zone Variant 2.1.178. Acknowledgments 🫶
The authors gave a huge thank-you to these amazing people 💜
- V. CHEN, N. HSU, H. HOTTA, S. TASHIRO, Y. YONEYA, and the other Joint Engineering Team members at the JET meeting in Bangkok, Thailand 🌸
- Yves Arrouye, an observer at the JET meeting in Bangkok, for his contribution on the IDL Package 🦋
- Everyone who commented on and suggested things for earlier versions, including Harald ALVESTRAND, Erin CHEN, Patrik FALTSTROM, Paul HOFFMAN, Soobok LEE, LEE Xiaodong, MAO Wei, Erik NORDMARK, and L.M. TSENG 👑
9. References 📚
9.1. Normative References
[ABNF] Crocker, D. and P. Overell, Eds., "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, November
1997.
[STD13] Mockapetris, P., "Domain names concepts and
facilities" STD 13, RFC 1034, November 1987.
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.
[IDNA] Faltstrom, P., Hoffman, P. and A. M. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[PUNYCODE] Costello, A.M., "Punycode: A Bootstring encoding of
Unicode for Internationalized Domain Names in
Applications (IDNA)", RFC 3492, March 2003.
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)",
RFC 3491, March 2003.
[IS10646] A product of ISO/IEC JTC1/SC2/WG2, Work Item
JTC1.02.18 (ISO/IEC 10646). It is a multipart
standard: Part 1, published as ISO/IEC 10646-
1:2000(E), covers the Architecture and Basic
Multilingual Plane, and Part 2, published as ISO/IEC
10646-2:2001(E), covers the supplementary
(additional) planes.
[UNIHAN] Unicode Han Database, Unicode Consortium
ftp://ftp.unicode.org/Public/UNIDATA/Unihan.txt.
[UNICODE] The Unicode Consortium, "The Unicode Standard Version
3.0," ISBN 0-201-61633-5. Unicode Standard Annex #28
(http://www.unicode.org/unicode/reports/tr28/)
defines Version 3.2 of the Unicode Standard, which is
definitive for IDNA and this document.
[ISO7098] ISO 7098;1991 Information and documentation
Romanization of Chinese, ISO/TC46/SC2.9.2. Informative References
[IANA-LVTABLES] Internet Assigned Numbers Authority (IANA), IDN
Character Registry.
http://www.iana.org/assignments/idn/
[IDN-WG] IETF Internationalized Domain Names Working Group,
now concluded,idn@ops.ietf.org, James Seng, Marc
Blanchet, co-chairs, http://www.i-d-n.net/.
[UDRP] ICANN, "Uniform Domain Name Dispute Resolution
Policy", October 1999,
http://www.icann.org/udrp/udrp-policy-24oct99.htm
[ISO639] "ISO 639:1988 (E/F) Code for the representation of names
of languages", International Organization for
Standardization, 1st edition, 1988-04-01.10. Contributors 🌈
So the formal responsibility for this document and its ideas belongs to K. Koniski, K. Huang, H. Qian, and Y. Ko 👑 They're listed on the first page as the authors of record, and they're the right long-term contacts for questions and comments on this RFC 💅 J. Seng, J. Klensin, and W. Rickard were the editors. They turned the ideas of those four authors, and the teams they represented, into the written form you see now 🧚 They were the main contacts during editing, but not in the long term ✨
10.1. Authors' Addresses
Kazunori KONISHI
JPNIC
Kokusai-Kougyou-Kanda Bldg 6F
2-3-4 Uchi-Kanda, Chiyoda-ku
Tokyo 101-0047
Japan
Phone: +81 49-278-7313
EMail: konishi@jp.apan.net
Kenny HUANG
TWNIC
3F, 16, Kang Hwa Street, Taipei
Taiwan
Phone: 886-2-2658-6510
EMail: huangk@alum.sinica.edu
QIAN Hualin
CNNIC
No.6 Branch-box of No.349 Mailbox, Beijing 100080
Peoples Republic of China
EMail: Hlqian@cnnic.net.cn
KO YangWoo
PeaceNet
Yangchun P.O. Box 81 Seoul 158-600
Korea
EMail: yw@mrko.pe.kr10.2. Editors' Addresses
James SENG
180 Lompang Road
#22-07 Singapore 670180
Phone: +65 9638-7085
EMail: jseng@pobox.org.sg
John C KLENSIN
1770 Massachusetts Avenue, No. 322
Cambridge, MA 02140
U.S.A.
EMail: Klensin+ietf@jck.com
Wendy RICKARD
The Rickard Group
16 Seminary Ave
Hopewell, NJ 08525
USA
EMail: rickard@rickardgroup.com11. Full Copyright Statement 💅🎀
okay so this part is the legal stuff 📜 but it's still important bestie! The Copyright (C) The Internet Society (2004) owns the copyright. This document is subject to the rights, licenses and restrictions in BCP 78, and the authors keep all their rights except for what BCP 78 says. 🔒
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.
ngl the all-caps energy is a lot 😭 but it's the official disclaimer, so it stays exactly as written. ⚠️
Intellectual Property 🦋
the IETF doesn't take a side on whether any IPR (intellectual property rights) that someone claims about the tech in this doc are valid, or how far they reach. it also doesn't say it looked into whether any such rights exist 🕵️♀️ if you want the procedures for rights in RFC docs, check BCP 78 and BCP 79 📚
if you want copies of IPR disclosures sent to the IETF Secretariat, or the assurances of licenses that come with them, or the results of an attempt to get a general license or permission for implementers or users, you can find them in the IETF's online IPR repository at http://www.ietf.org/ipr 🌐
and the IETF totally invites anyone to tell them about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. just send that info to ietf-ipr@ietf.org 📨✨
Acknowledgement 🫶
funding for the RFC Editor function is currently provided by the Internet Society 💜 thank you, ISOC, you're literally keeping the lights on for all of us 🌈
📦 where this page comes from
- ietf: rfc3743 2004-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms