[要約] RFC 3743は、中国語、日本語、韓国語の国際化ドメイン名（IDN）の登録と管理のためのJETガイドラインです。このRFCの目的は、これらの言語でのIDNの正確な登録と適切な管理を確保することです。
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
国際化されたドメイン名（IDN）登録および中国語、日本、韓国語の管理ガイドライン（JET）ガイドライン
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.
Copyright（c）The Internet Society（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）を祝福します。ここで説明する言語バリアントテーブルメカニズムにより、ジェットは言語ベースのキャラクターバリアントの好みを強制することができ、独自のポリシー施行にバリアントテーブルを使用したい人のために模範を示します。
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は、この例に従って、ジェットの勤勉さを例にとることを奨励しています。彼らの例に従うために、登録当局は政策を明確にし、執行のための適切な手順とメカニズムを開発し、2つの関係を文書化する必要があるかもしれません。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 Internationalizationは、多くのインターネットプロトコルとアプリケーションにも影響を及ぼし、技術管理とサービスの観点から複雑な追加のレイヤーを作成します。元の小さな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をいかなるリスクにしないという目標を持って、ユニコード文字列のエンコードとデコードをドメイン名システム（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. アプリケーションのホスト名[IDNA] 2.国際化された文字列の準備[StringPrep] 3.国際化ドメイン名のStringPrepプロファイル[NamePrep] 4. Punycode [Punycode]
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は、IDNSとして使用することを目的とした文字列を正規化および変換します。組み合わせて、4つは、ケースマッピングの実行、深刻な問題を引き起こすキャラクターの違いの排除、一致の指定（平等）など、国際化に必要な最小関数を提供します。また、結果のユニコードコードポイントと、実際の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で使用される文字列のセマンティクスが領域固有の定義、解釈、およびセマンティクスが含まれます。ユニコード文字列は、特定の言語の名前、単語、またはフレーズとして特定の意味を持つ場合がありますが、その意味は、国、地域、文化、または文字列が使用されるその他のコンテキストによって異なる場合があります。また、同じ文字の一部またはすべてを共有する異なる言語で異なる解釈がある場合があります。したがって、個々のゾーンとゾーン管理者は、自分の環境内で、混乱の可能性、および参照の不安定性を減らすために制限と手順を課す必要があると判断する場合があります。
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.
この文書は、CNNIC、TWNIC、KRNIC、およびJPNICのメンバーと他の個々の専門家で構成されるグループである共同工学チーム（JET）の努力です。レジストリオペレーターとレジストラを含むがこれらに限定されないゾーン管理者にガイドラインを提供し、中国語、日本、韓国のスクリプトから描かれた文字を含むドメイン名の管理に関するすべてのドメイン名保有者の情報を含みません。他の言語グループは、これらのガイドラインが役立つ場合は、必要に応じて独自のガイドラインを作成することをお勧めします。
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：「IDN」という用語には、さまざまな用途があります。（a）「国際化されたドメイン名」の略語として。（b）ASCIIに表示されない文字、特にドメイン名に推奨されるASCIIのサブセットではない少なくとも1つのラベルを含む完全に適格なドメイン名として（いわゆる「ホスト名」または「LDH」サブセット、RFC10355を参照[std13]）;（c）ASCII以外の少なくとも1つの文字を含むドメイン名のラベルとして。（d）nameprepで処理されるユニコード文字列として。（e）NamePrepからの出力である文字列として。（f）NamePrepとPunycodeへの変換の両方を処理した結果である文字列として。（g）このドキュメントの用語におけるIDN（より適切に、IDL）パッケージの略語として。（h）IETF IDNワーキンググループの略語として。（g）ICANN IDN委員会の略語として。（h）他の企業/組織での他のIDN活動の立場として。
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.
潜在的な混乱のため、このドキュメントでは、「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）名を含むすべてのラベルが明示的に含まれています。これに関連して、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.
登録：このドキュメントでは、「登録」という用語とは、潜在的なドメイン名保有者が、ドメイン内の個々の名前として、または別のドメイン名ホルダーからのサブドメイン代表としてラベルに配置することを要求するプロセスを指します。登録が成功した場合、ラベルまたは委任の記録は関連するゾーンファイルに配置されます。より具体的には、「アクティブ化」または「アクティブ」になり、追加のIDLは「IDLパッケージ」の一部として予約される場合があります。（以下を参照してください）。ここに示されているガイドラインは、すべてのゾーン、任意の階層レベルで推奨されます。このレベルでは、CJK文字が最初または2番目のレベルでドメインだけでなく表示されます。
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：International Standard Universal Multis-OCTETコード化された文字セット（「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 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.
Unicode文字：「Unicode文字」という用語は、Unicode Standardバージョン3.2 [Unicode]（したがってISO/IEC 10646から）から選択された文字を参照して、ここで使用されます。このドキュメントでは、文字は自分の位置または「コードポイント」によって識別されます。たとえば、Notation U 12ABは、Unicode 3.2テーブルの位置12AB（16進数）の文字を示します。FFFFを超える位置の文字、つまり、16ビット以上を表すために必要とする場合、平面1の位置12ABの文字のU 112ABなど、5〜8文字の文字列が使用されます。
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文字は、中国語、日本、または韓国語で一般的に使用されている文字です。これを含むが、Unicode標準でASCII（U 0020からU 007F）、Han Ideographs（U 3400からU 9FAFおよびU20000からu 2a6df）、bopomofo（u 3100からu 312fおよびu 31a0からu 31bf）、kana（u 3040からu 30ff）、jamo（u 1100〜11ffおよびu 3130からu 318f）、hangul（u ac00 to u 318f）D7AFおよびU 3130からU 318F）、およびそれぞれの互換性フォーム。特定のゾーンで許可されている特定の文字は、そのゾーンの言語バリアントテーブルで指定されています。
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に入力する（登録）する優先または文字バリアントラベル。つまり、関連するゾーンのゾーンファイルに。ゾーンバリアントは、ゾーンバリアントラベルまたはアクティブ（またはアクティブ化された）ラベルとも呼ばれます。
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とそのバリアントラベルは、単一の原子単位を形成します。
2.2. Notation for Ideographs and Other Non-ASCII CJK Characters.
2.2. 表意図およびその他の非ASCII CJK文字の表記。
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バージョンの読者の利便性、および中国語の文字を認識して区別することに精通していない一部の読者のために、これらの文字のほとんどの使用は、単一コードコードポイントと、それに対応する中国のローマ化を伴う「アスタリスクタグ」の両方に関連付けられます[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.
ゾーン管理者は、制御下にあるドメイン名ラベルの管理を担当します。ゾーン管理者は、一般的なコードであろうとカントリーコードであろうと、典型的なセカンドレベルまたは第3レベルのドメインなどの小規模なドメイン（TLD）などの大きなゾーンの責任を負う可能性があります。多くの場合、大きなゾーンは、より小さなカウンターパートよりも複雑です。ただし、追加、削除、委任、ドメイン名保有者間のゾーンの転送などの実際の技術管理タスクは、すべてのゾーンで類似しています。
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つとしてリストされています。優先順位と「権利」を管理するポリシーが既に実施されている場合、このドキュメントのFCFの使用をゾーンに固有のポリシーに置き換えることにより、ここでガイドラインを使用できます。ここでのガイドラインのいくつかは、ラベルの権利を決定するための他のポリシーに適用できない場合があります。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.
(a) 一部のユニコード文字列は、多くの言語やスクリプトからの文字の品揃えで構成される純粋な識別子である可能性がありますが、IDLは言語で特定の意味を持つ「単語」または「名前」または「フレーズ」である可能性があります。ゾーン管理は登録基準として「意味」を必要とする場合と必要でない場合がありますが、意味はユーザーの混乱を回避するための有用なツールであることが証明される可能性があります。
Each IDL to be registered should be associated administratively with one or more languages.
登録される各IDLは、1つ以上の言語に管理上関連する必要があります。
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が言語に関連付けられている場合、その言語の有効なサブセット内にないユニコード文字を含めることは許可されていません。
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.
(c) IDLが言語に関連付けられている場合、優先バリアントに加えて、それに関連する言語に依存する文字バリアントがある場合があります。これらのバリアントは、元のラベル文字列のコードポイントとの潜在的な混乱の原因です。その結果、それらから生成されたラベルは、他の名前、単語、またはフレーズの登録者には利用できないはずです。
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.
ゾーンは、それらがどのようにアクティブになるかについてのローカルポリシーを確立する必要があります。具体的には、特にトップレベルでの多くのゾーンは、「CNAME」のDNSエイリアス、特に名前サーバー委任記録（NSレコード）を指すCNAMEの使用を禁止または制限しています。また、DNSルックアップに導入できる再帰のために、単一の名前（「DNAME RECORDS」）ではなく、ドメイン階層の長期エイリアスの長期使用が問題と見なされます。
(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.
(d) IDLが「名前」、「単語」、または「フレーズ」である場合、関連する言語に応じて文字バリアントがあります。さらに、これらのキャラクターバリアントの1つ以上は、言語、政治的、またはその他の理由で他のバリアントよりも頻繁に使用されます。
These more commonly used variants are distinguished from ordinary Character Variants and are known as Preferred Variant(s) for the particular language.
これらのより一般的に使用されるバリアントは、通常の文字バリアントと区別され、特定の言語の優先バリアントとして知られています。
To increase the likelihood of correct and predictable resolution of the IDN by end users, all labels generated from the Preferred Variants for the associated language(s) should be resolvable.
エンドユーザーによる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) 1つ以上の言語に関連付けられた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パッケージは登録時に作成され、Atomic：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.
3.1で説明されている原則に準拠するために、このドキュメントでは、言語バリアントテーブルとIDLパッケージの2つの概念を紹介します。これらは次の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文字のサブセット（「有効なコードポイント」）が含まれています。これは、登録されるIDLを確認するために使用されます（3.1bを参照）。後述する登録手順のように、この列は、処理される提案されたIDLに表示される文字を調べるためのインデックスとして使用されます。特定の言語のテーブル内の有効なコードポイントのコレクションは、その言語のスクリプトを定義するものと考えることができますが、たとえばCJKの文字を持つ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（「有効なコードポイント」）の対応するユニコード文字の優先バリアントが含まれています。これらのバリアント文字は、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番目の列には、対応する有効なコードポイントの文字バリアントが含まれています。これらは、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テーブルの数値文字番号として表され、オプションで括弧内の参照が続く1つ以上のコードポイントで構成されています。最初の列、または有効なコードポイントには、特定の行で指定されたコードポイントが1つしかない場合があります。他の列には複数の列がある場合があります。
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
(2) IDLに関連する言語
(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
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が必要とするすべてのマッピングと標準化を適用して、nameprep-forcessedバージョンのinの生成します。
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は、NAMEPREPを使用して、IDNAを使用するためにグローバルに必要な正常化と除外を適用することにより処理されます。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）<=ステップ2.2で処理されたnameprep。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-Processed IDLのすべてのコードポイントが、言語の文字バリアントテーブルの「有効なコードポイント」列で許可されているコードポイントであることを確認することにより行われます。これは、登録で指定された他の言語（したがって、言語バリアントテーブル）で繰り返されます。1つ以上のコードポイントが有効でない場合、登録プロセスが終了します。
Step 3.2. PV(IN,AL) <= Set of available Nameprep-processed Preferred
Variants of NP(IN) in AL
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 IDL and any remaining variants will be registered (see steps 5 and 8 below).
ステップ3.2 NAMEPREP処理IDLの各コードポイントの「優先バリアント」列にリストされているすべての可能なバリアントの組み合わせ（以下のステップ3.2aを参照）を実行することにより、IDLの優先バリアントラベルのリストを生成します。生成された優先バリアントラベルは、NamePrepを使用して処理する必要があります。好みのバリアントラベルでNAMEPREP処理が失敗した場合（これは、テーブルに配置される前に優先バリアントがNAMEPREPを使用して処理される場合に発生する可能性が低い）、そのバリアントラベルはリストから削除されます。次に、リスト内の残りの優先バリアントラベルをチェックして、既に登録されているか予約されているかを確認します。登録または予約されている場合は、紛争解決ポリシーが適用されます。一般に、これは、ポリシーがそのような登録を防止しない限り、当初要求されたIDLが登録されるのを妨げません。たとえば、FCFSが適用される場合、競合するバリアントはリストから削除されますが、元々要求された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と組み合わせて、バリアントラベルのセットを形成する必要があります。概念的には、オリジナルのネームプレップ処理されたIDLから始まり、各キャラクターを順番に調べます。対応する優先バリアントまたはキャラクターのバリアントがある文字が遭遇した場合、元のバリアントポイントを使用して新しいバリアントラベルが生成されます。バリアントラベルが元のIDLの前半に登場した文字の処理の結果としてすでに存在する場合、置換もそれらに作成され、追加の生成されたバリアントラベルが生成されます。この操作は、優先バリアント（ステップ3.2）および文字バリアント（ステップ3.3）に対して個別に繰り返されます。もちろん、元の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.
このプロセスは、非常に多数のラベルを生成することがあります。たとえば、元のIDLの2人の文字のみが優先バリアントに関連付けられている場合、それらの最初の文字に3つの優先バリアントがあり、2番目に2つのバリアントがある場合、1つは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（コードポイントfのバリエーション）nsc = nsc set-union（コードポイントvの文字列）ループの端else subcom = comboning（sstr）各v in（コードポイントのバリエーション（sstr）f）subcom nsc = nsc set-union（最初のコードポイントvの文字列の後に文字列scの文字列）の各scについてループのendifの端端
Return NSC
NSCを返します
Step 3.3. CV(IN,AL) <= Set of available Nameprep-processed Character
Variants of NP(IN) in AL
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処理が失敗した場合、そのバリアントラベルはリストから削除されます。残りの文字バリアントラベルは、登録または予約されていないことを確認するためにチェックされます。1つ以上の場合、紛争解決ポリシーが適用されます。優先バリアントラベルと同様に、以前の登録者に有利に解決された競合は、一般に、IDLが登録されないことも、以下のステップ6で残りのバリアントも予約されないことを防ぎません。
Step 3.4. End of Loop Step 4. Let PVall be the set-union of all PV(IN,AL)
ステップ3.4。ループの終わりステップ4. pvallをすべてのPVのセットユニオンとします（in、al）
Step 4 generates the Preferred Variants Label for all languages. In this step, and again in step 6 below, the zone administrator 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)
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. cvallをすべてのCV（in、al）、set-minus {zv}のセットユニオンとします。
Step 6 generates the Reserved Label Variants (the Character Variant Label set). These labels are normally reserved but not activated. The set includes all Character Variant Labels for all languages, but not the Zone Variants 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
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はゾーンファイルで使用される実際のIDNA（「Punycode」）フォームになり、IDLはこの時点までユニコード形式で運ばれています。有効化されたIDLのいずれかでTOASCIIが失敗した場合、その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
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
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.3でNAMEPREPを使用して処理されるため、このステップは問題や変更を引き起こすことはありません（セクション3.2.3）。
Step 3. If NP(IN) not in CVall then stop
ステップ3. np（is）が呼び出しない場合は停止します
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-Processedバージョンが、IDLパッケージ、つまり予約されたラベルバリアントのリストであるCvallにまだ不活性化されたラベルとして表示されることを確認します。また、ゾーンファイルにまだ表示されていないことを確認するのに役立つ「正気チェック」かもしれません。
Step 4. CVall <= CVall set-minus NP(IN) and {ZV} <= {ZV} set-union
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
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
Get the Nameprep-processed version of the name (see discussion in the previous section).
名前のNamePrep-Processedバージョンを入手してください（前のセクションの説明を参照）。
Step 3. If NP(IN) not in {ZV} then stop
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)
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パッケージ内で、Active（Zone）ラベルバリアントのリストから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パッケージの原子性を保持するために、言語バリアントテーブルが変更された場合、Language Variantテーブルの以前のバージョンを使用して作成された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]の自発的なレジストリ[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
リファレンス1 CP936（一般にGBKとして知られています）参照2 ZVariant、Ztradvariant、Zsimpvariant in Unihan.txt [Unihan]リファレンス3の単純化された文字テーブルのリスト（簡素化された列）リファレンス4 Zsimpvariant 4 Zsimpvariant in Unihan.txt [Unihan]リファレンス5バリアント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
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
b) Language Variant Table for zh-tw
b) Zh-Twの言語バリアントテーブル
Reference 1 CP950 (commonly known as BIG5) Reference 2 zVariant, zTradVariant, zSimpVariant in Unihan.txt Reference 3 List of Simplified Character Table (Traditional column) Reference 4 zTradVariant in Unihan.txt
リファレンス1 CP950（一般にBIG5として知られています）参照2 ZVariant、Ztradvariant、Zsimpvariant in Unihan.txtリファレンス3の単純化された文字テーブルのリスト（従来の列）リファレンス4 Ztradvariant in Unihan.txt
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
c) Language Variant Table for ja
c) JAの言語バリアントテーブル
Reference 1 CP932 (commonly known as Shift-JIS) Reference 2 zVariant in Unihan.txt Reference 3 variant that exists in JIS X0208, commonly used Kanji
リファレンス1 CP932（一般的にシフトJISとして知られています）参照2 Zvariant in Unihan.txtリファレンス3 VariantはJIS X0208に存在します。
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
d) Language Variant Table for ko
d) KOの言語バリアントテーブル
Reference 1 CP949 (commonly known as EUC-KR) Reference 2 zVariant and K-source in Unihan.txt
参照1 CP949（一般にEUC-KRとして知られています）参照2 ZVariantおよびK-Source in Unihan.txt
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
Example 1: IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
{L} = {zh-cn, zh-sg, zh-tw}
NP(IN) = (U+6E05 U+771F U+6559)
PV(IN,zh-cn) = (U+6E05 U+771F U+6559)
PV(IN,zh-sg) = (U+6E05 U+771F U+6559)
PV(IN,zh-tw) = (U+6E05 U+771F U+6559)
{ZV} = {(U+6E05 U+771F U+6559)}
CVall = {(U+6E05 U+771E U+6559),
(U+6E05 U+771E U+654E),
(U+6E05 U+771F U+654E),
(U+6DF8 U+771E U+6559),
(U+6DF8 U+771E U+654E),
(U+6DF8 U+771F U+6559),
(U+6DF8 U+771F U+654E)}
Example 2: IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
{L} = {ja}
NP(IN) = (U+6E05 U+771F U+6559)
PV(IN,ja) = (U+6E05 U+771F U+6559)
{ZV} = {(U+6E05 U+771F U+6559)}
CVall = {(U+6E05 U+771E U+6559),
(U+6E05 U+771E U+654E),
(U+6E05 U+771F U+654E),
(U+6DF8 U+771E U+6559),
(U+6DF8 U+771E U+654E),
(U+6DF8 U+771F U+6559),
(U+6DF8 U+771F U+654E)}
Example 3: IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
{L} = {zh-cn, zh-sg, zh-tw, ja, ko}
NP(IN) = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
Invalid registration because U+6E05 is invalid in L = ko
Example 4: IDL = (U+806F U+60F3 U+96C6 U+5718)
*lian2 xiang3 ji2 tuan2*
{L} = {zh-cn, zh-sg, zh-tw}
NP(IN) = (U+806F U+60F3 U+96C6 U+5718)
PV(IN,zh-cn) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-sg) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-tw) = (U+806F U+60F3 U+96C6 U+5718)
{ZV} = {(U+8054 U+60F3 U+96C6 U+56E2),
(U+806F U+60F3 U+96C6 U+5718)}
CVall = {(U+8054 U+60F3 U+96C6 U+56E3),
(U+8054 U+60F3 U+96C6 U+5718),
(U+806F U+60F3 U+96C6 U+56E2),
(U+806f U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+56E2),
(U+8068 U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+5718)
Example 5: IDL = (U+8054 U+60F3 U+96C6 U+56E2)
*lian2 xiang3 ji2 tuan2*
{L} = {zh-cn, zh-sg}
NP(IN) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-cn) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-sg) = (U+8054 U+60F3 U+96C6 U+56E2)
{ZV} = {(U+8054 U+60F3 U+96C6 U+56E2)}
CVall = {(U+8054 U+60F3 U+96C6 U+56E3),
(U+8054 U+60F3 U+96C6 U+5718),
(U+806F U+60F3 U+96C6 U+56E2),
(U+806f U+60F3 U+96C6 U+56E3),
(U+806F U+60F3 U+96C6 U+5718),
(U+8068 U+60F3 U+96C6 U+56E2),
(U+8068 U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+5718)}
Example 6: IDL = (U+8054 U+60F3 U+96C6 U+56E2)
*lian2 xiang3 ji2 tuan2*
{L} = {zh-cn, zh-sg, zh-tw}
NP(IN) = (U+8054 U+60F3 U+96C6 U+56E2)
Invalid registration because U+8054 is invalid in L = zh-tw
Example 7: IDL = (U+806F U+60F3 U+96C6 U+5718)
*lian2 xiang3 ji2 tuan2*
{L} = {ja,ko}
NP(IN) = (U+806F U+60F3 U+96C6 U+5718)
PV(IN,ja) = (U+806F U+60F3 U+96C6 U+5718)
PV(IN,ko) = (U+806F U+60F3 U+96C6 U+5718)
{ZV} = {(U+806F U+60F3 U+96C6 U+5718)}
CVall = {(U+806F U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+5718),
(U+8068 U+60F3 U+96C6 U+56E3)}
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" Metalangage [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
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
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
参照1 CP936（一般にGBKとして知られています）参照2 ZVariant、Ztradvariant、Zsimpvariant in Unihan.txtリファレンス3の単純化された文字テーブルのリスト（簡略化された列）リファレンス4 Zsimpvariant 4 Zsimpvariant 4 Zsimpvariant in gb2312、一般的な単純化されたhanzii
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.
各言語バリアントテーブルには、バージョン番号とリリース日が必要です。これは「バージョン」という単語でタグ付けされ、その後に整数が続き、その後にyyyymmdd形式の日付が続きます。ここで、yyyは4桁の年、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つの列があります。「有効なコードポイント」。「優先バリアント」;および「キャラクターバリアント」。
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.
複数の優先バリアントがある場合があります。したがって、「優先バリアント」列に複数のエントリがある可能性があります。「優先バリアント」列が空の場合、対応する優先バリアントはありません。言い換えれば、優先バリアントは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.
「優先バリアント」または「文字バリアント」列に複数のバリアントがある場合、各バリアントはコンマで分離されます。
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.
「優先バリアント」列にリストされているコードポイントは、関連する言語が登録されるルールで許可する必要があります。ただし、これは「文字バリアント」列のエントリの要件ではありません。これらのエントリの一部を登録することを許可されない場合があります。
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言語の場合、攻撃者は、異なる文字（または、より具体的には、コードポイントを割り当てられたコードポイント）の結果として、ユーザーを同一または同様のセマンティクスで迂回または混乱させる機会があります。これらのガイドラインは、不適切なキャラクターがまったく登録されないことを禁止し、「バリアント」文字を一緒にグループ化して予約することを許可するためのフレームワークを提供することにより、これらのリスクの部分的な救済策を提供します。。ただし、提案するシステムは、このドキュメントが指定している形式と使用の形式をゾーンごとと言語ごとのテーブルよりも良くも悪くもありません。特定のテーブル、および追加のローカル処理は、登録のリスクと柔軟性のバランスに関するゾーンごとの決定を反映します。そして、もちろん、これらのテーブルの構築におけるエラーは、提供される保護の質を大幅に低下させる可能性があります。
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
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。Hotta、S。Tashiro、Y。Yoneya、およびタイのバンコクで開催されたジェット会議のその他の共同エンジニアリングチームメンバー。
- Yves Arrouye, an observer at the JET meeting in Bangkok, for his contribution on the IDL Package.
- IDLパッケージでの貢献について、バンコクで開催されたジェット会議のオブザーバーであるYves Arrouye。
- 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.
- Harald Alvestrand、Erin Chen、Patrik Faltstrom、Paul Hoffman、Soobok Lee、Lee Xiaodong、Mao Wei、Erik Nordmark、L.M。Tsengなど、以前のバージョンについてコメントし、提案した人々。
[ABNF] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker、D。およびP. Overell、eds。、「構文仕様のための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、1987年11月。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.、Hoffman、P.およびA. M. Costello、「アプリケーションの国際化ドメイン名（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] Costello、A.M。、「Punycode：Applications（IDNA）の国際化ドメイン名のUnicodeのブートストリングエンコーディング」、RFC 3492、2003年3月。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[StringPrep] Hoffman、P。and M. Blanchet、「国際化された文字列の準備（「StringPrep」）」、RFC 3454、2002年12月。
[NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[NamePrep] Hoffman、P。and M. Blanchet、「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）。これはマルチパート標準です。ISO/IEC 10646- 1：2000（e）として公開されたパート1、アーキテクチャと基本的な多言面をカバーし、パート2はISO/IEC 10646-2：2001（e）として公開されています。補足（追加）飛行機。
[UNIHAN] Unicode Han Database, Unicode Consortium ftp://ftp.unicode.org/Public/UNIDATA/Unihan.txt.
[Unihan] Unicode Hanデータベース、Unicode Consortium ftp://ftp.unicode.org/public/unidata/unihan.txt。
[UNICODE] The Unicode Consortium, "The Unicode Standard Version 3.0," ISBN 0-201-61633-5. Unicode Standard Annex #28 (http://www.unicode.org/unicode/reports/tr28/) defines Version 3.2 of the Unicode Standard, which is definitive for IDNA and this document.
[Unicode] Unicode Consortium、「Unicode Standardバージョン3.0」、ISBN 0-201-61633-5。Unicode Standard Annex＃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; 1991年の情報と文書化中国語、ISO/TC46/SC2のロマン化。
[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 Internationalized Domain Name Working Group、IDN@ops.ietf.org、James Seng、Marc Blanchet、共同議長、http：//www.i-dn.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-04-01。
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。Huang、H。Qian、およびY. Koに嘘をつきます。これらの著者は、最初のページに記録の著者としてリストされており、このRFCに関する質問やコメントのための長期的な連絡先です。一方、J。Seng、J。Klensin、およびW. Rickardは、ドキュメントの編集者を務め、4人の著者と彼らが表現したチームのアイデアを転写して翻訳しました。それらは編集プロセス中の主要な連絡先でしたが、長期的にはそうではありませんでした。
Kazunori KONISHI JPNIC Kokusai-Kougyou-Kanda Bldg 6F 2-3-4 Uchi-Kanda, Chiyoda-ku Tokyo 101-0047 Japan
Kazunori Konishi Jpnic Kokusai-Kougyou-Kanda Bldg 6f 2-3-4 Uchi-Kanda、Chiyoda-Ku Tokyo 101-0047 Japan
Phone: +81 49-278-7313
EMail: konishi@jp.apan.net
Kenny HUANG TWNIC 3F, 16, Kang Hwa Street, Taipei Taiwan
Kenny Huang Twnic 3f、16、Kang Hwa Street、台北台湾
Phone: 886-2-2658-6510 EMail: huangk@alum.sinica.edu
電話：886-2-2658-6510メール：huangk@alum.sinica.edu
QIAN Hualin CNNIC No.6 Branch-box of No.349 Mailbox, Beijing 100080 Peoples Republic of China
Qian Hualin CNNIC No.6 No.349メールボックス、北京100080人民共和国の支店
EMail: Hlqian@cnnic.net.cn
KO YangWoo PeaceNet Yangchun P.O. Box 81 Seoul 158-600 Korea
Ko Yangwoo Peacenet Yangchun P.O.ボックス81ソウル158-600韓国
EMail: yw@mrko.pe.kr
James SENG 180 Lompang Road #22-07 Singapore 670180 Phone: +65 9638-7085
ジェームズセン180ロンパンロード＃22-07シンガポール670180電話：65 9638-7085
EMail: jseng@pobox.org.sg
John C KLENSIN 1770 Massachusetts Avenue, No. 322 Cambridge, MA 02140 U.S.A.
ジョンCクレンシン1770マサチューセッツアベニュー、No。322ケンブリッジ、マサチューセッツ州02140 U.S.A.
EMail: Klensin+ietf@jck.com
Wendy RICKARD The Rickard Group 16 Seminary Ave Hopewell, NJ 08525 USA
ウェンディリッカードリッカードグループ16神学校アベニューホープウェル、ニュージャージー08525アメリカ
EMail: 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.
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。