Network Working Group K. Konishi
Request for Comments: 3743 K. Huang
Category: Informational H. Qian
Y. Ko
April 2004
Joint Engineering Team (JET) Guidelines for
Internationalized Domain Names (IDN) Registration and
Administration for Chinese, Japanese, and Korean
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 (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
IESG Note
IESG注意
The IESG congratulates the Joint Engineering Team (JET) on developing mechanisms to enforce their desired policy. The Language Variant Table mechanisms described here allow JET to enforce language-based character variant preferences, and they set an example for those who might want to use variant tables for their own policy enforcement.
IESGは、それらの所望のポリシーを施行するためのメカニズムの開発に共同エンジニアリングチーム（JET）を祝福します。ここで説明する言語バリアントテーブルメカニズムはJETは、言語ベースの文字バリアントの好みを強制することができ、そして彼らは自分のポリシーの施行のためのバリアントテーブルを使用する場合があります人のための例を設定します。
The IESG encourages those following this example to take JET's diligence as an example, as well as its technical work. To follow their example, registration authorities may need to articulate policy, develop appropriate procedures and mechanisms for enforcement, and document the relationship between the two. JET's LVT mechanism should be adaptable to different policies, and can be considered during that development process.
IESGは、この例を以下のものは例として、JETの勤勉さだけでなく、その技術的な仕事を取るために奨励しています。彼らの例に従うには、登録機関は、政策を明確に施行するために適切な手順や仕組みを開発し、両者の関係を文書化する必要があるかもしれません。 JETのLVTメカニズムは異なるポリシーに適応する必要があり、その開発プロセス中に考慮することができます。
The IETF does not, of course, dictate policy or require the use of any particular mechanisms for the implementation of these policies, as these are matters of sovereignty and contract.
IETFは、当然のことながら、これらは主権や契約の問題であるとして、政策を決定またはこれらの政策の実施のための任意の特定のメカニズムを使用する必要はありません。
Abstract
抽象
Achieving internationalized access to domain names raises many complex issues. These are associated not only with basic protocol design, such as how names are represented on the network, compared, and converted to appropriate forms, but also with issues and options for deployment, transition, registration, and administration.
ドメイン名に国際化のアクセスを達成することは、多くの複雑な問題を提起します。これらが関連付けられているだけでなく、そのような名前がなく、展開、移行、登録、および投与のための問題とオプションで、ネットワーク上で表現と比較し、適切な形式に変換される方法などの基本的なプロトコルの設計、です。
The IETF Standards for Internationalized Domain Names, known as "IDNA", focuses on access to domain names in a range of scripts that is broader in scope than the original ASCII. The development process made it clear that use of characters with similar appearances and/or interpretations created potential for confusion, as well as difficulties in deployment and transition. The conclusion was that, while those issues were important, they could best be addressed administratively rather than through restrictions embedded in 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 and, perhaps, the beginning of a framework for thinking about other zones, languages, and scripts.
「IDNA」として知られている国際化ドメイン名のためのIETF標準は、オリジナルのASCIIよりも範囲が広いのスクリプトの範囲内のドメイン名へのアクセスに焦点を当てています。開発プロセスは、それが明確に似た外見および/または解釈の混乱の可能性を作成し、同様の展開と移行の難しさを持つ文字の使用と判断しました。結論は、これらの問題が重要であった一方で、彼らは最高むしろプロトコルに組み込まれた制限によってよりも、管理に対処することができ、ということでした。この文書では、中国語、日本語、韓国語（CJK）のスクリプトのためにそのタイプの制限を適用するためのガイドラインのセットと、おそらく、それらを使用してゾーン、他のゾーン、言語、スクリプトを考えるための枠組みの始まりを定義します。
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 . . . . . . . . . . . . . . . . . . . 33
Domain names form the fundamental naming architecture of the Internet. 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 without any language context. However, as domain names have become visible to end users through Web URLs and e-mail addresses, the strings in domain-name labels are being increasingly interpreted as names, words, or phrases. It is likely that users will do the same with languages of differing character sets, such as Chinese, Japanese and Korean (CJK), in which many words or concepts are represented using short sequences of characters.
ドメイン名は、インターネットの基本的な命名アーキテクチャを形成します。無数のインターネットプロトコルやアプリケーションだけではなく、安定性と継続性のために、それらに依存するだけでなく、あいまいさを避けるために。彼らは、任意の言語コンテキストなしの識別子であるように設計されました。ドメイン名は、WebのURLや電子メールアドレス、ドメイン名のラベルの文字列を通じてエンドユーザーに見えるようになったとしてしかし、ますますの名前、単語、または句として解釈されています。これにより、ユーザーは、このような多くの単語や概念が文字の短い配列を用いて表現されている中国語、日本語、韓国語（CJK）、などの異なる文字セットの言語で同じことを行う可能性が高いです。
The introduction of what are called Internationalized Domain Names (IDN) amplifies both the difficulty of putting names into identifiers and the confusion that exists between scripts and languages. Character symbols that appear (or actually are) identical, or that have similar or identical semantics but that are assigned the different code points, further increase the potential for confusion. DNS internationalization also affects a number of Internet protocols and applications and creates additional layers of complexity in terms of technical administration and services. Given the added complications of using a much broader range of characters than the original small ASCII subset, precautions are necessary in the deployment of IDNs in order to minimize confusion and fraud.
国際化ドメイン名と呼ばれるものの導入（IDN）は、識別子に名前を入れての難しさやスクリプト言語との間に存在する混乱の両方を増幅します。出現（または実際に）同一の、または類似のまたは同一の意味を持っているが、文字シンボルはさらに混乱の可能性を増加させる、異なるコードポイントが割り当てられます。 DNSの国際化は、インターネット・プロトコルおよびアプリケーションの数に影響を与え、技術管理やサービスの面で複雑さの追加の層を作成します。オリジナルの小さなASCIIのサブセットよりも文字のはるかに広い範囲を使用しての追加合併症を考えると、予防策は混乱と詐欺を最小限にするためにのIDNの展開に必要です。
The IETF IDN Working Group [IDN-WG] addressed the problem of handling the encoding and decoding of Unicode strings into and out of Domain Name System (DNS) labels with the goal that its solution would not put the operational DNS at any risk. Its work resulted in one primary protocol and three supporting ones, respectively:
IETF IDNワーキンググループ[IDN-WG]は内外へのドメインネームシステム（DNS）のUnicode文字列のエンコードとデコードを処理する問題を取り上げ、その解決策は、任意のリスクで運用DNSを入れないであろうことを目標にラベルを付けます。その作業は、それぞれ、1つの主プロトコルと3つの支持のものになりました：
1. Internationalizing Host Names in Applications [IDNA] 2. Preparation of Internationalized Strings [STRINGPREP] 3. A Stringprep Profile for Internationalized Domain Names [NAMEPREP] 4. Punycode [PUNYCODE]
1.国際化ドメイン名[NAMEPREP] 4ピュニコード[PUNYCODE]を国際化された文字列[STRINGPREP] 3. Aのstringprepプロファイルの[IDNA] 2の調製アプリケーションでホスト名を国際
IDNA, which calls on the others, normalizes and transforms strings that are intended to be used as IDNs. In combination, the four provide the minimum functions required for internationalization, such as 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 is more suitable for storing in actual DNS labels. In this way, the IDNA transformations improve a user's chances of getting to the correct IDN.
他人に呼び出すIDNAは、正規化のIDNとして使用されることが意図されている文字列を変換します。組み合わせでは、4は、このような、ケースのマッピングを実行する深刻な問題を引き起こす文字の違いを解消し、マッチング（平等）を指定するなど、国際化のために必要な最低限の機能を提供します。彼らはまた、得られたUnicodeコードポイントと実際のDNSラベルに格納するためのより適しているASCIIベースの形式間の変換します。このように、IDNA変換が正しいIDNになって、ユーザのチャンスを向上させます。
Addressing the issues around differing character sets, a primary consideration and administrative challenge involves region-specific definitions, interpretations, and the semantics of strings to be used in IDNs. A Unicode string may have a specific meaning as a name, word, or phrase in a particular language but that meaning could vary depending on the country, region, culture, or other context in which the string is used. It might also have different interpretations in different languages that share some or all of the same characters. Therefore, individual zones and zone administrators may find it necessary to impose restrictions and procedures to reduce the likelihood of confusion, and instabilities of reference, within their own environments.
異なる文字セットの周りの問題に対処する、第一に考慮し、行政の課題は、地域固有の定義、解釈、とのIDNで使用する文字列の意味を含んでいます。 Unicode文字列は、特定の言語での名前、単語、または語句として特定の意味を持っているかもしれませんが、その意味は、文字列が使用される国、地域、文化、または他のコンテキストに応じて変化させることができます。また、同じ文字の一部または全部を共有する異なる言語で異なる解釈を持っているかもしれません。したがって、個々のゾーンとゾーンの管理者は、それが必要自分の環境内で、基準の制限と混同の可能性を低減するための手順、および不安定性を課すかもしれません。
Over the centuries, the evolution of CJK characters, and the differences in their use in different languages and even in different regions where the same language is spoken, has given rise to the idea of "variants", wherein 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 in the obtaining or using of domain names. However, the concept of variants is complex and may require many different layers of solutions. This guideline offers only one of those solution components. It is not sufficient by itself to solve the whole problem, even with zone-specific tables as described below.
何世紀にもわたって、CJK文字の進化、および異なる言語であっても同じ言語が話されているさまざまな地域での使用の違いは、1つの概念的文字がで識別されることができる「変異体」、の考えに上昇を与えていますコンピュータ用の文字セットでは、いくつかの異なるコードポイント。この文書では、取得またはドメイン名の使用における深刻なユーザーの混乱の可能性を最小限に抑えながら、このような変異体を処理するためのフレームワークを提供します。しかし、変異体の概念は複雑であり、解決策の多くの異なる層を必要とするかもしれません。このガイドラインは、これらの溶液成分の一つだけを提供しています。これは、ゾーン固有のテーブルは、以下に記載されるようにもして、全体の問題を解決するために、それ自体では十分ではありません。
Additionally, because of local language or writing-system differences, it is impossible to create universally accepted definitions for which potential variants are the same and which are not the same. It is even more difficult to define a technical algorithm to generate variants that are linguistically accurate. That is, that the variant forms produced make as much sense in the language as the originally specified forms. It is also possible that variants generated may have no meaning in the associated language or languages. The intention is not to generate meaningful "words" but to generate similar variants to be reserved. So even though the method described in this document may not always be linguistically accurate, nor does it 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.
また、理由は現地の言語や書き込み・システムの違い、潜在的な変異体は同じであり、同じではありませんそのために普遍的に受け入れ定義を作成することは不可能です。それは言語的に正確である変異体を作製するための技術的なアルゴリズムを定義するのはさらに困難です。それは、生産変異型が最初に指定されたフォームなどの言語で同じくらい意味をなすこと、です。生成された変異体は関連する言語または言語の意味を持たないことも可能です。意味のある「言葉」を生成するのではなく、同様の変異体を作製するために意図が確保されます。そのため、この資料に記載された方法は、常に言語的に正確ではないかもしれない、またそれをする必要がないにもかかわらず、それはDNSの固有の限界と人間の言語の複雑さを受け入れながら、右の変種を得ることのチャンスを高めます。
This document outlines a model for such conventions for zones in which labels that contain CJK characters are to be registered and a system for implementing that model. It provides a mechanism that allows each zone to define its own local rules for permitted characters and sequences and the handling of IDNs and their variants.
この文書では、CJK文字を含むラベルが登録されるべきゾーンのためのそのような規則のためのモデルと、そのモデルを実装するためのシステムの概要を説明します。これは、各ゾーンが許可された文字とシーケンスとのIDNとその変種の取り扱いのために独自のローカルルールを定義することを可能にするメカニズムを提供します。
The document is an effort of the Joint Engineering Team (JET), a group composed of members of CNNIC, TWNIC, KRNIC, and JPNIC as well as other individual experts. It offers guidelines for zone administrators, including but not limited to registry operators and registrars and information for all domain names holders on the administration of 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 is helpful.
文書は、共同エンジニアリングチーム（JET）、CNNIC、TWNIC、KRNIC、およびJPNICのメンバーだけでなく、他の個別専門家で構成されるグループの努力です。これは、中国語、日本語、韓国語のスクリプトから引き出された文字を含むドメイン名の管理上のすべてのドメイン名の所有者のための演算子とレジストラとの情報をレジストリに含むがこれらに限定されない、ゾーン管理者のためのガイドラインを提供しています。それが有益である場合、他の言語グループは、これらのガイドラインに基づいて、必要に応じて、独自のガイドラインを作成することが奨励されています。
This document uses a number of special terms. In this section, definitions and explanations are grouped topically. Some readers may prefer to skip over this material, returning, perhaps via the index to terminology in section 7, when needed.
この文書では、特別な用語の数を使用しています。このセクションでは、定義および説明は、局所的にグループ化されています。一部の読者は、必要なときにセクション7、中の用語に、おそらくインデックスを経由して、戻って、この材料をスキップすることもできます。
IDN: The term "IDN" has a number of different uses: (a) as an abbreviation for "Internationalized Domain Name"; (b) as a fully qualified domain name that contains at least one label that contains 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.
IDN：「国際化ドメイン名」の省略形として（A）：用語「IDN」は、異なる用途の数を有しています（b）の文字を含む少なくとも1つのラベルは、ドメイン名（いわゆる「ホスト名」または「LDH」サブセットを推奨ASCIIのサブセットに特異的に、ASCIIではない表示されていない含まれている完全修飾ドメイン名として、RFC1035を参照してください[STD13]）。 ASCIIを超えて少なくとも一つの文字を含むドメイン名のラベルとして、（c）は、 NAMEPREPによって処理されるUnicode文字列として（D）。 （E）NAMEPREPから出力された文字列として。 （F）NAMEPREPとピュニコードへの変換の両方を介して処理の結果である文字列として。 IDNの略語として（G）（より正確に、IDL）パッケージ、本文書の用語では、 IETF IDNワーキンググループの略語として（H）。 ICANN IDN委員会の略称として（G）。および他の企業/組織内の他のIDNの活動のために立っとして（H）。
Because of the potential confusion, this document uses the term "IDN" as an abbreviation for Internationalized Domain Name and, specifically, in the second sense described in (b) above. It uses "IDL," defined immediately below, to refer to Internationalized Domain Labels.
なぜなら混乱のため、この文書は、上記（b）で説明した第2の意味で、具体的には、国際化ドメイン名の略称される用語「IDN」を使用して。これは、国際化ドメインラベルを参照するために、「IDL、」すぐ下に定義を使用しています。
IDL: This document provides a guideline to be applied on a per-zone basis, one label at a time. Therefore, the term "Internationalized Domain Label" or "IDL" will be used instead of the more general term "IDN" or its equivalents. The processing specifications of this document may be applied, in some zones, to ASCII characters also, if those characters are specified as valid in a Language Variant Table (see below). Hence, in some zones, an IDL may contain or consist entirely of "LDH" characters.
IDL：この文書は、一度に1つのラベル、ゾーン単位で適用されるガイドラインを提供します。したがって、用語「国際化ドメインラベル」または「IDL」は、より一般的な用語「IDN」またはその同等物の代わりに使用されます。これらの文字は言語バリアント表に有効であると指定されている場合は、この文書の処理仕様（下記参照）、また、ASCII文字に、いくつかのゾーンに適用することができます。したがって、いくつかのゾーンで、IDLが含まれていてもよい、または完全に「LDH」の文字から成ります。
FQDN: A fully qualified domain name, one that explicitly contains all labels, including a Top-Level Domain (TLD) name. In this context, 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.
FQDN：完全修飾ドメイン名、明示的にトップレベルドメイン（TLD）名を含むすべてのラベルが含まれてい1。この文脈では、TLD名は、そのラベルルートゾーンでのネームサーバレコードに表示されるものです。用語「ドメイン名のラベルは、」FQDNの任意のラベルを指します。
Registration: In this document, the term "registration" refers to the process by which a potential domain name holder requests that a label be placed in the DNS either as an individual name within a domain or as a subdomain delegation from another domain name holder. In the case of a successful registration, the label or delegation records are placed in the relevant zone file, or, more specifically, they are "activated" or made "active" and additional IDLs may be reserved as part of an "IDL Package" (see below). The guidelines presented here are recommended for all zones, at any hierarchy level, in which CJK characters are to appear and not just domains at the first or second level.
登録：この文書では、用語「登録」のラベルがドメイン内の個々の名前として、または別のドメイン名所有者からサブドメインの委任のいずれかとしてDNSに置くことによって、潜在的なドメイン名の所有者の要求するプロセスを指します。登録が成功した場合には、ラベルや委任レコードが関連するゾーンファイルに配置されている、または、より具体的に、彼らは「活性化」または「活性」作られており、追加のIDLは、「IDLパッケージ」の一部として予約することができます（下記参照）。ここに示したガイドラインはここでCJK文字が表示されるようにしているだけでなく、第一又は第二のレベルでドメイン、任意の階層レベルで、すべてのゾーンのために推奨されています。
RFC3066: A system, widely used in the Internet, for coding and representing names of languages [RFC3066]. It is based on an International Organization for Standardization (ISO) standard for coding language names [ISO639], but expands it to provide additional precision.
RFC3066：言語の名前を符号化し、表現するために広くインターネットで使用されるシステムは、[RFC3066]。これは、国際標準化機構（ISO）言語名を符号化するための標準的な[ISO639]に基づいて、それは追加の精度を提供するために展開されています。
ISO/IEC 10646: The international standard universal multiple-octet coded character set ("UCS") [IS10646]. The Code Point definitions of this standard are identical to those of corresponding versions of the Unicode standard (see below). Consequently, the characters and their coding are often referred to as "Unicode characters."
ISO / IEC 10646：国際標準ユニバーサルマルチオクテット符号化文字集合（ "UCS"）[IS10646]。この規格のコードポイントの定義は、Unicode標準のバージョン（下記参照）対応のものと同一です。そのため、文字とそのコーディングは、しばしばと呼ばれている「のUnicode文字。」
Unicode Character: The term "Unicode character" is used here in reference to characters chosen from the Unicode Standard Version 3.2 [UNICODE] (and hence from ISO/IEC 10646). In this document, the
Unicode文字：用語「Unicode文字が」Unicode標準バージョン3.2 [UNICODE]から選択された文字に関連してここで使用されている（したがって、ISO / IEC 10646から）。この文書では、
characters are identified by their positions, or "Code Points." The notation U+12AB, for example, indicates the character at the position 12AB (hexadecimal) in the Unicode 3.2 table. For characters in positions above FFFF, i.e., requiring more than sixteen bits to represent, a five to eight-character string is used, such as U+112AB for the character in position 12AB of plane 1.
文字は、その位置、またはによって識別され、「コードポイント。」表記U + 12ABは、例えば、ユニコード3.2テーブルの位置12AB（16進数）の文字を表します。 FFFF上記位置の文字について、すなわち、表現するために以上16ビットを必要とする5〜8文字列は、プレーン1の位置12ABにおける文字のU + 112ABとして、使用されています。
Unicode String: "Unicode string" refers to a string of Unicode characters. The Unicode string is identified by the sequence of the Unicode characters regardless of the encoding scheme.
Unicodeの文字列：「Unicode文字列は、」Unicode文字の文字列を指します。 Unicode文字列に関係なく符号化方式のUnicode文字のシーケンスによって識別されます。
CJK Characters: CJK characters are characters commonly used in the Chinese, Japanese, or Korean languages, including but not limited to those 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. The particular characters that are permitted in a given zone are specified in the Language Variant Table(s) for that zone.
CJK文字：CJK文字がASCIIとしてUnicode標準（U + 007FにU + 0020）で定義されたものを含むがこれらに限定されない、一般的に中国語、日本語、または韓国語の言語で使用される文字で、漢の表意文字（U + 3400 Uへ+ 9FAFとU + 2A6DFにU + 20000）、ボポモフォ（U + 3100 U + 312FおよびU + 31BFにU + 31A0）、カナ（U + 30FFにU + 3040）、字母（11FFにU + 1100にU + 318FにU + 3130）、U + 318FにU + D7AFとU + 3130にハングル（U + AC00）、及びそれぞれの互換性フォーム。所与のゾーンで許可されている特定の文字は、そのゾーンの言語バリアントテーブル（単数または複数）で指定されています。
Label String: A generic term referring to a string of characters that is a candidate for registration in the DNS or such a string, once registered. A label string may or may not be valid according to the rules of this specification and may 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.
ラベルの文字列：DNSまたは、そのような文字列への登録候補となる文字列を指す一般的な用語は、一度登録されました。ラベル文字列は、あるいはこの仕様の規則に従って有効であってもなくてもよいとさえIDNAの使用のために無効になることがあります。 「標識」という用語は、それ自体で、検証されたとDNSゾーンファイルに表示されるようにフォーマットされてもよいの文字列を指します。
Language Variant Table: The key mechanisms of this specification utilize a three-column table, called a Language Variant Table, for each language permitted to be registered in the zone. Those columns are known, respectively, as "Valid Code Point", "Preferred Variant", and "Character Variant", which are defined separately below. The Language Variant Tables are critical to the success of the guideline described in this document. However, the principles to be used to generate the tables are not within the scope of this document and should be worked out by each registry 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.
言語バリアント表：各言語ゾーンに登録することを許可するために、本明細書の主要なメカニズムは、3列のテーブルを利用し、言語バリアントテーブルと呼ばれます。これらの列は、以下に別々に定義される「有効なコードポイント」、「好ましい変形」、および「文字バリアント」として、それぞれ知られています。言語バリアントテーブルは、この文書で説明したガイドラインの成功に不可欠です。しかし、テーブルを生成するために使用される原理は、この文書の範囲外であり、（おそらく他のいくつかのレジストリの仕事を採用するまたは適合させることにより）別々に各レジストリによって働いされるべきです。この文書では、「表」と「バリアント表は、」言語バリアント表のための短い形態として使用されています。
Valid Code Point: In a Language Variant Table, the list of Code Points that is permitted for that language. Any other Code Points, or any string containing them, will be rejected by this specification. The Valid Code Point list appears as the first column of the Language Variant Table.
有効なコードポイント：言語バリアント表には、その言語のために許可されているコードポイントのリスト。他のコードポイント、またはそれらを含む任意の文字列は、この仕様によって拒否されます。有効なコードポイントのリストは言語バリアント表の最初の列として表示されます。
Preferred Variant: In a Language Variant Table, a list of Code Points corresponding to each Valid Code Point and providing possible substitutions for it. These substitutions are "preferred" in the sense that the variant labels generated using them are normally registered in the zone file, or "activated." The Preferred Code Points appear in column 2 of the Language Variant Table. "Preferred Code Point" is used interchangeably with this term.
好ましい変形例：言語バリアント表には、各有効なコードポイントに対応し、そのための可能な置換を提供するコードポイントのリスト。これらの置換は、それらを使用して生成バリアントのラベルは、通常、ゾーンファイルに登録、またはされているという意味で「好ましい」されている「活性化。」優先コードポイントは言語バリアント表の第2欄に表示されます。 「優先コードポイントは、」この用語と交換可能に使用されます。
Character Variant: In a Language Variant Table, a second list of Code Points corresponding to each Valid Code Point and providing possible substitutions for it. Unlike the Preferred Variants, substitutions based on Character Variants are normally reserved but not actually registered (or "activated"). Character Variants appear in column 3 of the Language Variant Table. The term "Code Point Variants" is used interchangeably with this term.
文字バリアント：言語バリアントテーブル、各有効なコードポイントに対応し、それのために可能な置換を提供するコードポイントの第2のリストで。好ましい変異体とは異なり、文字バリアントに基づいて、置換が正常に予約されているが、実際に登録（または「活性化」）しません。文字バリアントは言語バリアント表の第3欄に表示されます。用語「コードポイント変異体」は、この用語と交換可能に使用されます。
Preferred Variant Label: A label generated by use of Preferred Variants (or Preferred Code Points).
好ましい変形ラベル：好ましい変異体（または優先コードポイント）を使用することによって生成されたラベル。
Character Variant Label: A label generated by use of Character Variants.
文字バリアントレーベル：文字バリアントを使用することによって生成されたラベル。
Zone Variant: A Preferred or Character Variant Label that is actually to be entered (registered) into the DNS. That is, into the zone file for the relevant zone. Zone Variants are also referred to as Zone Variant Labels or Active (or Activated) Labels.
ゾーンバリアント：実際にあるDNSに入力（登録）することが好ましいか、文字バリアントラベル。それは、関連するゾーンのゾーンファイルに、です。ゾーンバリアントもゾーンバリアントラベルまたはActive（または活性化）ラベルと呼ばれています。
IDL Package: A collection of IDLs as determined by these Guidelines. All labels in the package are "reserved", meaning they cannot be registered by anyone other than the holder of the Package. These reserved IDLs may be "activated", meaning they are actually entered into a zone file as a "Zone Variant". The IDL Package also contains identification of the language(s) associated with the registration process. The IDL and its variant labels form a single, atomic unit.
IDLパッケージ：これらのガイドラインによって決定されるのIDLのコレクション。パッケージ内のすべてのラベルは、パッケージの所有者以外の者によって登録されていないことができることを意味し、「予約」されています。これらの予約済みのIDLは、彼らが実際に「ゾーンバリアント」として、ゾーンファイルに入力されている意味、「活性化」することができます。 IDLパッケージは、登録プロセスに関連付けられている言語（複数可）の同定を含んでいます。 IDLおよびその変異体ラベルは、単一のアトミックユニットを形成します。
For purposes of clarity, particularly in regard to examples, Han ideographs appear in several places in this document. However, they do not appear in the ASCII version of this document. For the convenience of readers of the ASCII version, and some readers not familiar with recognizing and distinguishing Chinese characters, most uses of these characters will be associated with both their Unicode Code Points and an "asterisk tag" with its corresponding Chinese Romanization [ISO7098], with the tone mark represented by a number from 1 to 4. Those tags have no meaning outside this document; they are a quick visual and reading reference to help facilitate the combinations and transformations of characters in the guideline and table excerpts.
明確にするために、特に例に関して、漢の表意文字は、このドキュメントのいくつかの場所に表示されます。しかし、彼らはこの文書のASCIIバージョンでは表示されません。中国の文字を認識・識別に精通していないASCII版の読者、および一部の読者の便宜のために、これらの文字のほとんどの用途は、そのUnicodeのコードポイントとそれに対応する中国のローマ字表記で「アスタリスクタグ」の両方に関連付けられます[ISO7098] 、トーン・マークで1〜4の数で表されるタグは、この文書の外には意味を持ちません。彼らはガイドラインやテーブル抜粋内の文字の組み合わせと変換を促進するのに役立つ視覚的にすばやく、読書参照されています。
Zone administrators are responsible for the administration of the domain name labels under their control. A zone administrator might be responsible for a large zone, such as a top-level domain (TLD), whether generic or country code, or a smaller one, such as a typical second- or third-level domain. A large zone is often more complex than its smaller counterpart. However, actual technical administrative tasks, such as addition, deletion, delegation, and transfer of zones between domain name holders, are similar for all zones.
ゾーン管理者は、管理下のドメイン名ラベルの管理を担当しています。ゾーン管理者は、大規模なそのようなトップレベルドメイン（TLD）のようなゾーン、汎用または国コードか、またはそのような典型的な2次または第3レベルドメインとして小さい方の原因かもしれません。大ゾーンは、多くの場合、その小さなカウンターパートよりも複雑です。しかし、そのような追加、削除、委任、およびドメイン名保有者間のゾーンの転送など、実際の技術的な管理タスクは、すべてのゾーンについても同様です。
This document provides guidelines for the ways 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).
この文書は、提供CJK文字は言語の問題を考慮して組み込まれるべきかについて、およびCJK文字を含むどのようにドメイン名のラベルのため、ゾーン内で処理されなければならない方法についてのガイドラインは、（登録、削除、およびラベルの移転を含む）投与すべきです。
Other IDN policies, such as the creation of new top-level domains (TLDs), the cost structure for registrations, and how the processes described here get allocated between registrar and registry if the zone makes that distinction, also are outside the scope of this document.
新たなトップレベルドメイン（TLD）の作成、登録のためのコスト構造、およびどのゾーンはその区別を行う場合、ここで説明したプロセスは、レジストラとレジストリの間で割り当てられますなどの他のIDNポリシーは、また、この範囲外であります資料。
Technical implementation issues are not 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, with the possibility that it will differ from zone to zone.
技術的な実装上の問題はここでも議論されていません。例えば、ガイドラインは、レジストリのアクションとして実装する必要があり、それがゾーンにゾーンから異なることが可能で、管理者をゾーニングして残っているレジストラの行動、であるべきかを決めます。
In many places, in the event of a dispute over rights to a name (or, more accurately, DNS label string), this document assumes "first-come, first-served" (FCFS) as a resolution policy even though FCFS is not listed below as one of the principles for this document. If policies are already in place governing priorities and "rights", one can use the guidelines here by replacing uses of FCFS in this document with policies specific to the zone. Some of the guidelines here may not be applicable to other policies for determining rights to labels. Still other alternatives, such as use of UDRP [UDRP] or mutual exclusion, might have little impact on other aspects of these guidelines.
名前への権利をめぐる紛争のイベントで多くの場所、（または、より正確に、DNSラベルの文字列）は、この文書が前提としていて、「先着順」FCFSは（FCFS）解決ポリシーとしてではないにもかかわらず、この文書の原則の一つとして、以下に示します。政策が優先順位と「権利」を支配する場所に既に存在する場合、1は、ゾーンに固有のポリシーに、この文書でFCFSの使用を置き換えることで、ここでのガイドラインを使用することができます。ここでのガイドラインのいくつかは、ラベルの権利を決定するための他のポリシーに適用できない場合があります。それでも、このようなUDRP [UDRP]または相互排他の使用など他の選択肢は、これらのガイドラインの他の側面にはほとんど影響があるかもしれません。
(a) Although some Unicode strings may be pure identifiers made up of an assortment of characters from many languages and scripts, IDLs are likely to be "words" or "names" or "phrases" that have specific meaning in a language. While a zone administration might or might not require "meaning" as a registration criterion, meaning could prove to be a useful tool for avoiding user confusion.
一部のUnicode文字列は、多くの言語やスクリプトからの文字の品揃えで構成された純粋な識別子であるかもしれないが（a）は、のIDLは言語に特定の意味を持つ「言葉」や「名前」または「フレーズ」である可能性が高いです。ゾーンの管理がまたは登録基準として「意味」を必要としない場合がありますが、意味は、ユーザーの混乱を回避するために有用なツールになるかもしれません。
Each IDL to be registered should be associated administratively with one or more languages.
登録する各IDLは、一の以上の言語に行政関連付けられている必要があります。
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 latter may be necessary for some zones, but it will make administration more difficult and will increase the likelihood of conflicts in variant forms.
言語の関連付けは、いずれかのゾーン管理者によって予め定められた全体領域に適用されるか、毎IDLに基づいて登録者によって選択されなければなりません。後者は、いくつかのゾーンのために必要かもしれないが、それは管理がより困難になり、異型における競合の可能性を高めるだろう。
A given zone might have multiple languages associated with it or it may have no language specified at all. Omitting specification of a language may provide additional opportunities for user confusion and is therefore NOT recommended.
与えられたゾーンは、それに関連付けられた複数の言語を持っているかもしれませんか、それがすべてで指定されていない言語を持たないことがあります。言語の仕様を省略すると、ユーザーの混乱のための追加の機会を提供するため、推奨されないことがあります。
(b) Each language uses only a subset of Unicode characters. Therefore, if an IDL is associated with a language, it is not permitted to contain any Unicode character that is not within the valid subset for that language.
（B）各言語は、Unicode文字のサブセットのみを使用します。 IDLは言語に関連付けられている場合ので、その言語の有効なサブセット内にない任意のUnicode文字を含めることが許可されていません。
Each IDL to be registered must be verified against the valid subset of Unicode for the language(s) associated with the IDL.
登録する各IDLは、IDLに関連付けられている言語（複数可）にUnicodeの有効なサブセットに対して検証されなければなりません。
That subset is specified by the list of characters appearing in the first column of the language and zone-specific tables as described later in this document.
本書で後述するように、そのサブセットは、言語とゾーン固有のテーブルの最初の列に現れる文字のリストで指定されています。
If the IDL fails this test for any of its associated languages, the IDL is not valid for registration.
IDLは、それに関連する言語のいずれかのために、このテストに失敗した場合、IDLは、登録のために有効ではありません。
Note that this verification is not necessarily linguistically accurate, because some languages have special rules. For example, some languages impose restrictions on the order in which particular combinations of characters may appear. Characters that are valid for the language, and hence permitted by this specification, might still not form valid words or even strings in the language.
一部の言語は特別なルールを持っているので、この検証は、必ずしも言語的に正確ではないことに注意してください。例えば、いくつかの言語では、文字の特定の組み合わせが表示される場合があります順序に制約を課します。言語の有効な、したがって、この仕様によって許可されている文字は、まだ言語で有効な言葉、あるいは文字列を形成しない場合があります。
(c) When an IDL is associated with a language, it may have Character Variants that depend on that language associated with it in addition to any Preferred Variants. These variants are potential sources of confusion with the Code Points in the original label string. Consequently, the labels generated from them should be unavailable to registrants of other names, words, or phrases.
IDLは、言語に関連付けられている場合（C）は、任意の好ましい変異体に加えて、それに関連する言語に依存する文字バリアントを有していてもよいです。これらの変異体は、元のラベル文字列でのコードポイントとの混同の潜在的な原因です。その結果、それらから生成されたラベルは、他の名前、単語、またはフレーズの登録者に利用不能にする必要があります。
During registration, all labels generated from the Character Variants for the associated language(s) of the IDL should be reserved.
登録時に、IDLの関連言語（複数可）の文字バリアントから生成されたすべてのラベルを保有しなければなりません。
IDL reservations of the type described here 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.
ここに記載したタイプのIDL予約は正規分布DNSゾーンファイルには表示されません。言い換えれば、これらの予約済みのIDLは解決されない場合があります。ドメイン名の所有者は、これらの予約済みのIDLは、ゾーンファイルに入れ、積極的かつ解決可能行うことを要求することができます。
Zones will need to establish local policies about how they are to be 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). And long-term use of long-term aliases for domain hierarchies, rather than single names ("DNAME records") are considered problematic because of the recursion they can introduce into DNS lookups.
ゾーンは、彼らがアクティブにされる方法についてのローカルポリシーを確立する必要があります。具体的には、特にトップレベルで多くのゾーンは、特に委任レコード（NSレコード）、ネームサーバをポイントするCNAMES、「CNAME」のDNSエイリアスの使用を禁止または制限されています。そして、長期的なドメイン階層のエイリアスではなく、単一の名前（「DNAMEレコード」）の長期使用があるため、彼らはDNSルックアップに導入することができます再帰の問題と考えられています。
(d) When an IDL is a "name", "word", or "phrase", it will have Character Variants depending on the associated language. Furthermore, one or more of those Character Variants will be used more often than others for linguistic, political, or other reasons.
IDLは、「名前」、「単語」、または「句」である場合には（D）、それは文字が関連付けられている言語に応じてバリアントがあります。さらに、これらの文字バリアントのうちの1つ以上は、言語的、政治的、またはその他の理由で他の人よりも頻繁に使用されます。
These more commonly used variants are distinguished from ordinary Character Variants and are known as Preferred Variant(s) for the particular language.
これらのより一般的に使用される変異体は、通常の文字バリアントから区別され、特定の言語のための好ましい変形（S）として知られています。
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.
エンドユーザによってIDNの正確かつ予測可能な解像度の可能性を高めるために、関連する言語（複数可）のための好ましい変異体から生成されたすべてのラベルが解決すべきです。
In other words, the Preferred Variant Labels should appear in the distributed DNS zone file.
言い換えれば、好ましい変形ラベルは、分散DNSゾーンファイルに表示されます。
(e) IDLs associated with one or more languages may have a large number of Character Variant Labels or Preferred Variant Labels. Some of these labels may include combinations of characters that are meaningless or invalid linguistically. It may therefore be appropriate for a zone to adopt procedures that include only linguistically acceptable labels in the IDL Package.
一の以上の言語に関連付けられた（E）のIDL文字バリアントラベルまたは好ましい変形ラベルを多数有していてもよいです。これらのラベルの一部は無意味か、または無効言語的な文字の組合せを含むことができます。ゾーンはIDLパッケージでのみ言語学的に許容可能な標識を含む手順を採用することは、したがって適切であり得ます。
A zone administrator may impose additional rules and other processing activities to limit the number of Character Variant Labels or Preferred Variant Labels that are actually reserved or registered.
ゾーン管理者は、実際に予約または登録されている文字バリアントラベルまたは好ましい変形ラベルの数を制限するために、追加のルールと他の処理活動を課すことができます。
These additional rules and other processing activities are based on policies and/or procedures imposed on a per-zone basis and therefore are not within the scope of this document. Such policies or procedures might be used, for example, to restrict the number of Preferred Variant Labels actually reserved or to prevent certain words from being registered at all.
これらの付加的な規則及び他の処理活動は、ゾーンごとに課されるポリシーおよび/または手順に基づくものであり、従って、この文書の範囲内ではありません。このような方針や手続きは、実際に予約され好ましい変形ラベルの数を制限するために、またはすべてに登録されることから特定の単語を防ぐために、例えば、使用される可能性があります。
(f) There are some Character Variant Labels and Preferred Variant Labels that are associated with each IDL. These labels are considered "equivalent" to each another. To avoid confusion, they all should be assigned to a single domain name holder.
（f）は、各IDLに関連付けられているいくつかの文字バリアントラベルと好ましい変形ラベルがあります。これらのラベルは、それぞれ別の「同等」とみなされます。混乱を避けるために、それらはすべて、単一のドメイン名の所有者に割り当てる必要があります。
The IDL and its variant labels should be grouped together into a single atomic unit, known in this document as an "IDL Package".
IDLおよびその変異ラベルは「IDLパッケージ」として本書で知られている単一の原子単位にグループ化されるべきです。
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. That is, 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.
IDLパッケージには、登録時に作成され、アトミックです：IDLの転送および削除は、全体としてのIDLパッケージで実行されます。すなわち、IDLパッケージ内IDLが転送または個々に削除されなくてもよいです。 IDLに影響を与える任意の再登録、転送、またはその他のアクションは、他の変形に影響を与える必要があります。
The name-conflict resolution policy associated with this zone could result in a conflict with the principle of IDL Package atomicity. In such a case, the policy must be defined to make the precedence clear.
このゾーンに関連付けられている名前紛争解決ポリシーは、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 that is used to interpret the table and generate variant labels.
言語バリアント表とIDLパッケージ：3.1で説明した原則に準拠するため、この文書は二つの概念を紹介します。これらは、テーブルを解釈して変異体のラベルを生成するために使用されるアルゴリズムの説明に続いて次の2つのサブセクションに記載されています。
For each zone that uses a given language, each language should have its own Language Variant Table. The table consists of 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 and three columns.
指定された言語を使用する各ゾーンについて、各言語には独自の言語バリアントテーブルを持つ必要があります。テーブルは、言語と3列のために有効である各コードポイントのための1つの行のセクションに続いて参照し、バージョン情報を識別するヘッダ部、から構成されています。
(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 is used 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.
（1）最初の列は（「有効なコードポイント」）が登録されるように有効であるUnicode文字のサブセットが含まれています。これは、（3.1Bを参照）登録するIDLを確認するために使用されます。後述する登録手順と同様に、この列は、処理することが提案IDLに表示される文字を検査するためのインデックスとして使用されます。スクリプトの通常の定義は、日中韓のもので、例えば、ASCII文字が含まれていないだろうが、特定の言語のためのテーブルで有効なコードポイントのコレクションは、その言語のスクリプトを定義すると考えることができます。
(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. 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 that they will resolve when the DNS is queried for them.
（2）第2列は、1桁目に対応するUnicode文字（「有効なコードポイント」）の好ましい変形（複数可）を含有します。これらの変異体の文字はIDLのための好ましい変形ラベルを生成するために使用されています。これらのラベルは、（3.1dを参照）に解決する必要があります。 DNSは、彼らのために照会されたときに、彼らが解決できるようにするために、通常の状況下では、これらの好ましい変形ラベルの全ては、関連するゾーンファイルで活性化されます。
(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.
（3）第3列は、対応する有効なコードポイントの文字バリアント（S）を含有します。これらは、（3.1Cを参照）、次に予約されるIDLの文字バリアントラベルを生成するために使用されます。文字バリアントから生成されたラベルの登録、または活性化は、通常、ローカルポリシーの対象と登録者の決定、となります。
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, or Valid Code Point, may have only one Code Point specified in a given row. The other columns may have more than one.
列内の各エントリは、Unicodeテーブルの数字数として表され、必要に応じて括弧参照続いて、一つ以上のコードポイントから成ります。最初の列、または有効なコードポイントは、所与の行で指定された唯一のコードポイントを有することができます。他の列は、複数であってもよいです。
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.
テーブルの正式な構文とその組織のいくつかのより正確な定義は、第5節で表示されます。
The Language Variant Table should be provided by a relevant group, organization, or body. However, the question of who is relevant or has the authority to create this table and the rules that define it is beyond the scope of this document.
言語バリアント表は、関連するグループ、組織、又は身体によって提供されるべきです。しかし、の質問は関連性があるか、このテーブルと、それは、このドキュメントの範囲を超えて定義したルールを作成する権限を持っています。
The IDL Package is created on successful registration and consists of:
IDLパッケージが正常に登録上で作成し、で構成されています。
(1) the IDL registered
（1）IDL登録します
(2) the language(s) associated with the IDL
IDLに関連付けられた（2）言語（複数可）
(3) the version of the associated character variant table
（3）対応する文字バリアントテーブルのバージョンを
(4) the reserved IDLs
（4）予約済みのIDL
(5) active IDLs, that is, "Zone Variant Labels" that are to appear in the DNS zone file
（5）アクティブのIDLを、それは、DNSゾーンファイルに表示されている「ゾーンバリアントラベル」です
An explanation follows each step.
説明は、各ステップに従います。
Step 1. IN <= IDL to be registered and {L} <= Set of languages associated with IN
<= IDL登録すると、{L} <INに関連付けられた言語のセット= INステップ1
Start the process with the label string (prospective IDL) to be registered and the associated language(s) as input.
入力として登録するラベル列（将来IDL）と関連付けられた言語（複数可）でプロセスを開始します。
Step 2. Generate the Nameprep-processed version of the IN, applying all mappings and canonicalization required by IDNA.
ステップ2. IDNAで必要とされるすべてのマッピングおよび正規化を適用し、INのNAMEPREP-処理されたバージョンを生成します。
The prospective IDL is processed by using Nameprep to apply the normalizations and exclusions globally required to use IDNA. If the Nameprep processing fails, then the IDL is invalid and the registration process must stop.
将来のIDLはグローバルIDNAを使用するために必要な正規化と除外を適用するにはNAMEPREPを使用して処理されます。 NAMEPREP処理が失敗した場合、IDLは無効であり、登録プロセスを停止する必要があります。
Step 2.1. NP(IN) <= Nameprep processed IN Step 2.2. Check availability of NP(IN). If not available, route to conflict policy.
ステップ2.1。 NP（IN）<= NAMEPREPステップ2.2で処理。 NP（IN）の可用性を確認してください。利用できない場合、紛争政策へのルート。
The Nameprep-processed IDL is then checked against the contents of the zone file and previously created IDL Packages. If it is already registered or reserved, then a conflict exists that must be resolved by applying whatever policy is applicable for the zone. For example, if FCFS is used, the registration process terminates unless the conflict resolution policy provides another alternative.
NAMEPREP処理IDLは、ゾーンファイルの内容と、以前に作成したIDLパッケージと照合されます。それは既に登録または予約されている場合、競合がそのゾーンに適用されますどんなポリシー適用することで解決されなければならない存在します。 FCFSが使用される場合、競合解決ポリシーは、別の代替手段を提供しない限り、例えば、登録処理を終了します。
Step 3. Process each language. For each language (AL) in {L}
ステップ3.プロセスの各言語。 {L}中の各言語（AL）のために
Step 3 goes through all languages associated with the proposed IDL and checks each character (after Nameprep has been applied) for validity in each of them. It then applies the Preferred Variants (column 2 values) and the Character Variants (column 3 values) to generate candidate labels.
ステップ3は、それらのそれぞれにおける有効性のための提案IDLをチェック（NAMEPREPが適用された後で）各文字に関連付けられているすべての言語を通過します。これは、候補ラベルを生成する好ましい変異体（列2つの値）および文字バリアント（カラム3の値）を印加します。
Step 3.1. Check validity of NP(IN) in AL. If failed, stop processing.
ステップ3.1。 ALにNP（IN）の妥当性を確認してください。失敗した場合は、処理を停止。
In step 3.1, IDL validation is done by checking that every Code Point in the Nameprep-processed IDL is a Code Point allowed by the "Valid Code Point" column of the Character Variant Table for the language. This is then repeated for any other languages (and hence, Language Variant Tables) specified in the registration. If one or more Code Points are not valid, the registration process terminates.
ステップ3.1では、IDLの検証はNAMEPREP処理IDL内のすべてのコードポイントは、言語の文字バリアントの表の「有効なコードポイント」欄で許可されたコードポイントがあることを確認することで行われます。次いで、これを他の言語（したがって、言語バリアントテーブル）の登録で指定について繰り返されます。一つ以上のコードポイントが有効でない場合は、登録処理を終了します。
Step 3.2. PV(IN,AL) <= Set of available Nameprep-processed Preferred Variants of NP(IN) in AL
ステップ3.2。 PV（IN、AL）<= ALにおけるNP（IN）の利用可能NAMEPREP処理好ましい変異体のセット
Step 3.2 generates the list of Preferred Variant Labels of the IDL by doing a combination (see Step 3.2A below) of all 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 the Nameprep processing fails for any Preferred Variant Label (this is unlikely to occur if the Preferred Variants are processed through Nameprep before being placed in the table), then that variant label will be removed from the list. The remaining Preferred Variant Labels in the list are then checked to see whether they are already registered or reserved. If any are registered or reserved, then the conflict resolution policy will apply. In general, this will not prevent the originally requested IDL from being registered unless the policy prevents such registration. For example, if FCFS is applied, then the conflicting variants will be removed from the list, but the originally requested
ステップ3.2は、組み合わせをNAMEPREP処理IDLの各コードポイントについて「好ましい変形（S）」の欄に記載されているすべての可能な変形の（下のステップ3.2Aを参照）ことによって、IDLの好ましい変形ラベルのリストを生成します。生成された好ましい変形ラベルはNAMEPREPを通って処理されなければなりません。 NAMEPREP処理は（これは好ましい変異体は、テーブルに配置される前に、NAMEPREPを通って処理されている場合に発生することはほとんどありません）任意の好ましい変形ラベルのために失敗した場合、そのバリアントラベルがリストから削除されます。リスト内の残りの好ましい変形のラベルは、彼らがすでに登録または予約されているかどうかをチェックされます。いずれかが登録または予約されている場合は、競合解決ポリシーが適用されます。一般的には、このポリシーは、そのような登録を防止していない限り、登録されてから最初に要求IDLを防ぐことはできません。 FCFSが適用された場合、その後、競合変異体は、リストから削除されますが、最初に要求します
IDL and any remaining variants will be registered (see steps 5 and 8 below).
IDLおよび残りの変異体は、（下記のステップ5及び8を参照）に登録します。
Step 3.2A Generating variant labels from Variant Code Points.
バリアントコードポイントからバリアントのラベルを生成するステップ3.2A。
Steps 3.2 and 3.3 require that the Preferred Variants and Character Variants be combined with the original IDL to form sets of variant labels. Conceptually, one starts with the original, Nameprep-processed, IDL and examines each of its characters in turn. If a character is encountered for which there is a corresponding Preferred Variant or Character Variant, a new variant label is produced with the Variant Code Point substituted for the original one. If variant labels already exist as the result of the processing of characters that appeared earlier in the original IDL, then the substitutions are made in them as well, resulting in additional generated variant labels. This operation is repeated separately for the Preferred Variants (in Step 3.2) and Character Variants (in Step 3.3). Of course, equivalent results could be achieved by processing the original IDL's characters in order, building the Preferred Variant Label set and Character Variant Label set in parallel.
3.2と3.3が好ましい変異体と文字バリアントラベルのセットを形成するために、元のIDLと組み合わせること変種ことを必要とする手順。概念的には、一つはオリジナル、NAMEPREP処理、IDLで始まり、順番にその文字のそれぞれを調べます。文字は、対応する好ましい変形や文字バリアントが存在しているために発生した場合のバリアントコードポイントは、元の1の代わりに、新しい変種ラベルが作成されます。変異体ラベルは既に元のIDLで先に現れた文字の処理の結果として存在する場合、置換が追加発生変異体標識をもたらす、ならびにそれらで作られています。この動作は、（ステップ3.3）好ましい変異体（ステップ3.2）および文字バリアントに対して別々に繰り返されます。もちろん、同等の結果が平行に設定好ましい変形ラベルセットと文字バリアントラベルを構築し、順番に元のIDLの文字を処理することによって達成することができました。
This process will sometimes generate a very large number of labels. For example, if only two of the characters in the original IDL are associated with Preferred Variants and if the first of those characters has three Preferred Variants and the second has two, one ends 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 further increase the number of labels. And if more than one language is specified for the original IDL, then repetition of the process for additional languages (see step 4, below) might further increase the size of the set.
このプロセスは、時々ラベルの非常に大きな数を生成します。例えば、2つだけのオリジナルIDLの文字は、好ましい変異体に関連付けられている場合、それらの文字の最初の3つの好ましい変異体を有し、第2は、2つを持っている場合、一方がIDLパッケージ内に配置されるように12枚の変異体ラベルで終わると通常、ゾーンファイルインチが存在する場合、文字バリアントのためのプロセスを繰り返すこと、さらにラベルの数を増加させるであろう。複数の言語が、元のIDLに指定されている場合は、追加の言語（以下ステップ4を参照）のためのプロセスの繰り返しがさらにセットのサイズを大きくすることがあります。
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
SSTRは、コードポイントの（変異体中の各VについてそうでループするSubCOM =コンビネーション（SSTR）の端部（コードポイントVの文字列）（コードポイントFのバリアント）NSC = NSCセット組合内の各V、次いで空の場合ループENDIFのループ端するSubCOM NSC = NSCセット組合（文字列SCに続いて最初のコードポイントVの文字列内の各SCについてF））終了
Return NSC
NSCを返します。
Step 3.3. CV(IN,AL) <= Set of available Nameprep-processed Character Variants of NP(IN) in AL
ステップ3.3。 CV（IN、AL）<ALにおけるNP（IN）の利用可能NAMEPREP処理文字バリアントのセット=
This step generates the list of Character Variant Labels by doing a combination (see Step 3.2A above) of all the possible variants listed in the "Character Variant(s)" column for each Code Point in the Nameprep-processed original IDL. As with the Preferred Variant Labels, the generated Character Variant Labels must be processed by, and acceptable to, Nameprep. If the Nameprep processing fails for a Character Variant Label, then that variant label will be removed from the list. The remaining Character Variant Labels are then checked to be sure they are not registered or reserved. If one or more are, then the conflict resolution policy is applied. As with Preferred Variant Labels, a conflict that is resolved in favor of the earlier registrant does not, in general, prevent the IDL from being registered, nor the remaining variants from being reserved in step 6 below.
このステップでは、NAMEPREP処理元IDL内の各コードポイントのための「文字変種」欄に記載されているすべての可能な変形の（上記のステップ3.2Aを参照）の組み合わせを実行して、文字バリアントラベルのリストを生成します。好ましい変形ラベルと同じように、生成された文字バリアントラベルはによって処理されなければならない、とNAMEPREPに許容できます。 NAMEPREP処理は文字バリアントラベルのために失敗した場合、そのバリアントラベルがリストから削除されます。残りの文字バリアントラベルは、その後、彼らは登録または予約されていないことを確認するためにチェックされています。一つ以上である場合には、紛争解決ポリシーが適用されます。好ましい変形ラベル、一般的には、登録されているからIDLを防ぐことはできません、以前の登録者を優先して解決された紛争、また残りの亜種と同様に、以下のステップ6で予約されています。
Step 3.4. End of Loop
ステップ3.4。ループの終わり
Step 4. Let PVall be the set-union of all PV(IN,AL)
ステップ4.レッツは、全てのPV（IN、AL）のセット組合もPVall
Step 4 generates the Preferred Variants Label for all languages. In this step, and again in step 6 below, the zone administrator may impose additional rules and processing activities to restrict the number of Preferred (tentatively to be reserved and activated) and Character (tentatively to be reserved) Label Variants. These additional rules and processing activities are zone policy specific and therefore are not specified in this document.
ステップ4は、すべての言語のための好ましい変異体ラベルを生成します。このステップでは、再度以下のステップ6で、ゾーン管理者は、（仮予約と活性化される）と文字（仮予約する）ラベル変異好ましいの数を制限するために追加のルールおよび処理活動を課すことができます。これらの追加のルールと処理活動は、特定のため、この文書で指定されていないゾーンのポリシーです。
Step 5. {ZV} <= PVall set-union NP(IN)
ステップ5. {ZV} <= PVallセット組合NP（IN）
Step 5 generates the initial Zone Variants. The set includes all Preferred Variants for all languages and the original Nameprep-processed IDL. Unless excluded by further processing, these Zone Variants will be activated. That is, placed into the DNS zone. Note that the "set-union" operation will eliminate any duplicates.
ステップ5は、最初のゾーンバリアントを生成します。セットには、すべての言語のすべての好ましい変異体と、元NAMEPREP処理IDLを含んでいます。さらに処理によって除外されない限り、これらのゾーンバリアントが有効になります。これは、DNSゾーンに置かれています。 「セット・ユニオン」の操作は、任意の重複を排除することに注意してください。
Step 6. Let CVall be the set-union of all CV(IN,AL), set-minus {ZV}
ステップ6.レットは、すべてのCV（IN、AL）、セットマイナス{ZV}のセット和集合であるCVall
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 defined in the previous step. The set-union and set-minus operations eliminate any duplicates.
ステップ6は、予約ラベルバリアント（文字バリアントラベルセット）を生成します。これらのラベルは、通常は予約が、活性化されません。セットには、すべての言語のすべての文字バリアントラベルが含まれていますが、ゾーン変異体は、前のステップで定義されていません。セット組合とセットマイナス操作は、任意の重複を排除します。
Step 7. Create IDL Package for IN using IN, {L}, {ZV} and CVall
ステップ7. IDL IN用パッケージに用い、{L}、{ZV}とCVallを作成します
In Step 7, the "IDL Package" is created using the original IDL, the associated language(s), the Zone Variant Labels, and the Reserved Variant Labels. If zone-specific additional processing or filtering is to be applied to eliminate linguistically inappropriate or other forms, it should be applied before the IDL Package is actually assembled.
ステップ7では、「IDLパッケージには、」オリジナルのIDL、関連する言語（複数可）、ゾーンバリアントラベル、および予約バリアントラベルを使用して作成されます。ゾーン固有の追加の処理またはフィルタリングが言語的に不適切又は他の形態を排除するために適用される場合IDLパッケージが実際に組み立てられる前に、それが適用されるべきです。
Step 8. Put {ZV} into zone file
ゾーンファイルにステップ8入れ{} ZV
The activated IDLs are converted via ToASCII with UseSTD13ASCIIRules [IDNA] before being placed into the zone file. This conversion results in the IDLs being in the actual IDNA ("Punycode") form used in zone files, while the IDLs have been carried in Unicode form up to this point. If ToASCII fails for any of the activated IDLs, that IDL must not be placed into the zone file. If the IDL is a subdomain name, it will be delegated.
活性化のIDLは、ゾーンファイルに置かれる前にUseSTD13ASCIIRules [IDNA]でもしToASCIIを介して変換されます。 IDLは、Unicodeで行われているが、実際のIDNA（「ピュニコード」）ゾーンファイルで使用される形態であるのIDLでこの変換結果は、この時点までに形成されます。もしToASCIIがアクティブのIDLのいずれかで失敗した場合、IDLは、ゾーンファイルの中に置かれてはならないこと。 IDLは、サブドメイン名である場合、それが委任されます。
In traditional domain administration, every Domain Name Label is independent of all other Domain Name Labels. Registration, deletion, and transfer of labels is done on a per-label basis. However, with the guidelines discussed here, each IDL is associated with specific languages, with all label variants, both active (zone) and reserved, together in an IDL Package. This quite deliberately prohibits labels that contain sufficient mixtures of characters from different scripts to make them impossible as words in any given language. If a zone chooses to not impose that restriction--that is, to permit labels to be constructed by picking characters from several different languages and scripts--then the guidelines described here would be inappropriate.
伝統的なドメイン管理では、すべてのドメイン名のラベルは、他のすべてのドメイン名のラベルとは無関係です。登録、削除、およびラベルの転送があたり、ラベルに基づいて行われます。しかし、ここで説明するガイドラインと、各IDLは一緒にIDLパッケージ内のすべてのラベルの変異体、両方の活性（ゾーン）と予約済みで、特定の言語に関連付けられています。これは非常に慎重に任意の言語の単語としてそれらを不可能にするために異なるスクリプトからの文字の十分な混合物が含まれているラベルを禁止しています。いくつかの異なる言語やスクリプトから文字を選ぶことによって構築されるようにラベルを可能にするために、ある - - ゾーンはその制限を課さないことを選択した場合は、ここで説明するガイドラインは不適切です。
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 related to the handling of disagreements requires a particular IDL to be transferred and deleted independently of the IDL Package, the conflict policy would take precedence. In such an event, the conflict policy should include a transfer or delete procedure that takes the nature of IDL Packages into consideration.
先に述べたように、IDLパッケージは、単一の単位として扱われるべきであるとIDLのすべての亜種は、単一のドメイン・ネームホルダーに属している必要があります。意見の相違の取り扱いに関連するローカルポリシーが独立してIDLパッケージの転送や削除する特定のIDLを必要とする場合、競合ポリシーが優先されます。このようなイベントでは、競合政策を考慮にIDLパッケージの性質を取る転送や削除の手続きを含める必要があります。
When an IDL Package is deleted, all of the Zone and Reserved Label Variants again become available. The deletion of one IDL Package does not change any other IDL Packages.
IDLパッケージが削除されると、ゾーンと予約ラベル変異体のすべてが再び利用可能になります。 1 IDLパッケージの削除は、他のIDLパッケージは変更されません。
Because there are active (registered) IDLs and inactive (reserved but not registered) IDLs within an IDL package, processes are required to activate or deactivate IDL variants within an IDL Package.
アクティブ（登録）のIDLと非アクティブ（予約が、登録されていない）のIDLは、IDLパッケージ内に存在するため、プロセスは、IDLパッケージ内IDLバリアントを有効または無効する必要があります。
Step 1. IN <= IDL to be activated and PA <= IDL Package
ステップ1で<= IDLが活性化されるとPA <= IDLパッケージ
Start with the IDL to be activated and the IDL Package of which it is a member.
アクティブにするIDLを起動し、それがメンバーであるIDLパッケージ。
Step 2. NP(IN) <= Nameprep processed IN
ステップ2 NP（IN）<= NAMEPREPで処理
Process the IDL through Nameprep. This step should never cause a problem, or even a change, since all labels that become part of the IDL Package are processed through Nameprep in Step 3.2 or 3.3 of the Registration procedure (section 3.2.3).
NAMEPREPてIDLを処理します。 IDLパッケージの一部となるすべてのラベルがステップ3.2または登録手順（セクション3.2.3）の3.3にNAMEPREPを通って処理されているので、このステップは、問題、あるいは変化を引き起こすことはありません。
Step 3. If NP(IN) not in CVall then stop
ステップ3 CVallにおけるNP（IN）ではないが、その後停止した場合
Verify that the Nameprep-processed version of the IDL appears as a still-unactivated label in the IDL Package, i.e., in the list of Reserved Label Variants, CVall. It might be a useful "sanity check" to also verify that it does not already appear in the zone file.
IDLのNAMEPREP-処理されたバージョンが予約されたラベルバリアント、CVallのリストには、すなわち、IDLパッケージではまだ、活性化されていないラベルとして表示されていることを確認します。また、それはすでにゾーンファイルに表示されていないことを確認するのに便利な「健全性チェック」であるかもしれません。
Step 4. CVall <= CVall set-minus NP(IN) and {ZV} <= {ZV} set-union NP(IN)
ステップ4. CVall <= CVallセットマイナスNP（IN）と{ZV} <= {ZV}設定組合NP（IN）
Within the IDL Package, remove the Nameprep-processed version of the IDL from the list of Reserved Label Variants and add it to the list of active (zone) label variants.
IDLパッケージ内に、予約されたラベルバリアントのリストからIDLのNAMEPREP-処理されたバージョンを削除し、アクティブ（ゾーン）ラベル変異体のリストに追加します。
Step 5. Put {ZV} into the zone file
ゾーンファイルにステップ5入れ{} ZV
Actually register (activate) the Zone Variant Labels.
実際にゾーンバリアントラベルを登録（アクティベート）。
Step 1. IN <= IDL to be deactivated and PA <= IDL Package
ステップ1で<= IDLを無効にすると、PA <= IDLパッケージ
As with activation, start with the IDL to be deactivated and the IDL Package of which it is a member.
活性化と同様に、不活性化されるIDL、それがメンバであるIDLパッケージで始まります。
Step 2. NP(IN) <= Nameprep processed IN
ステップ2 NP（IN）<= NAMEPREPで処理
Get the Nameprep-processed version of the name (see discussion in the previous section).
名前のNAMEPREP-処理されたバージョンを取得します（前のセクションの説明を参照）。
Step 3. If NP(IN) not in {ZV} then stop
ステップ3. {ZV}におけるNP（IS）ではないが、その後停止した場合
Verify that the Nameprep-processed version of the IDL appears as an activated (zone) label variant in the IDL Package. It might be a useful "sanity check" at this point to also verify that it actually appears in the zone file.
IDLのNAMEPREP-処理されたバージョンはIDLパッケージ中の活性化（ゾーン）ラベル変種として表示されていることを確認します。また、それが実際にゾーンファイルに表示されていることを確認するために、この時点で有用な「健全性チェック」であるかもしれません。
Step 4. CVall <= CVall set-union NP(IN) and {ZV} <= {ZV} set-minus NP(IN)
ステップ4. CVall <= CVallセット組合NP（IN）と{ZV} <= {ZV}設定マイナスNP（IN）
Within the IDL Package, remove the Nameprep-processed version of the IDL from the list of Active (Zone) Label Variants and add it to the list of Reserved (but inactive) Label Variants.
IDLパッケージ内に、アクティブ（ゾーン）ラベルバリアントのリストからIDLのNAMEPREP-処理されたバージョンを削除し、予約（ただし非アクティブ）ラベルバリアントのリストに追加します。
Step 5. Put {ZV} into the zone file
ゾーンファイルにステップ5入れ{} ZV
Since the IDL package is an atomic unit and the associated list of variants must not be changed after creation, this document does not include a mechanism for adding and deleting language associations within the IDL package. Instead, it recommends deleting the IDL package entirely, followed by a registration with the new set of languages. Zone administrators may find it desirable to devise procedures that prevent other parties from capturing the labels in the IDL Package during these operations.
IDLパッケージは、原子単位であり、変異体の関連するリストが作成後に変更されてはならないので、この文書は、IDLパッケージ内の言語の関連付けを追加および削除するためのメカニズムを備えていません。代わりに、それは言語の新しいセットの登録に続いて、完全にIDLパッケージを削除することをお勧めします。ゾーン管理者は、それが望ましいこれらの操作中にIDLパッケージのラベルをキャプチャから他の当事者を防ぐ方法を考案するかもしれません。
Language Variant Tables are subject to changes over time, and these changes may or may not be backward compatible. It is possible that updated Language Variant Tables may produce a different set of Preferred Variants and Reserved Variants.
言語バリアントテーブルは、経時的に変更することがあり、これらの変化は、下位互換性であってもなくてもよいです。更新された言語バリアントテーブルは好ましい変異体と予約変異体の異なるセットを生成することが可能です。
In order to preserve the atomicity of the IDL Package, when the Language Variant Table is changed, IDL Packages created using the previous version of the Language Variant Table must not be updated or affected.
言語バリアント表が変更された場合IDLパッケージのアトミック性を維持するために、言語バリアント表の以前のバージョンを使用して作成したIDLパッケージが更新または影響を受けてはなりません。
To provide a meaningful example, some Language Variant Tables must be defined. Assume, then, for the purpose of giving examples, that the following four Language Variant Tables are defined:
意味の例を提供するために、いくつかの言語バリアントテーブルが定義されなければなりません。次の4つの言語バリアントテーブルが定義されていることを、例を与えるために、次に、仮定します。
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.
注：これらのテーブルは、実際のテーブルの表現ではありません、そして、彼らは任意の実際の実装で使用されるのに十分なエントリが含まれていません。 IANAは、完全な例については、参照することができる実際のテーブル[IANA-LVTABLES]の自発的な登録を維持します。
a) Language Variant Table for zh-cn and zh-sg
A）の言語バリアント表ZH-CNと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
（一般GBKとして知られている）参照1 CP936文献2 zVariant、zTradVariant、zSimpVariant簡易文字テーブル（簡易カラム）参考に存在する4 zSimpVariant Unihan.txtにおける[UNIHAN参考5変異体のUnihan.txt [UNIHAN参考3一覧GB2312、一般的な単純化された漢字
Version 1 20020701 # July 2002
バージョン1 20020701＃2002年7月
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
56E2（1）、56E2（5）; 5718（2）＃球、球、円、質量、塊5718（1）、56E2（4）、56E2（2）、56E3（2）＃球、球、円、質量、塊60F3（1）、60F3（5）。 6559（2）＃ティーチ;＃、と思う推測し、計画、654E（1）を検討し、6559（5）
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 together
6559（1）、6559（5）、654E（2）＃ティーチ、クラス6DF8（1）; 6E05（5）; 6E05（2）＃クリア6E05（1）; 6E05（5）; 6DF8（2）＃クリア、純粋な、きれい。静か771E（1）771F（5）; 771F（2）＃実数、実際の、真の、本物771F（1）771F（5）; 771E（2）＃実数、実際の、真の、本物8054（1）。 8054（3）; 806F（2）＃参加、接続。会合、味方806F（1）、8054（3）、8054（2）、8068（2）＃接続、加入。会合、味方96C6（1）、96C6（5）。 ＃組み立て、一緒に集めます
b) Language Variant Table for zh-tw
ZH-TW用B）言語バリアントテーブル
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
（一般BIG5として知られている）参照1 CP950文献2 zVariant、zTradVariant、zSimpVariant zTradVariant Unihan.txt簡略化キャラクタテーブル（従来のカラム）参照4のUnihan.txt文献3一覧
Version 1 20020701 # July 2002
バージョン1 20020701＃2002年7月
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 together
5718（1）、5718（4）、56E2（2）、56E3（2）＃球、球、円、質量、塊60F3（1）、60F3（1）。 ＃検討し、計画を推測し、考える6559（1）; 6559（1）; 654E（2）＃ティーチ、クラス6E05（1）; 6E05（1）; 6DF8（2）＃明確で、純粋で、きれい。平和771F（1）; 771F（1）; 771E（2）＃の本当の、実際の、本当の、本物の806F（1）; 806F（3）; 8054（2）、8068（2）＃接続し、参加します。会合、味方96C6（1）、96C6（1）。 ＃組み立て、一緒に集めます
c) Language Variant Table for ja
JAのためのC）言語バリアント表
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
JIS X0208に存在する基準1 CP932（一般にシフトJISとしても知られる）参照2 zVariant Unihan.txtにおける基準3変異体は、一般的に使用される漢字
Version 1 20020701 # July 2002
バージョン1 20020701＃2002年7月
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 together
5718（1）、5718（3）、56E3（2）＃球、球、円、質量、塊60F3（1）、60F3（3）。 ＃だと思い、推測、計画、654E（1）を検討し、6559（3）; 6559（2）＃（1）6559を教える; 6559（3）; 654E（2）＃ティーチ、クラス6DF8（1）; 6E05（3 ）; 6E05（2）＃クリア6E05（1）; 6E05（3）; 6DF8（2）＃、明確な純粋な、クリーン。平和771E（1）; 771E（1）; 771F（2）＃の本当の、実際の、本当の、本物の771F（1）; 771F（1）; 771E（2）＃の本当の、実際の、本当の、本物の806F（1）; 806F（1）、8068（2）＃接続し、参加します。会合、味方96C6（1）、96C6（3）。 ＃組み立て、一緒に集めます
d) Language Variant Table for ko
KOのためのd）に言語バリアント表
Reference 1 CP949 (commonly known as EUC-KR)
基準1 CP949（一般EUC-KRとも呼ばれます）
Reference 2 zVariant and K-source in Unihan.txt
Unihan.txtにおける基準2 zVariant及びK-ソース
Version 1 20020701 # July 2002
バージョン1 20020701＃2002年7月
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 together
5718（1）、5718（1）、56E3（2）＃球、球、円、質量、塊60F3（1）、60F3（1）。 ＃だと思い、推測、計画、654E（1）考える; 654E（1）; 6559（2）＃は、（1）6DF8を教える; 6DF8（1）; 6E05（2）＃明確771E（1）; 771E（1）; 771F（2）＃実数、実際の、真の、本物806F（1）806F（1）、8068（2）＃接続、加入。会合、味方96C6（1）、96C6（1）。 ＃組み立て、一緒に集めます
Example 1: IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4* {L} = {zh-cn, zh-sg, zh-tw}
実施例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)
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)}
{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}
実施例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)}
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)}
呼び出し= {（UO + 6E05 U + 771E U + 6559）、（U + 6E05 U + 771E U + 654E）、（U + 6E05 U + 771F U + 654E）、（U + 6DF8 U + 771E + 6559 U） 、（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}
実施例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*
NP（IN）=（U + 6E05 U + 771F U + 6559）* qing2 zhen1 jiao4 *
Invalid registration because U+6E05 is invalid in L = ko
無効な登録のU + 6E05は、L = KOで無効であるため、
Example 4: IDL = (U+806F U+60F3 U+96C6 U+5718) *lian2 xiang3 ji2 tuan2* {L} = {zh-cn, zh-sg, zh-tw}
実施例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)
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 + + 5718 96C6 U）
Example 5: IDL = (U+8054 U+60F3 U+96C6 U+56E2) *lian2 xiang3 ji2 tuan2* {L} = {zh-cn, zh-sg}
実施例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)}
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 + 96C6 U + 5718 U）}
Example 6: IDL = (U+8054 U+60F3 U+96C6 U+56E2) *lian2 xiang3 ji2 tuan2* {L} = {zh-cn, zh-sg, zh-tw}
実施例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-tw
NP（IN）=（U + 8054 U + 60F3 U + 96C6 U + 56E2）無効登録U + 8054は、L = ZH-TWに無効であるため、
Example 7: IDL = (U+806F U+60F3 U+96C6 U+5718) *lian2 xiang3 ji2 tuan2* {L} = {ja,ko}
実施例7：IDL =（U + U + 806F + 96C6 60F3 U U + 5718）* lian2 xiang3 JI2 tuan2 * {L} = {I}
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)}
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 + + 5718 96C6 U）}
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)}
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）}
The formal syntax for the Language Variant Table is as follows, using the IETF "ABNF" metalanguage [ABNF]. Some comments on this syntax appear immediately after it.
IETF「ABNF」メタ言語[ABNF]を使用して、次のように言語バリアント表のための正式な構文は次のとおりです。この構文上のいくつかのコメントには、その直後に表示されます。
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
LanguageVariantTable = 1 * ReferenceLine VersionLine 1 * EntryLine ReferenceLine = "参考" SP REFNO SP RefDesciption [コメント] CRLF REFNO = 1 * DIGITのRefDesciption = * [VCHAR] VersionLine = "バージョン" SP VersionNoのSP VersionDate [コメント] CRLF VersionNoの= 1 * DIGIT VersionDate = YYYYMMDD EntryLine = VariantEntry /コメント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 = "#" *VCHAR
VariantEntry = ValidCodePoint ";" PreferredVariant ";" CharacterVariant [コメント] ValidCodePoint =コードポイントRefList = REFNO 0 *（ "" REFNO）PreferredVariant = CodePointSet 0 *（ "" CodePointSet）CharacterVariant = CodePointSet 0 *（ "" CodePointSet）CodePointSet =コードポイント0 *（SPコードポイント）コードポイント= 4 * 8DIGIT [ "（" Reflist "）"]コメント= "＃" * VCHAR
YYYYMMDD is an integer, in alphabetic form, representing a date, where YYYY is the 4-digit year, MM is the 2-digit month, and DD is the 2-digit day.
YYYYMMDDは、YYYYは4桁の年の日付を表すアルファベットの形で、整数であり、MMは2桁の月、DDは2桁の日です。
Any lines starting with, or portions of lines after, the hash symbol("#") are treated as comments. Comments have no significance in the processing of the tables; nor are there any syntax requirements between the hash symbol and the end of the line. Blank lines in the tables are ignored completely.
任意で始まる行または行の部分は後に、ハッシュ記号（「＃」）は、コメントとして扱われます。コメントは、テーブルの処理中に意味を持ちません。でも、ハッシュシンボルとラインの端部との間のいずれかの構文の要件があります。表中の空白行は完全に無視されます。
Every language should have its own Language Variant Table provided by a relevant group, organization, or other body. That table will normally be based on some established standard or standards. The group that defines a Language Variant Table should document references to the appropriate standards at the beginning of the table, tagged with the word "Reference" followed by an integer (the reference number) followed by the description of the reference. For example:
すべての言語は、関連するグループ、組織、または他の身体が提供する独自の言語バリアントテーブルを持つ必要があります。そのテーブルは、通常、いくつかの確立された標準や規格に基づいて行われます。参照の説明に続いて整数（参照番号）が続く単語「リファレンス」でタグ付けされたテーブルの先頭に適切な標準への参照を文書化する必要があり言語バリアントテーブルを定義するグループ、。例えば：
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 Hanzi
（一般GBKとして知られている）参照1 CP936文献2 zVariant、zTradVariant、簡易文字テーブル（簡易カラム）参照GB2312に存在Unihan.txt文献5バリアント、共通の簡略化された漢字4 zSimpVariantのUnihan.txt文献3一覧zSimpVariant
Each Language Variant Table must have a version number and its release date. This is tagged with the word "Version" followed by an integer then followed by the date in the format YYYYMMDD, where YYYY is the 4-digit year, MM is the 2-digit month, and DD is the 2-digit day of the publication date of the table.
各言語バリアント表は、バージョン番号とそのリリース日を持っている必要があります。これはその後、YYYYは4桁の年であるYYYYMMDD形式で日付が続く整数が続く単語「バージョン」でタグ付けされ、MMは2桁の月、DDは2桁の日ですテーブルの発行日。
Version 1 20020701 # July 2002 Version 1
バージョン1 20020701＃2002年7月第1版
The table has three columns, separated by semicolons: "Valid Code Point"; "Preferred Variant(s)"; and "Character Variant(s)".
テーブルには、セミコロンで区切られた3つの列、持っている：「有効なコードポイントを」; "好ましい変形（S）";そして「文字変種」。
The "Valid Code Point" is the subset of Unicode characters that are valid to be registered.
「有効なコードポイントは、」登録する有効なUnicode文字のサブセットです。
There can be more than one Preferred Variant; hence there could be multiple entries in the "Preferred Variant(s)" column. If the "Preferred Variant(s)" column is empty, then there is no corresponding Preferred Variant; in other words, the Preferred Variant is null, there is no corresponding preferred variant codepoint, and no processing to add labels for preferred variants occurs." Unless local policy dictates otherwise, the procedures above will result in only those labels that reflect the valid code point being activated (registered) into the zone file.
複数の好ましい変形が存在することができます。したがって、「好ましい変形（S）」の欄に複数のエントリがあるかもしれません。 「好ましい変形（S）」の欄が空の場合は、該当する好ましい変形は存在しません。言い換えれば、好ましい変形がnullの場合、そこには、対応する好ましい変形コードポイントはありません、そして好ましい変形のためにラベルを追加する処理は発生しません。」ローカルポリシーは、別段の指示がない限り、上記の手順は、有効なコードを反映したラベルのみになりますポイントは、ゾーンファイルに（登録）活性化されます。
The "Character Variant(s)" column contains all Character Variants of the Code Point. Since the Code Point is always a variant of itself, to avoid redundancy, the Code Point is assumed to be part of the "Character Variant(s)" and need not be repeated in the "Character Variant(s)" column.
「文字変種」欄は、コードポイントのすべての文字バリアントが含まれています。コードポイントは、常に冗長性を回避するために、自身の変種であるため、コードポイントは、「文字変種」の一部とみなされ、「文字変種」欄に繰り返す必要はありません。
If the variant in the "Preferred Variant(s)" or the "Character Variant(s)" column is composed of a sequence of Code Points, then sequence of Code Points is listed separated by a space.
「好ましい変形（S）」または「文字変種」列の変異体は、コードポイントのシーケンスで構成されている場合、コードポイントのシーケンスは、スペースで区切られ記載されています。
If there are multiple variants in the "Preferred Variant(s)" or the "Character Variant(s)" column, then each variant is separated by a comma.
複数の変異体「は、好ましい変法（複数可）」または「文字バリアント（S）」の欄に存在する場合、各変異体は、カンマで区切られています。
Any Code Point listed in the "Preferred Variant(s)" column must be allowed by the rules for the relevant language to be registered. However, this is not a requirement for the entries in the "Character Variant(s)" column; it is possible that some of those entries may not be allowed to be registered.
「好ましい変形（S）」の欄に記載されている任意のコードポイントを登録する関連言語の規則によって許可されなければなりません。しかしながら、これは、「文字変種」カラムのエントリのための必要条件ではありません。これらのエントリの一部を登録することが許可されない可能性があります。
Every Code Point in the table should have a corresponding reference number (associated with the references) specified to justify the entry. The reference number is placed in parentheses after the Code Point. If there is more than one reference, then the numbers are placed within a single set of parentheses and separated by commas.
テーブル内のすべてのコードポイントは、エントリを正当化するために指定された対応する参照番号を（参考文献に関連する）必要があります。参照番号は、コードポイントの後の括弧内に置かれています。複数の参照がある場合、番号は括弧の単一のセット内に置かれ、コンマで区切られています。
As discussed in the Introduction, substantially-unrestricted use of international (non-ASCII) characters in domain name labels may cause user confusion and invite various types of attacks. In particular, in the case of CJK languages, an attacker has an opportunity to divert or confuse users as a result of different characters (or, more specifically, assigned code points) with identical or similar semantics. These Guidelines provide a partial remedy for those risks by supplying a framework for prohibiting inappropriate characters from being registered at all and for permitting "variant" characters to be grouped together and reserved, so that they can only be registered in the DNS by the same owner. However, the system it suggests is no better or worse than the per-zone and per-language tables whose format and use this document specifies. Specific tables, and any additional local processing, will reflect per-zone decisions about the balance between risk and flexibility of registrations. And, of course, errors in construction of those tables may significantly reduce the quality of protection provided.
はじめに述べたように、ドメイン名のラベル国際（非ASCII）文字の実質的に無制限の使用は、ユーザーの混乱を引き起こし、攻撃のさまざまなタイプを招くことがあります。具体的には、CJK言語の場合には、攻撃者が迂回または同一または類似のセマンティクスを持つ異なる文字（又は、より具体的には、割り当てられたコードポイント）の結果として、ユーザーが混乱する機会を有します。これらのガイドラインはすべてに登録されることから、不適切な文字を禁止するためのフレームワークを供給することによって、彼らは、同じ所有者がDNSに登録することができるように、一緒にグループ化され、予約する「変異体」の文字を許可するそれらのリスクのための部分的な救済を提供します。しかし、それは示唆しているシステムには良くも悪くもそのフォーマットは、この文書の指定を使用し、ゾーンごとおよび言語のテーブルよりもありません。特定のテーブル、および任意の追加のローカル処理は、登録の危険性と柔軟性のバランスに関するゾーンごとの意思決定に反映されます。そして、もちろん、これらのテーブルの建設中のエラーを大幅に提供される保護の品質を低下させる可能性があります。
As a convenience to the reader, this section lists all of the special terminology used in this document, with a pointer to the section in which it 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.17
コードポイント2.1.7コードポイントバリアント2.1.14 FQDN 2.1.3ホスト名2.1.1 IDL 2.1.18 IDN 2.1.1国際化ドメインラベル2.1.2 ISO / IEC 10646 2.1.6ラベル文字列2.1.10 IDLパッケージ2.1.2言語名コード2.1.5言語バリアント表2.1.11 LDHサブセット2.1.1優先コードポイント2.1.13好ましい変形2.1.13好ましい変形ラベル2.1.15登録2.1.4予約2.1.18 RFC3066 2.1.5表2.1.11 UCS 2.1.6 Unicodeの文字2.1.7 Unicode文字列2.1.8有効なコードポイント2.1.12バリアント表2.1.11ゾーンバリアント2.1.17
The authors gratefully acknowledge the contributions of:
作者は感謝の貢献を認めます：
- V. CHEN, N. HSU, H. HOTTA, S. TASHIRO, Y. YONEYA, and other Joint Engineering Team members at the JET meeting in Bangkok, Thailand.
- V. CHEN、N. HSU、H.堀田、S.田代、Y.米谷、バンコク、タイのJET会議で他の共同エンジニアリングチームのメンバー。
- Yves Arrouye, an observer at the JET meeting in Bangkok, for his contribution on the IDL Package.
- イヴArrouye、IDLパッケージの彼の貢献のためのバンコクでJET会議、で観測。
- Those who commented on, and made suggestions about, earlier versions, including Harald ALVESTRAND, Erin CHEN, Patrik FALTSTROM, Paul HOFFMAN, Soobok LEE, LEE Xiaodong, MAO Wei, Erik NORDMARK, and L.M. TSENG.
- 上のコメント、およびハラルドALVESTRAND、エリンCHEN、パトリックFALTSTROM、ポール・ホフマン、Soobok LEE、LEE暁東、MAO魏、エリックNordmarkと、およびL.M. TSENGを含む以前のバージョン、について提案をした人たち。
[ABNF] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]クロッカー、D.、およびP. Overell、編、 "構文仕様のための増大しているBNF：ABNF"。、RFC 2234、1997年11月。
[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.
[STD13] Mockapetris、P.、 "ドメイン名の概念と設備" STD 13、RFC 1034年11月1987年Mockapetris、P.、 "ドメイン名の実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages," BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H.、 "言語識別のためのタグ、" BCP 47、RFC 3066、2001年1月。
[IDNA] Faltstrom, P., Hoffman, P. and A. M. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[IDNA] Faltstrom、P.、ホフマン、P.およびA. M.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
[PUNYCODE] Costello, A.M., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[PUNYCODE]コステロ、午前、 "ピュニコード：アプリケーションにおける国際化ドメイン名のUnicodeのブートストリングのエンコード（IDNA）"、RFC 3492、2003年3月。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
【STRINGPREP]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、RFC 3454、2002年12月。
[NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[NAMEPREP]ホフマン、P.とM.ブランシェ、 "NAMEPREP：国際化ドメイン名のためのstringprepプロフィール（IDN）"、RFC 3491、2003年3月。
[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.
[IS10646] ISO / IEC JTC1 / SC2 / WG2、ワークアイテムJTC1.02.18（ISO / IEC 10646）の製品。 2000（E）ISO / IEC 10646-2として公開アーキテクチャと基本多言語面、およびパート2、カバー：パート1、ISO / IEC 10646- 1として公開：それはマルチパートの標準である2001（E）、カバーを補足（追加）面。
[UNIHAN] Unicode Han Database, Unicode Consortium ftp://ftp.unicode.org/Public/UNIDATA/Unihan.txt.
[UNIHAN] Unicodeの漢データベース、ユニコードコンソーシアム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.
[UNICODE]ユニコードコンソーシアム、 "Unicode規格バージョン3.0、" ISBN 0-201-61633-5。 Unicode規格附属書は、＃28（http://www.unicode.org/unicode/reports/tr28/）はIDNAと、この文書のための決定的であるUnicode標準のバージョン3.2を定義します。
[ISO7098] ISO 7098;1991 Information and documentation Romanization of Chinese, ISO/TC46/SC2.
[ISO7098] ISO 7098;中国語、ISO / TC46 / SC2の1991年の情報とドキュメントローマ字表記。
[IANA-LVTABLES] Internet Assigned Numbers Authority (IANA), IDN Character Registry. http://www.iana.org/assignments/idn/
[IANA-LVTABLES]インターネット割り当て番号機関（IANA）、IDN文字レジストリ。 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/.
[IDN-WG] IETF国際化ドメイン名ワーキンググループでは、今、@ ops.ietf.org IDN、ジェームズ・ハンセン、マルク・ブランシェ、共同議長、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
[UDRP] ICANN、 "統一ドメイン名紛争処理方針"、1999年10月、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.
[ISO639] "ISO 639：1988（E / F）言語の名前の表現のためのコード"、標準化、第1版、1988年4月1日のための国際機関。
The formal responsibility for this document and the ideas it contains lie with K. Koniski, K. Huang, H. Qian, and Y. Ko. These authors are listed on the first page as authors of record, and they are the appropriate the long-term contacts for questions and comments on this RFC. On the other hand, J. Seng, J. Klensin, and W. Rickard served as editors of the document, transcribing and translating the ideas of the four authors and the teams they represented into the current written form. They were the primary contacts during the editing process, but not in the long term.
この文書やアイデアのための正式な責任は、それがK. Koniski、K.黄、H.銭、およびY.コで嘘が含まれています。これらの著者は、レコードの作成者として、最初のページに記載されている、と彼らはこのRFCに関する質問やコメントについて長期的接点適切です。一方、J.セン、J. Klensin、およびW.リカードは、4人の著者のアイデアや、彼らが現在の書面に代表されるチームを転写し、翻訳、文書の編集者を務めていました。彼らはなく、長期的には、編集プロセス中にプライマリ連絡しました。
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
電話：+81 49-278-7313 Eメール：konishi@jp.apan.net
Kenny HUANG TWNIC 3F, 16, Kang Hwa Street, Taipei Taiwan
ケニーHUANG TWNIC 3F、16、カンファ街、台北、台湾
Phone: 886-2-2658-6510 EMail: huangk@alum.sinica.edu
電話：886-2-2658-6510 Eメール：huangk@alum.sinica.edu
QIAN Hualin CNNIC No.6 Branch-box of No.349 Mailbox, Beijing 100080 Peoples Republic of China
QIAN Hualin CNNIC第6号支店・ボックスNo.349メールボックスの、中国の北京100080人民共和国
EMail: Hlqian@cnnic.net.cn
メールアドレス：Hlqian@cnnic.net.cn
KO YangWoo PeaceNet Yangchun P.O. Box 81 Seoul 158-600 Korea
KO YangWoo PeaceNet陽春私書箱ボックス81ソウル158から600韓国
EMail: yw@mrko.pe.kr
メールアドレス：yw@mrko.pe.kr
James SENG 180 Lompang Road #22-07 Singapore 670180 Phone: +65 9638-7085
ジェームズSENG 180中空ロード＃22から07シンガポール670180電話：+65 9638から7085
EMail: jseng@pobox.org.sg
メールアドレス：jseng@pobox.org.sg
John C KLENSIN 1770 Massachusetts Avenue, No. 322 Cambridge, MA 02140 U.S.A.
ジョン・C KLENSIN 1770マサチューセッツアベニュー、第322ケンブリッジ、MA 02140 U.S.A.
EMail: Klensin+ietf@jck.com
メールアドレス：Klensin+ietf@jck.com
Wendy RICKARD The Rickard Group 16 Seminary Ave Hopewell, NJ 08525 USA
ウェンディリカードザ・リカードグループ16神学校アベニューホープウェル、ニュージャージー08525 USA
EMail: rickard@rickardgroup.com
メールアドレス：rickard@rickardgroup.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利、ライセンスおよび制限があり、そこに記載された以外、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78および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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。