[要約] RFC 4290は、国際化ドメイン名（IDN）の登録に関する推奨事項を提供する。その目的は、IDNの登録プロセスを改善し、インターネット上での多言語サポートを促進することである。
Network Working Group J. Klensin
Request for Comments: 4290 December 2005
Category: Informational
Suggested Practices for Registration of Internationalized Domain Names (IDN)
国際化されたドメイン名の登録のための提案された慣行（IDN）
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
IESG Note
IESGノート
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information.
このRFCは、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄し、公開する決定はIETFワークとの競合に関するIESGレビューとは別にIETFレビューに基づいていないことに注意してください。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。詳細については、RFC 3932を参照してください。
Abstract
概要
This document explores the issues in the registration of internationalized domain names (IDNs). The basic IDN definition allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar-looking names. To avoid this confusion, the IDN registration process must impose rules that disallow some otherwise-valid name combinations. This document suggests a set of mechanisms that registries might use to define and implement such rules for a broad range of languages, including adaptation of methods developed for Chinese, Japanese, and Korean domain names.
このドキュメントでは、国際化されたドメイン名（IDN）の登録における問題を調査します。基本的なIDN定義により、ドメイン名で非常に多数の可能な文字が可能になり、この豊かさは、似たような名前に関する深刻なユーザーの混乱につながる可能性があります。この混乱を避けるために、IDN登録プロセスは、他の方法では明確な名前の組み合わせを禁止するルールを課さなければなりません。このドキュメントは、中国語、日本、韓国のドメイン名のために開発された方法の適応を含む、幅広い言語のそのようなルールを定義および実装するためにレジストリが使用できる一連のメカニズムを示唆しています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. The Nature and Status of these Recommendations .............4
1.3. Terminology ................................................5
1.3.1. Languages and Scripts .................................5
1.3.2. Characters, Variants, Registrations, and Other
Issues ................................................6
1.3.3. Confusion, Fraud, and Cybersquatting ..................9
1.4. A Review of the JET Guidelines .............................9
1.4.1. JET Model .............................................9
1.4.2. Reserved Names and Label Packages ....................10
1.5. Languages, Scripts, and Variants ..........................11
1.5.1. Languages versus Scripts .............................11
1.5.2. Variant Selection ....................................13
1.6. Variants are not a Universal Remedy .......................14
1.7. Reservations and Exclusions ...............................14
1.7.1. Sequence Exclusions for Valid Characters .............14
1.7.2. Character Pairing Issues .............................15
1.8. The Registration Bundle ...................................15
1.8.1. Definitions and Structure ............................15
1.8.2. Application of the Registration Bundle ...............16
2. Some Implications of This Approach .............................17
3. Possible Modifications of the JET Model ........................18
4. Conclusions and Recommendations About the General Approach .....18
5. A Model Table Format ...........................................19
6. A Model Label Registration Procedure: "CreateBundle" ...........20
6.1. Description of the CreateBundle Mechanism .................21
6.2. The "no-variants" Case ....................................22
6.3. CreateBundle and Nameprep Mapping .........................22
7. IANA Considerations ............................................23
8. Internationalization Considerations ............................24
9. Security Considerations ........................................24
10. Acknowledgements ..............................................25
11. Informative References ........................................26
The IDNA (Internationalized Domain Names in Applications) specification [RFC3490] defines the basic model for encoding non-ASCII strings in the DNS. Additional specifications [RFC3491] [RFC3492] define the mechanisms and tables needed to support IDNA. As work on these specifications neared completion, it became apparent that it would be desirable for registries to impose additional restrictions on the names that could actually be registered (e.g., see [IESG-IDN] and [ICANN-IDN]) to reduce potential confusion among characters that were similar in some way. This document explores these IDN (international domain name) registration issues and suggests a set of mechanisms that IDN registries might use.
IDNA（アプリケーションの国際化ドメイン名）仕様[RFC3490]は、DNSの非ASCII文字列をエンコードするための基本モデルを定義します。追加の仕様[RFC3491] [RFC3492]は、IDNAをサポートするために必要なメカニズムと表を定義します。これらの仕様の作業が完了に近づいたため、レジストリが実際に登録できる名前に追加の制限を課すことが望ましいことが明らかになりました（たとえば、[IESG-IDN]および[ICANN-IDN]を参照）、何らかの方法で類似したキャラクター間の潜在的な混乱を減らすことができます。このドキュメントは、これらのIDN（国際ドメイン名）登録の問題を調査し、IDNレジストリが使用する可能性のある一連のメカニズムを提案します。
Registration restrictions are part of a long tradition. For example, while the original DNS specifications [RFC1035] permitted any string of octets in a DNS label, they also recommended the use of a much more restricted subset. This subset was derived from the much older "hostname" rules [RFC952] and defined by the "LDH" convention (for the three permitted types of characters: letters, digits, and the hyphen). Enforcement of this restricted subset in registrations was the responsibility of the registry or domain administrator. The definition of the subset was embedded in the DNS protocol itself, although some applications protocols, notably those concerned with electronic mail, did impose and enforce similar rules.
登録制限は長い伝統の一部です。たとえば、元のDNS仕様[RFC1035]はDNSラベルのオクテットの文字列を許可しましたが、はるかに制限されたサブセットの使用も推奨しました。このサブセットは、はるかに古い「ホスト名」ルール[RFC952]から派生し、「LDH」条約（許可された3つのタイプの文字、数字、ハイフン）で定義されています。登録におけるこの制限されたサブセットの施行は、レジストリまたはドメイン管理者の責任でした。サブセットの定義はDNSプロトコル自体に埋め込まれていましたが、一部のアプリケーションプロトコル、特に電子メールに関係するアプリケーションプロトコルは、同様のルールを課し、実施しました。
If there are no constraints on registration in a zone, people can register characters that increase the risk of misunderstandings, cybersquatting, and other forms of confusion. A similar situation existed even before the introduction of IDNA, as exemplified by domain names such as example.com and examp1e.com (note that the latter domain contains the digit "1" instead of the letter "l").
ゾーンでの登録に制約がない場合、人々は誤解、サイバースクッティング、その他の混乱のリスクを高めるキャラクターを登録できます。embly.comやexamp1e.comなどのドメイン名で例示されるように、IDNAの導入前でも同様の状況が存在していました（後者のドメインには文字「L」の代わりに桁「1」が含まれていることに注意してください）。
For non-ASCII names (so-called "internationalized domain names" or "IDNs"), the problem is more complicated. In the earlier situation that led to the LDH (hostname) rules, all protocols, hosts, and DNS zones used ASCII exclusively in practice, so the LDH restriction could reasonably be applied uniformly across the Internet. Support for IDNs introduces a very large character repertoire, different geographical and political locations, and languages that require different collections of characters. The optimal registration restrictions are no longer a global matter; they may be different in different areas and, hence, in different DNS zones.
非ASCII名（いわゆる「国際化ドメイン名」または「IDNS」）の場合、問題はより複雑です。LDH（ホスト名）ルールにつながった以前の状況では、すべてのプロトコル、ホスト、およびDNSゾーンが実際にASCIIを独占的に使用したため、LDHの制限はインターネット全体に均一に適用される可能性があります。IDNSのサポートでは、非常に大きなキャラクターのレパートリー、さまざまな地理的および政治的な場所、さまざまなキャラクターのコレクションを必要とする言語が紹介されています。最適な登録制限は、もはやグローバルな問題ではありません。それらは異なる領域で異なる場合があり、したがって、異なるDNSゾーンでは異なります。
For some human writing systems, there are characters and/or strings that have equivalent or near-equivalent usages. If a name can be registered with such a character or string, the registry might want to automatically associate all of the names that have the same meaning with the registered name. The registry might also decide whether the names that are associated with, or generated by, one registration should, as a group or individually, go into the zone or should be blocked from registration by different parties.
一部の人間のライティングシステムには、同等またはほぼ同等の使用法を持つ文字および/または文字列があります。名前をそのような文字または文字列に登録できる場合、レジストリは同じ意味を持つすべての名前を登録名に自動的に関連付けることをお勧めします。また、レジストリは、1つの登録に関連付けられている、または1つの登録がグループとして、または個別にゾーンに入るべきか、異なる当事者による登録からブロックされるべきかを決定する場合があります。
To date, the best-developed system for handling registration restrictions for IDNs is the JET Guidelines for Chinese, Japanese, and Korean [RFC3743], the so-called "CJK" languages. The JET Guidelines are limited to the CJK languages and, in particular, to their common script base. Those languages are also the best-known and most widely-used examples of writing systems constructed on "ideographic" or "pictographic" principles. This document explores the principles behind the JET guidelines. It then examines some of the issues that might arise in adapting them to alphabetic languages, i.e., to languages whose characters primarily represent sounds rather than meanings.
これまで、IDNSの登録制限を処理するための最良のシステムは、中国、日本、韓国語[RFC3743]のジェットガイドラインであり、いわゆる「CJK」言語です。JETガイドラインは、CJK言語、特に一般的なスクリプトベースに限定されています。これらの言語はまた、「表記法」または「絵文字」の原則に基づいて構築された執筆システムの最も有名で最も広く使用されている例です。このドキュメントでは、ジェットガイドラインの背後にある原則を調査します。次に、アルファベット語の言語に適応する際に発生する可能性のある問題のいくつか、つまり、キャラクターが主に意味ではなく音を表す言語に調べます。
This document describes five things:
このドキュメントは、5つのことを説明しています。
1. The general background and considerations for non-ASCII scripts in names.
1. 名前の非ASCIIスクリプトの一般的な背景と考慮事項。
2. Suggested practices for describing character variants.
2. キャラクターのバリエーションを説明するための提案されたプラクティス。
3. A method for using a zone's character variants to determine which names should be associated with a registration.
3. ゾーンの文字バリアントを使用して、登録に関連付けられる名前を決定する方法。
4. A format for publishing a zone's table of character variants; Such tables are referred to below simply as "language tables" or simply "tables".
4. ゾーンのキャラクターのバリエーションテーブルを公開するための形式。このような表は、以下で単に「言語テーブル」または単に「テーブル」と呼ばれます。
5. A model algorithm for name registration given the presence of language tables.
5. 言語テーブルの存在を考慮して、名前登録のモデルアルゴリズム。
The document makes recommendations for consideration by registries and, where relevant, by those who coordinate them, and by those who use their services. None of the recommendations are intended to be normative. Instead, the intent of the document is to illustrate a framework for developing variations to meet the needs of particular registries and their processing of particular languages. Of course, if registries make similar decisions and utilize similar tools, costs and confusion may be reduced -- both between registries and for users and registrars who have relationships with more than one domain.
このドキュメントは、レジストリによる検討のための推奨事項を作成し、関連する場合は、それらを調整する人、およびサービスを使用する人によって行われます。推奨事項のいずれも規範的であることを意図していません。代わりに、ドキュメントの意図は、特定のレジストリのニーズと特定の言語の処理を満たすためにバリエーションを開発するためのフレームワークを説明することです。もちろん、レジストリが同様の意思決定を行い、同様のツールを利用する場合、レジストリと複数のドメインと関係があるユーザーとレジストラの両方のコストと混乱が削減される可能性があります。
Just as the JET Guidelines contain some suggestions that may not be applicable to alphabetic scripts, some of the suggestions here, especially the more specific ones, may be applicable to some scripts and not others.
JETガイドラインにアルファベットのスクリプトに適用できない可能性のあるいくつかの提案が含まれているように、ここでの提案のいくつか、特により具体的なものは、いくつかのスクリプトに適用される可能性があります。
This document uses the term "language" in what may be, to many readers, an odd way. Neither this specification, nor IDNA, nor the DNS are directly concerned with natural language, but only with the characters that make up a given label. In some respects, the term "script", used in the character coding community for a collection of characters, might be more appropriate. However, different subsets of the same script may be used with different languages, and the same language may be written using different characters (or even completely different scripts) in different locations, so "script" is not precisely correct either.
このドキュメントでは、「言語」という用語を、多くの読者にとって、奇妙な方法で使用します。この仕様もIDNAもDNSも、自然言語に直接関係していませんが、特定のラベルを構成するキャラクターのみに関係しています。いくつかの点では、文字コーディングコミュニティでキャラクターのコレクションのために使用される「スクリプト」という用語がより適切かもしれません。ただし、同じスクリプトの異なるサブセットを異なる言語で使用することができ、同じ言語を異なる場所で異なる文字（または完全に異なるスクリプト）を使用して書くことができるため、「スクリプト」も正確に正しくありません。
Long-standing confusion has also resulted from the fact that most scripts are, informally at least, named after one of the languages written in them. "Chinese" describes both a language and a collection of characters that are also used in writing Japanese, Korean, and, at least historically, some other languages. "Latin" describes a language, the characters used to write that language, and, often, characters used to write a number of contemporary languages that are derived from or similar to those used to write the Latin language. The script used to write the Arabic language is called "Arabic", but it is also used (typically with some additions or deletions) to write a number of other languages. Situations in which a script has a clearly-defined name that is independent of the name of a language are the exception, rather than the rule; examples include Hangul, used to write Korean, Katakana and Hiragana, used to write Japanese, and a few others. Some scholars have historically used "Roman" or "Roman-derived" for the script in an attempt to distinguish between a script and the Latin language.
長年の混乱は、ほとんどのスクリプトが少なくとも非公式には、それらに書かれた言語の1つにちなんで名付けられたという事実からも生じました。「中国語」は、日本、韓国語、そして少なくとも歴史的には他の言語を書く際にも使用される言語とキャラクターのコレクションの両方を説明しています。「ラテン語」は言語、その言語を書くために使用されるキャラクター、そして多くの場合、ラテン語を書くために使用されるものと類似した多くの現代言語を書くために使用されるキャラクターをしばしば書いています。アラビア語を書くために使用されるスクリプトは「アラビア語」と呼ばれますが、他の多くの言語を書くために（通常はいくつかの追加または削除が付いています）も使用されます。スクリプトには、言語の名前に依存しない明確に定義された名前がある状況は、ルールではなく例外です。例には、韓国語、カタカナ、ヒラガナを書くために使用されるハングルなどがあり、日本語を書くために使用されていました。一部の学者は、スクリプトとラテン語を区別しようとするために、スクリプトに「ローマ」または「ローマ由来」を歴史的に使用してきました。
The term "language" is therefore used in this document in the informal sense of a written language and is defined, for this purpose, by the characters used to write it, i.e., as a language-specific subset of a script. In this context, a "language" is defined by the combination of a code (see Section 1.4.1) and an authority that has chosen to use that code and establish a character-listing for it. Authorities are normally TLD (top-level domain) registries; see Section 7 and [IANA-language-registry]. However, it is expected that TLD registries will find appropriate experts and that advice from language and script experts selected by international neutral bodies will also become part of the registration system. In addition, as discussed below in Section 7, registries may conclude that the best interests of registrants, stakeholders, and the Internet community would be served by constructing "language tables" that mix scripts and characters in ways that conform to no known language. Conventions should be developed for such registrations that do not misleadingly reflect specific language codes.
したがって、「言語」という用語は、書かれた言語の非公式な意味でこのドキュメントで使用され、この目的のために、それを書くために使用されるキャラクター、つまりスクリプトの言語固有のサブセットとして定義されています。これに関連して、「言語」は、コード（セクション1.4.1を参照）とそのコードを使用してキャラクターリストを確立することを選択した権限の組み合わせによって定義されます。当局は通常、TLD（トップレベルのドメイン）レジストリです。セクション7および[Iana-Language-Registry]を参照してください。ただし、TLDレジストリは適切な専門家を見つけることが期待されており、国際的な中立団体によって選択された言語およびスクリプトの専門家からのアドバイスも登録システムの一部になることが予想されます。さらに、セクション7で説明するように、レジストリは、登録者、利害関係者、およびインターネットコミュニティの最大の利益は、既知の言語に準拠していない方法でスクリプトとキャラクターを組み合わせた「言語テーブル」を構築することで提供されると結論付けることができます。特定の言語コードを誤解させないような登録のために、慣習を開発する必要があります。
1. Characters in this document are specified by their Unicode codepoints in U+xxxx format, by their official names, or both.
1. このドキュメントの文字は、U XXXX形式のUnicode CodePoints、公式名、またはその両方によって指定されています。
2. The following terms are used in this document.
2. このドキュメントでは、次の用語が使用されています。
* String
* 弦
A "string" is an sequence of one or more characters.
「文字列」は、1つ以上の文字のシーケンスです。
* Base Character
* ベース文字
This document discusses characters that may have equivalent or near-equivalent characters or strings. A "base character" is a character that has zero or more equivalents. In the JET Guidelines, base characters are referred to as "valid characters". In a table with variants, as described in Section 5, the base characters occupy the first column. Normally (and always, if the recommendation of Section 6.3 is adopted), the base characters will be the characters that appear in registration requests from registrants; any other character will invalidate the registration attempt.
このドキュメントでは、同等またはほぼ同等の文字または文字列を持つキャラクターについて説明します。「ベースキャラクター」は、ゼロ以上の同等のキャラクターです。ジェットガイドラインでは、ベース文字は「有効な文字」と呼ばれます。セクション5で説明されているように、バリアントのあるテーブルでは、基本文字が最初の列を占めています。通常（常に、セクション6.3の推奨が採用されている場合）、ベース文字は登録要求に登録要求に表示される文字になります。他のキャラクターは登録の試みを無効にします。
* Native Script
* nativeScript
Native script is the form in which the relevant string would normally be represented. For example, it might use Lower Slobbovian characters and the glyphs normally used to write them. It would not be punycode as a presentation form.
ネイティブスクリプトは、関連する文字列が通常表される形式です。たとえば、より低いslobbovianキャラクターを使用し、通常はそれらを書くために使用されるグリフを使用する場合があります。プレゼンテーションフォームとしては、プニコードではありません。
* Variant Characters/Strings
* バリアント文字/文字列
The "variant(s)" are character(s) and/or string(s) that are treated as equivalent to the base character. Note that these might not be exactly equivalent characters; a particular original character may be a base character with a mapping to a particular variant character, but that variant character may not have a mapping to the original base character. Indeed, the variant character may not appear in the base character list, and hence may not be valid for use in a registration. Usually, characters or strings to be designated as variants are considered either equivalent or sufficiently similar (by some registry-specific definition) that confusion between them and the base character might occur.
「バリアント」は、ベース文字に相当するものとして扱われる文字および/または文字列です。これらは正確に同等の文字ではないかもしれないことに注意してください。特定のオリジナルの文字は、特定のバリアント文字にマッピングするベース文字である可能性がありますが、そのバリアント文字には元のベース文字にマッピングがない場合があります。実際、バリアント文字はベース文字リストに表示されない可能性があるため、登録での使用に有効でない場合があります。通常、バリアントとして指定される文字または文字列は、それらとベース文字との間の混乱が発生する可能性があるという同等または十分に類似した（ある程度のレジストリ固有の定義によって）と見なされます。
* Base Registration
* 基本登録
The "base registration" is the single name that the registrant requested from the registry. The JET Guidelines use the term "label string" for this concept.
「基本登録」は、登録者がレジストリから要求した単一名です。JETガイドラインは、この概念に「ラベル文字列」という用語を使用します。
* Registered, Activated
* 登録、アクティブ化
A label (or "name") is described as "registered" if it is actually entered into a domain (i.e., into a zone file) by the registry, so that it can be accessed and resolved using standard DNS tools. The JET Guidelines describe a "registered" label as "activated". However, some domains use a slightly different registration logic in which a name can be registered with the registrar (if one is involved) and with the registry, but not actually entered into the zone file until an additional activation or delegation step occurs. This document does not make that distinction, but is compatible with it.
ラベル（または「名前」）は、実際にレジストリによってドメイン（つまり、ゾーンファイルに）に入力された場合、「登録」と呼ばれ、標準のDNSツールを使用してアクセスおよび解決できます。ジェットガイドラインでは、「登録された」ラベルを「アクティブ化」として説明しています。ただし、一部のドメインでは、レジストラ（関与している場合）およびレジストリに名前を登録できるわずかに異なる登録ロジックを使用しますが、追加のアクティベーションまたは委任ステップが発生するまでゾーンファイルに実際に入力されません。このドキュメントはその区別をしませんが、それと互換性があります。
As specified in the IDNA Standard, the name actually placed in the zone file is always the internal ("punycode") form. There is no provision for actually entering any other form of an IDN into the DNS. It remains controversial, with different registrars and registries having adopted different policies, as to whether the registration, as submitted by the registrant, is in the form of:
IDNA標準で指定されているように、実際にゾーンファイルに配置された名前は、常に内部（「Punycode」）フォームです。他の形式のIDNをDNSに実際に入力する規定はありません。登録者によって提出された登録が次の形であるかどうかに関して、異なるレジストラとレジストリが異なるポリシーを採用していることで議論の余地があります。
o The native-script name, either in UTF-8 or in some coding specified by the registrar, or
o ネイティブスクリプト名は、UTF-8またはレジストラによって指定された一部のコーディングのいずれか、または
o the internal-form ("punycode") name, or
o 内部形式（ "punycode"）名、または
o both forms of the name together, so that the registrar and registry can verify the intended translation.
o レジストラとレジストリが意図した翻訳を検証できるように、両方のフォームが一緒にいます。
If any of the approaches defined in this document is used, it is almost certain to be necessary that the native-script form of the requested string be available to the registry.
このドキュメントで定義されているアプローチのいずれかが使用されている場合、要求された文字列のネイティブスクリプト形式をレジストリで利用できるようにする必要があることがほぼ確実です。
* Registration Bundle
* 登録バンドル
A "registration bundle" is the set of all labels that come from expanding the base characters for a single name into their variants. The presence of a label in a registration bundle does not imply that it is registered. In the JET Guidelines, a registration bundle is called an "IDN Package".
「登録バンドル」は、単一の名前のベース文字をバリアントに拡大することから生じるすべてのラベルのセットです。登録バンドルにラベルが存在することは、登録されていることを意味しません。ジェットガイドラインでは、登録バンドルは「IDNパッケージ」と呼ばれます。
* Reserved Label
* 予約されたラベル
A "reserved label" is a label in a registration bundle that is not actually registered.
「予約済みのラベル」は、実際には登録されていない登録バンドルのラベルです。
* Registry"
* レジストリ」
A "registry" is the administrative authority for a DNS zone. The registry is the body that enforces, and typically makes, policies that are used in a particular zone in the DNS.
「レジストリ」は、DNSゾーンの管理当局です。レジストリは、DNSの特定のゾーンで使用されるポリシーを実施し、通常行う本体です。
* Coded Character Set
* コード化された文字セット
A "Coded Character Set" (CCS) is a list of characters and the code positions assigned to them. ASCII and Unicode are CCSs.
「コード化された文字セット」（CCS）は、文字のリストとそれらに割り当てられたコード位置です。ASCIIとUnicodeはCCSSです。
* Language
* 言語
A "language" is something spoken by humans, independent of how it is written or coded. ISO Standard 639 and IETF BCP 47 (RFC 3066) [RFC3066] list and define codes for identifying languages.
「言語」とは、人間が話しているものであり、それがどのように書かれたりコーディングされたりする方法とは無関係です。ISO Standard 639およびIETF BCP 47（RFC 3066）[RFC3066]は、言語を識別するためのコードをリストおよび定義します。
* Script
* 脚本
A "script" is a collection of characters (glyphs, independent of coding) that are used together, typically to represent one or more languages. Note that the script for one language may heavily overlap the script for another. This does not imply that they have identical scripts.
「スクリプト」は、通常1つ以上の言語を表すために一緒に使用されるキャラクター（グリフ、コードとは無関係）のコレクションです。ある言語のスクリプトは、スクリプトを別の言語のスクリプトと重く重ねる場合があることに注意してください。これは、それらが同一のスクリプトを持っていることを意味するものではありません。
* Charset
* 文字コード
"Charset" is an IETF-invented term to describe, more or less, the combination of a script, a CCS that encodes that script, and rules for serializing encoded bytes that are stored on a computer or transmitted over the network.
「Charset」は、IETFに発明された用語であり、多かれ少なかれスクリプトの組み合わせ、そのスクリプトをエンコードするCCS、およびコンピューターに保存されているか、ネットワーク上に送信されるエンコードされたバイトをシリアル化するためのルールです。
The last four of these definitions are redundant with, but deliberately somewhat less precise than, the definitions in [RFC3536], which also provides sources. The two sets of definitions are intended to be consistent.
これらの定義の最後の4つは冗長ですが、[RFC3536]の定義も意図的には、ソースを提供します。定義の2つのセットは、一貫性があることを目的としています。
The term "confusion" is used very generically in this document to cover the entire range from accidental user misperception of the relationship between characters with some characteristic in common (typically appearance, sound, or meaning) to cybersquatting and (other) deliberately fraudulent attempts to exploit those relationships based on the nature of the characters.
「混乱」という用語は、このドキュメントで非常に一般的に使用されており、キャラクターと共通の特徴（通常は音、または意味）との関係の偶発的なユーザーの誤解から、サイバースコーティングや（他の）故意に詐欺的な試みを、キャラクターの性質に基づいて故意に詐欺的な試みをカバーしています。
In the JET Guidelines model, a prospective registrant approaches the registry for a zone (perhaps through an intermediate registrar) with a candidate base registration -- a proposed name to be registered -- and a list of languages in which that name is to be interpreted. The languages are defined according to the fairly high-resolution coding of [RFC3066] or, if the registry considers it more appropriate, a coding based on scripts such as those in [LTRU-Registry]. In this way, Chinese as used on the mainland of the People's Republic of China ("zh-cn") can, at registry option, consist of a somewhat different list of characters (code points) and be represented by a separate table compared to Chinese as used in Taiwan ("zh-tw").
JETガイドラインモデルでは、将来の登録者が、候補ベース登録（登録される提案された名前）とその名前が解釈される言語のリストを持つゾーン（おそらく中級レジストラを介して）のレジストリにアプローチします。言語は、[RFC3066]のかなり高解像度のコーディングに従って定義されます。または、レジストリがより適切であると考える場合、[ltru-registry]のようなスクリプトに基づくコーディング。このように、中国人民共和国（「Zh-CN」）の本土で使用される中国語は、レジストリオプションでは、やや異なる文字リスト（コードポイント）で構成され、台湾（「Zh-TW」）で使用されている中国語と比較して別のテーブルで表されます。
The design of the JET Guidelines took one important constraint as a basis: IDNA was treated as a firm standard. A procedure that modified some portion of the IDNA functions, or was a variant on them, was considered a violation of those standards and should not be encouraged (or, probably, even permitted).
ジェットガイドラインの設計は、1つの重要な制約を根拠として取り上げました。IDNAは確固たる基準として扱われました。IDNA関数の一部を変更した、またはそれらのバリアントであった手順は、それらの基準の違反と見なされ、奨励されるべきではありません（または、おそらく許可さえさえします）。
Each registry is expected to construct (or obtain) a table for each language it considers relevant and appropriate. These tables list, for the particular zone, the characters permitted for that language. If a character does not appear as a base character (called a "valid code point" in the JET document) in that table, then a name containing it cannot be registered. If multiple languages are listed for the registration, then the character must appear in the tables for each of those languages.
各レジストリは、関連性と適切と見なされる各言語のテーブルを構築（または取得）することが期待されます。これらのテーブルには、特定のゾーンの場合、その言語で許可されている文字がリストされています。キャラクターがそのテーブルのベース文字（ジェットドキュメントの「有効なコードポイント」と呼ばれる）として表示されない場合、それを含む名前を登録できません。登録のために複数の言語がリストされている場合、それらの各言語のテーブルに文字が表示される必要があります。
The tables may also contain columns that specify alternate or variant forms of the valid character. If these variants appear, they are used to synthesize labels that are alternatives to the original one. These labels are all reserved and can be registered or "activated" (placed into the DNS) only by the action or request of the original registrant; some (the "preferred variant labels") are typically registered automatically. The zone is expected to establish appropriate policies for situations in which the variant forms of one label conflict with already-reserved or already-registered labels.
テーブルには、有効な文字の代替またはバリアント形式を指定する列が含まれる場合があります。これらのバリアントが表示される場合、元のバリエーションに代わるラベルを合成するために使用されます。これらのラベルはすべて予約されており、元の登録者のアクションまたはリクエストによってのみ、登録または「アクティブ化」（DNSに配置された）ことができます。一部（「優先バリアントラベル」）は通常、自動的に登録されます。このゾーンは、1つのラベルのバリアントが既に予約されたまたは既に登録されているラベルと競合する状況のための適切なポリシーを確立することが期待されています。
Most of these concepts were introduced because of concerns about specific issues with CJK characters, beginning from the requirement that the use of Simplified Chinese by some registrants and Traditional Chinese by others not be permitted to create confusion or opportunities for fraud. While they may be applicable to registry tables constructed for alphabetic scripts, the translation should be done with care, since many analogies are not exact.
これらの概念のほとんどは、CJKキャラクターの特定の問題に関する懸念のために導入されました。これは、一部の登録者による単純化された中国人の使用が、詐欺の混乱や機会を生み出すことは許可されていないという要件から始まります。アルファベットのスクリプト用に構築されたレジストリテーブルに適用できますが、多くの類推は正確ではないため、翻訳は注意して行う必要があります。
Some of the important issues are discussed in the sections that follow, especially Section 3. The JET model may be considered as a variation on, and inspiration for, the model and method presented by the rest of this document, although the JET model has been completely developed only for CJK characters. Other languages or scripts, especially alphabetic ones, may require other variations.
重要な問題のいくつかについては、特にセクション3に続くセクションで説明されています。ジェットモデルは、このドキュメントの残りの部分で提示されるモデルと方法のバリエーションとインスピレーションと見なされる場合がありますが、ジェットモデルはCJK文字のみで完全に開発されています。他の言語やスクリプト、特にアルファベット語の言語には、他のバリエーションが必要になる場合があります。
A basic assumption of the JET model is that, if the evolution of specific characters or the properties of Unicode [Unicode] [Unicode32] or IDNA cause two strings to appear similar enough to cause confusion, then both should be registered by the same party or one of them should become unregisterable. The definition of "appear similar enough" will differ for different cultures and circumstance, and hence DNS zones, but the principle is fairly general. In the JET model, all of the variant strings are identified, some are registered into the DNS automatically, and others are simply reserved and can be registered, if at all, only by the original registrant. Other zones might find other policies appropriate. For example, a zone might conclude that having similar strings registered in the DNS was undesirable. If so, the list of variant strings would be used only to build a list of names that would be reserved and prohibited from being registered.
ジェットモデルの基本的な仮定は、特定の文字の進化またはUnicode [unicode] [unicode32]またはidnaの特性が2つの文字列が混乱を引き起こすほど十分に似ているように見える場合、両方が同じ当事者によって登録されるべきであるか、そのうちの1つは登録できないようにする必要があるということです。「十分に似たように見える」の定義は、異なる文化や状況で異なるため、DNSゾーンが異なりますが、原則はかなり一般的です。JETモデルでは、すべてのバリアント文字列が識別され、一部はDNSに自動的に登録され、他の文字列は単に予約されており、元の登録者のみが登録できます。他のゾーンは他のポリシーが適切であると思うかもしれません。たとえば、ゾーンは、DNSに類似した文字列を登録することは望ましくないと結論付けるかもしれません。その場合、バリアント文字列のリストは、予約され、登録されることを禁止する名前のリストを作成するためにのみ使用されます。
Conversations about scripts -- collections of characters associated with particular languages -- are common when discussing character sets and codes. However, the boundaries between one script and another are not well-defined. The Unicode Standard ([Unicode], [Unicode32]), for example, does not define script boundaries at all, even though it is structured in terms of usually-related blocks of characters. The issue is complicated by the common origin of most alphabetic scripts in use in the world today (see, for example, [Drucker] or the more scholarly [Daniels]).
スクリプトに関する会話 - 特定の言語に関連する文字のコレクション - は、文字セットとコードを議論するときに一般的です。ただし、あるスクリプトと別のスクリプトの境界は明確に定義されていません。たとえば、Unicode標準（[Unicode]、[Unicode32]）は、通常関連する文字のブロックの観点から構成されていても、スクリプトの境界をまったく定義しません。この問題は、今日の世界で使用されているほとんどのアルファベットのスクリプトの一般的な起源によって複雑になっています（たとえば、[Drucker]またはより学術的な[ダニエルズ]を参照）。
Because of that history, certain characters (or, more precisely, symbols representing characters) appear in the scripts associated with multiple languages, sometimes with very different sounds or meanings. This differs from the CJK situation in which, if a character appears in more than one of the relevant languages, it will usually have the same interpretation in each one. For the subset of characters that actually are ideographs or pictographs, pronunciation is expected to vary widely while meaning is preserved. At least in part because of that similarity of meaning, it made sense in the JET case to permit a registration to specify multiple languages, to verify that the characters in the label string (the requested "Base registration") were valid for each, and then to generate variant labels using each language in turn. For many alphabetic languages, it may be more sensible to prohibit the label string submitted for registration from being associated with more than one language. Indeed, "one label, one language" has been suggested as an important barrier against common sources of "look-alike" confusion. For example, the imposition of that rule in a zone would prevent the insertion of a few Greek or Cyrillic characters with shapes identical to the Latin ones into what was otherwise a Latin-based string. For a particular table, the list of base characters may be thought of as the script associated with the relevant language, with the understanding that the table design does not prevent the same character from appearing in the tables for multiple languages.
その歴史のために、特定の文字（または、より正確には、文字を表すシンボル）が複数の言語に関連付けられたスクリプトに、時には非常に異なる音や意味を持つスクリプトに表示されます。これは、キャラクターが関連する言語の複数に表示される場合、通常はそれぞれと同じ解釈を持つCJKの状況とは異なります。実際に表意文字または絵文字である文字のサブセットの場合、発音は大きく異なると予想されますが、意味は保持されます。少なくともその意味の類似性のために、ジェットケースでは、登録が複数の言語を指定することを許可し、ラベル文字列の文字（要求された「基本登録」）がそれぞれに有効であることを確認し、各言語を使用して各言語を使用してバリアントラベルを生成することは意味がありました。多くのアルファベット語の言語では、登録のために提出されたラベル文字列を複数の言語に関連付けることを禁止する方が賢明かもしれません。実際、「1つのラベル、1つの言語」は、「見た目のような」混乱の一般的なソースに対する重要な障壁として示唆されています。たとえば、ゾーン内でそのルールを賦課すると、ラテン語の弦と同一の形状のギリシャ語またはキリル文字がラテン語をベースにした文字列に挿入するのを防ぎます。特定のテーブルの場合、ベース文字のリストは、関連する言語に関連付けられたスクリプトと考えることができ、テーブルデザインは同じ文字が複数の言語のテーブルに表示されるのを妨げないという理解があります。
Indeed, this notion of a script that is local and specifically identified can be turned around: so-called "language tables" are associated with languages only insofar as thinking about the character structure and word forms associated with a given language helps to inform the construction of the table. A country like Finland, for example, might select among:
確かに、ローカルで具体的に特定されたスクリプトのこの概念は、向きを変えることができます。いわゆる「言語テーブル」は、特定の言語に関連付けられた文字構造と単語形式について考える限り、言語にのみ関連付けられています。たとえば、フィンランドのような国は以下を選択するかもしれません。
o One table each for Finnish, Swedish, and English characters and conventions, permitting a string to be registered in one, two, or all three languages. However, a three-language registration would necessarily prohibit any characters that did not appear in all three languages, since the label would make little sense otherwise.
o フィンランド語、スウェーデン語、英語のキャラクターと慣習のためにそれぞれ1つのテーブルで、文字列を1つ、2つ、または3つの言語すべてに登録することができます。ただし、3言語の登録は、レーベルが他の方法ではほとんど意味がないため、3つの言語すべてに表示されなかったキャラクターを必然的に禁止します。
o One table each, but with a "one label, one language" rule for the zone.
o それぞれ1つのテーブルですが、ゾーンの「1つのラベル、1つの言語」ルールがあります。
o A combined table based on the observation that all three writing systems were based on Roman characters and that the possibilities for confusion of interest to the registry would not be reduced by "language" differentiation. This option raises an interesting issue about language labeling as described in Section 1.4.1; see the discussion in Section 7 below.
o 3つのライティングシステムすべてがローマのキャラクターに基づいており、レジストリにとって関心のある混乱の可能性は「言語」の差別化によって減少しないという観察に基づいた合計テーブル。このオプションは、セクション1.4.1で説明されているように、言語のラベル付けに関する興味深い問題を提起します。以下のセクション7の説明を参照してください。
Regardless of what decisions were made about those languages and scripts, they might have a separate table for registration of labels containing Cyrillic characters. That table might contain some Roman-derived characters (either as base characters or as variants), just as some CJK tables do. See also Section 2, below.
これらの言語やスクリプトについてどのような決定が下されたかに関係なく、キリル文字を含むラベルの登録のための別のテーブルがある場合があります。そのテーブルには、いくつかのCJKテーブルがそうであるように、いくつかのローマ由来の文字（ベース文字またはバリアントとして）が含まれる場合があります。以下のセクション2も参照してください。
Tables that present multiple languages, as described above, have introduced confusion and discomfort among those who have failed to understand these definitions. The consequence of these definitions is that use of a language or script code in a registration is a mnemonic, rather than a normative statement about the language or script itself. When that confusion is likely to occur, it is appropriate to simply use the registry identifier and a sequence number to identify the registration.
上記のように、複数の言語を提示する表は、これらの定義を理解できなかった人々の間に混乱と不快感をもたらしました。これらの定義の結果は、登録での言語またはスクリプトコードの使用は、言語またはスクリプト自体に関する規範的な声明ではなく、ニーモニックであるということです。その混乱が発生する可能性が高い場合、レジストリ識別子とシーケンス番号を使用して登録を識別することが適切です。
As the JET Guidelines stress, no tables or systems of this type -- even if identified with a language as a means of defining or describing the table -- can assure linguistic or even syntactic correctness of labels with regard to that language. That assurance may not be possible without human intervention or at least dictionary lookups of complete proposed labels. It may even not be desirable to attempt that level of correctness (see Section 2).
JETガイドラインが強調するため、このタイプのテーブルやシステムは、テーブルを定義または説明する手段として言語で識別されたとしても、その言語に関するラベルの言語的または構文的な正しさを保証できません。その保証は、人間の介入または少なくとも完全な提案ラベルの辞書の検索なしでは不可能かもしれません。そのレベルの正確性を試みることは望ましくないかもしれません（セクション2を参照）。
Of course, if any language-based tests or constraints, including "one label, one language", are to be applied to limit the associated sources of confusion, each zone must have a table for each language in which it expects to accept registrations. The notion of a single combined table for the zone is, in the general case, simply unworkable. One could use a single table for the zone if the intent were to impose only minimal restrictions, e.g., to force alphabetic and numeric characters only, excluding symbols and punctuation. That type of restriction might be useful in eliminating some problems, such as those of unreadable labels, but it would be unlikely to be very helpful with, e.g., confusion caused by similar-looking characters.
もちろん、「1つのラベル、1つの言語」を含む言語ベースのテストまたは制約が、関連する混乱の原因を制限するために適用される場合、各ゾーンには登録を受け入れることを期待する各言語のテーブルが必要です。ゾーンの単一の結合テーブルの概念は、一般的な場合、単に実行不可能です。意図が最小限の制限のみを課す場合、たとえば、記号と句読点を除くアルファベットと数値のみを強制するために、ゾーンに単一のテーブルを使用できます。このタイプの制限は、読み取れないラベルの問題など、いくつかの問題を排除するのに役立つかもしれませんが、例えば、似たようなキャラクターによって引き起こされる混乱に非常に役立つ可能性は低いでしょう。
The area of character variants is rife with difficulties (and perhaps opportunities). There is no universal agreement about which base characters have variants, or if they do, what those variants are. For example, in some regions of the world and in some languages, LATIN SMALL LETTER O WITH DIAERESIS (U+00F6) and LATIN SMALL LETTER O WITH STROKE (U+00F8) are variants of each other, while in other regions, most people would think that LATIN SMALL LETTER O WITH STROKE has no variants. In some cases, the list of variants is difficult to enumerate. For example, it required several years for the Chinese language community to create variant tables for use with IDNA, and it remains, at the time of this writing, questionable how widely those tables will be accepted among users of Chinese from areas of the world other than those represented by the groups that created them.
キャラクターのバリエーションの領域は、困難（そしておそらく機会）に満ちています。どのベース文字がバリアントを持っているか、またはそれらのバリエーションが何であるかについての普遍的な合意はありません。たとえば、世界の一部の地域や一部の言語では、ラテン語の小さな文字o diaeresis（u 00F6）と脳卒中のあるラテンの小さな文字o（u 00F8）は互いに変異体であり、他の地域では、ほとんどの人は脳卒中のあるラテンの小文字oには変異体がないと考えています。場合によっては、バリアントのリストを列挙することは困難です。たとえば、中国語コミュニティがIDNAで使用するためのバリアントテーブルを作成するために数年必要であり、この執筆時点では、それらを作成したグループが代表するグループ以外の地域から中国人のユーザーの間でそれらのテーブルがどれほど広く受け入れられるかは疑わしいままです。
Thus, the first thing a registry should ask is whether or not any of the characters that they want to permit to be used have variants. If not, the registry's work is much simpler. This is not to say that a registry should ignore variants if they exist: adding variants after a registry has started to take registrations will be nearly as difficult administratively as removing characters from the list of acceptable characters. That is, if a registry later decides that two characters are variants of each other, and there are actively-used names in the zones that differ only on the new variants, the registry might have to transfer ownership of one of the names to a different owner, using some process that is certain to be controversial.
したがって、レジストリが最初に尋ねる必要があるのは、使用したいキャラクターのいずれかがバリアントを持っているかどうかです。そうでない場合、レジストリの作業ははるかに簡単です。これは、レジストリが存在する場合、レジストリがバリアントを無視する必要があるということではありません。レジストリが登録を開始した後にバリアントを追加することは、許容されるキャラクターのリストから文字を削除するのと同じくらい困難です。つまり、レジストリが後で2つの文字が互いのバリエーションであると決定し、ゾーンには新しいバリエーションのみが異なるゾーンに積極的に使用されている名前がある場合、レジストリは、議論の余地があることを確実にするプロセスを使用して、名前の1つの所有権を異なる所有者に転送する必要がある場合があります。
This situation in likely to be much easier for areas and zones that use characters that previously did not occur in the DNS at all than it will be for zones in which non-English labels have been registered in ASCII characters for some time, presumably because the language of interest uses additional "Latin" characters with some conventions when only ASCII is available. In the former case, the rules and conventions can be established before any registrations occur. In the latter, there may be conflicts or opportunities for confusion between existing registrations and now-permitted Roman-based characters that do not appear in ASCII. For example, a domain name might exist today that uses the name of a city in Canada spelled as "Montreal". If the zone in which it occurs changes its rules to permit the use of the character LATIN SMALL LETTER E WITH ACUTE (U+00E9), does the name of the city, spelled (correctly) using that character, conflict with the existing domain name registration? Certainly, if both are permitted, and permitted to be registered by separate parties, there are many opportunities for confusion.
この状況は、以前にDNSで発生していなかったキャラクターを使用していたエリアやゾーンではるかに簡単になる可能性が高いこの状況は、おそらくASCIIのみが利用可能な場合にいくつかのコンベンションを伴う追加の「ラテン」文字を使用するため、おそらくASCIIキャラクターに非英語のラベルが登録されているゾーンの場合よりもはるかに簡単です。前者の場合、登録が発生する前に規則と慣習を確立できます。後者では、既存の登録とASCIIに登場しない現在想定されているローマを拠点とするキャラクターとの間に混乱の紛争または機会があるかもしれません。たとえば、カナダの都市の名前を「モントリオール」と綴るドメイン名が今日存在する可能性があります。それが発生するゾーンがルールを変更してキャラクターラテンの小文字Eの急性（U 00E9）を使用することを許可する場合、そのキャラクターを使用して（正しく）綴られた都市の名前は、既存のドメイン名登録と対立しますか？確かに、両方が許可され、別々の当事者によって登録されることが許可されている場合、混乱の機会はたくさんあります。
Of course, zone managers should inform all current registrants when the registration policy for the zone changes. This includes the times when IDN characters are first allowed in the zone, when additional characters are permitted, and when any change occurs in the character variant tables.
もちろん、ゾーンマネージャーは、ゾーンの登録ポリシーが変更された場合、現在のすべての登録者に通知する必要があります。これには、IDN文字がゾーンで最初に許可される時間、追加の文字が許可されている場合、および文字バリアントテーブルで変更が発生する時間が含まれます。
Many languages contain two variants for a character, one of which is strongly preferred. A registry might restrict the base registration to the preferred form, or it might allow any form for the base registration. If the variant tables are created carefully, the resulting bundles will be the same, but some registries will give special status to the base registration such as its appearance in "Whois" databases.
多くの言語には、キャラクターに2つのバリアントが含まれており、そのうちの1つは強く好まれています。レジストリは、ベース登録を優先フォームに制限するか、基本登録の任意のフォームを許可する場合があります。バリアントテーブルが慎重に作成されている場合、結果のバンドルは同じになりますが、一部のレジストリは、「Whois」データベースに登場するなど、基本登録に特別なステータスを提供します。
It is worth stressing that there are many obvious opportunities for confusion that variant systems, by virtue of being based on processing of individual characters, cannot address. For example, if a language can be written with more than one script, or transliterations of the language into another script are common, variant models are insufficient to prevent conflicting registration of the related forms. Avoiding those types of problems would require different mechanisms, perhaps based on phonetic or natural language processing techniques for the entire proposed base registration.
個々のキャラクターの処理に基づいているため、バリアントシステムが対処できないことにより、混乱のための多くの明らかな機会があることを強調する価値があります。たとえば、言語を複数のスクリプトで書くことができる場合、または言語の別のスクリプトへの音訳が一般的である場合、バリアントモデルは、関連フォームの競合する登録を防ぐには不十分です。これらのタイプの問題を回避するには、おそらく提案された基本登録全体の音声言語処理技術に基づいて、異なるメカニズムが必要です。
The JET Guidelines are based on processing only single characters. Pairs or longer sequences of characters can, at the option of the registry, be handled through what the Guidelines describe as "additional processing". These registry-specific string processing procedures are specifically permitted by the guidelines to supplement the per-character processing that generates the variants.
ジェットガイドラインは、単一の文字のみを処理することに基づいています。文字のペアまたは長いシーケンスは、レジストリのオプションで、ガイドラインが「追加処理」と呼ぶものを介して処理できます。これらのレジストリ固有の文字列処理手順は、バリアントを生成する文字ごとの処理を補足するために、ガイドラインによって特別に許可されています。
A different zone with different needs could use a modified version of the table structure, or different types of additional processing, to prohibit particular sequences of characters by marking them as invalid, and to accept characters by marking them as valid. Other modifications or extensions might be designed to prevent certain letters from appearing at the beginning or end of labels. The use of regular expressions in the "valid characters" column might be one way to implement these types of restrictions, but there has been no experience so far with that approach.
異なるニーズを持つ異なるゾーンは、テーブル構造の変更されたバージョン、または異なる種類の追加処理を使用して、無効としてマークする特定の文字シーケンスを禁止し、有効なものとしてマークすることで文字を受け入れることができます。その他の変更または拡張機能は、ラベルの開始または終了時に特定の文字が表示されないように設計されている場合があります。「有効な文字」列での正規表現の使用は、これらのタイプの制限を実装する1つの方法かもしれませんが、そのアプローチの経験はこれまでにありませんでした。
In particular, in some scripts derived from Roman characters, sequences that have historically been typographically represented by single "ligature" or "digraph" characters may also be represented by the separate characters (e.g., "ae" for U+00E6 or "ij" for U+0133). If it is desired to either prohibit these, or to treat them as variants, some extensions to the single-character JET model may be needed. Some careful thinking about IDNA (especially nameprep) may also be needed, since some of these combinations are excluded there).
特に、ローマ文字から派生したいくつかのスクリプトでは、歴史的に単一の「ligature」または「gigraph」文字によって誤字が表現されてきたシーケンスは、別の文字（例えば、u 00e6またはu 0133の「ij」など）で表される場合があります。これらを禁止するか、それらをバリエーションとして扱うことが望ましい場合は、シングルキャラクタージェットモデルへのいくつかの拡張が必要になる場合があります。これらの組み合わせの一部はそこで除外されているため、IDNA（特にNamePrep）についての慎重な考え方も必要になる場合があります。
Some character pairings -- the use of a character form (glyph) in one language and a different form with the same properties in a related one -- closely approximate the issues with mapping between Traditional and Simplified Chinese, although the history is different. For example, it might be useful to have "o" with a stroke (U+00F8) as a variant for "o" with diaeresis above it (U+00F6) (and the equivalent upper-case pair) in a Swedish table, and vice versa in a Norwegian one, or to prohibit one of these characters entirely in each table. In a German table, U+00F8 would presumably be prohibited, while U+00F6 might have "oe" as a variant. Obviously, if the relevant language of registration is unknown, this type of variant matching cannot be applied in any sensible way.
いくつかのキャラクターのペアリング - 1つの言語でのキャラクターフォーム（GLYPH）の使用と、関連する特性で同じ特性を持つ異なる形式 - は、歴史は異なりますが、伝統的な中国と単純化された中国語のマッピングの問題に密接に近似しています。たとえば、ストローク（U 00F8）を「O」のバリアントとして「O」（U 00F6）（U 00F6）（および同等のアッパーケースペア）のバリアントとして、スウェーデンのテーブルでは、その逆も同様であり、各テーブルでこれらのキャラクターの1つを抑制します。ドイツのテーブルでは、U 00F8はおそらく禁止されていますが、U 00F6はバリアントとして「OE」を持っている可能性があります。明らかに、登録の関連言語が不明な場合、このタイプのバリアントマッチングを賢明な方法で適用することはできません。
As one of its critical innovations, the JET model defines an "IDN package", known in this document as a "registration bundle", which consists of the primary registered string (which is used as the name of the bundle), the information about the language table(s) used, the variant labels for that string, and indications of which of those labels are registered in the relevant zone file ("activated" in the JET terminology). Registration bundles are also atomic -- one can not add or remove variant labels from one without unregistering the entire package. A label exists in only one registration bundle at a time; if a new label is registered that would generate a variant that matches one that appears in an existing package, that variant simply is not included in the second package. A subsequent de-registration of the first package does not cause the variant to be added to the second. While it might be possible to change this in other models, the JET conclusion was that other options would be far too complex to implement and operate and would cause many new types of name conflicts.
重要なイノベーションの1つとして、JETモデルは、このドキュメントで「登録バンドル」として知られている「IDNパッケージ」を定義します。これは、プライマリ登録文字列（バンドルの名前として使用されます）、使用された言語テーブルの情報、その文字列のバリアントラベル、およびそれらのラベルの指標が関連ゾーンファイルに登録されていることを示すものです。登録バンドルもアトミックです。パッケージ全体を登録することなく、バリアントラベルを追加または削除することはできません。ラベルは、一度に1つの登録バンドルのみに存在します。既存のパッケージに表示されるバリアントと一致するバリアントを生成する新しいラベルが登録されている場合、そのバリアントは単に2番目のパッケージに含まれていません。最初のパッケージのその後の登録は、バリアントを2番目のパッケージに追加しません。他のモデルでこれを変更することは可能かもしれませんが、JETの結論は、他のオプションが実装および操作するには非常に複雑すぎて、多くの新しいタイプの名前の競合を引き起こすということでした。
A registry has three options for handling the case where the registration bundle contains more than one label. The policy options are:
レジストリには、登録バンドルに複数のラベルが含まれているケースを処理するための3つのオプションがあります。ポリシーオプションは次のとおりです。
o Register and resolve all labels in the zone, making the zone information identical to that of the registered labels. This option will allow end users to find names with variants more easily, but will result in larger zone files. For some language tables, the zone file could become so large that it could negatively affect the ability of the registry to perform name resolution. If the base registration contains several characters that have equivalents, the owner could end up having to take care of large numbers of zones. For instance, if DIGIT ONE is a variant of LATIN SMALL LETTER L, the owner of the domain name all-lollypops.example.com will have to manage 32 zones. If the intent is to keep the contents of those zones identical, the owner may then face a significant administrative problem. If other concerns dictate short times to live and absolute consistency of DNS responses, the challenges may be nearly impossible.
o ゾーン内のすべてのラベルを登録および解決し、ゾーン情報を登録ラベルと同じようにします。このオプションにより、エンドユーザーはバリアントのある名前をより簡単に見つけることができますが、より大きなゾーンファイルになります。一部の言語テーブルの場合、ゾーンファイルは非常に大きくなる可能性があるため、レジストリが名前の解決を実行する能力に悪影響を与える可能性があります。基本登録に同等の文字があるいくつかの文字が含まれている場合、所有者は多数のゾーンの世話をしなければならない可能性があります。たとえば、Digit OneがLatin Small Letter Lのバリアントである場合、ドメイン名All-LollyPops.example.comの所有者は32ゾーンを管理する必要があります。これらのゾーンの内容を同一に保つ意図がある場合、所有者は重大な管理上の問題に直面する可能性があります。他の懸念が、DNS応答の生きた一貫性と絶対的な一貫性に短い時間を決定する場合、課題はほとんど不可能かもしれません。
o Block all labels other than the registered label so they cannot be registered in the future. This option does not increase the size of the zone file and provides maximum safety against false positives, but it may cause end users to not be able to find names with variants that they would expect. If the base registration contains characters that have equivalents, Internet users who do not know what base characters were used in the registration will not know what character to type in to get a DNS response. For instance, if DIGIT ONE is a variant of LATIN SMALL LETTER L, and LATIN SMALL LETTER L is a variant of DIGIT ONE, the user who sees "pale.example.com" will not know whether to type a "1" or a "l" after the "pa" in the first label.
o 登録されたラベル以外のすべてのラベルをブロックして、将来登録できないようにします。このオプションは、ゾーンファイルのサイズを増やすことはなく、誤検知に対して最大の安全性を提供しますが、エンドユーザーが予想されるバリアントを持つ名前を見つけることができなくなる可能性があります。基本登録に同等のキャラクターが含まれている場合、登録で使用されているベース文字がわからないインターネットユーザーは、DNS応答を取得するために入力する文字がわかりません。たとえば、1桁がラテン語の小文字Lのバリアントであり、ラテン語の小文字Lが数字のバリアントである場合、「pale.example.com」を見るユーザーは、最初のラベルの「PA」の後に「1」と入力するか「L」を入力するかどうかはわかりません。
o Resolve some labels and block some other labels. This option is likely to cause the most confusion with users because including some variants will cause a name to be found, but using other variants will cause the name to be not found. For example, even if people understood that DIGIT ONE and LATIN SMALL LETTER L were variants, a typical DNS user wouldn't know which character to type because they wouldn't know whether this pair were used to register or block the labels. However, this option can be used to balance the desires of the name owner (that every possible attempt to enter their name will work) with the desires of the zone administrator (to make the zone more manageable and possibly to be compensated for greater amounts of work needed for a single registration). For many circumstances, it may be the most attractive option.
o いくつかのラベルを解決し、他のいくつかのラベルをブロックします。一部のバリエーションを含めると名前が見つかるため、このオプションはユーザーとの最も混乱を引き起こす可能性がありますが、他のバリアントを使用すると名前が見つかりません。たとえば、桁数とラテン語の小文字Lがバリエーションであることを人々が理解したとしても、典型的なDNSユーザーは、このペアがラベルの登録またはブロックに使用されているかどうかを知らないため、入力する文字を知りません。ただし、このオプションは、名前の所有者（名前を入力しようとするすべての試みが機能すること）の希望のバランスをとるために使用できます。多くの状況では、それは最も魅力的な選択肢かもしれません。
In all cases, at least the registered label should appear in the zone. It would be almost impossible to describe to name owners why the name that they asked for is not in the zone, but some other name that they now control is. By implication, if the requested label is already registered, the entire registration request must be rejected.
いずれの場合も、少なくとも登録されたラベルがゾーンに表示されるはずです。なぜ所有者に要求した名前がゾーンにないのかを説明することは、ほとんど不可能ですが、現在コントロールしている他の名前です。含意により、要求されたラベルがすでに登録されている場合、登録要求全体を拒否する必要があります。
Historically, DNS labels were considered to be arbitrary identifier strings, without any inherent meaning. Even in ASCII, there was no requirement that labels form words. Labels that could not possibly represent words in any Romance or Germanic language (the languages that have been written in "Latin" scripts since medieval times or earlier) have actually been quite common. In general, in those languages, words contain at least one vowel and do not have embedded numbers. As a result, a string such as "bc345df" cannot possibly be a "word" in these languages. More generally, the more one moves toward "language"-based registry restrictions, the less it is going to be possible to construct labels out of fanciful strings. While fanciful strings are terrible candidates for "words", they may make very good identifiers. To take a trivial example using only ASCII characters, "rtr32w", "rtr32x", and "rtr32z" might be very good DNS labels for a particular zone and application. However, given the embedded digits and lack of vowels, they, like the "bc345df" example given above, would fail even the most superficial of tests for valid English (or German or French (etc.)) word forms.
歴史的に、DNSラベルは、固有の意味なしに、任意の識別子文字列であると考えられていました。ASCIIでさえ、ラベルが単語を形成するという要件はありませんでした。ロマンスやゲルマン語で単語を表すことができないラベル（中世以前以来「ラテン語」スクリプトで書かれている言語）は、実際には非常に一般的でした。一般に、これらの言語では、単語には少なくとも1つの母音が含まれており、数字が埋め込まれていません。その結果、「BC345DF」などの文字列は、これらの言語では「単語」になることはできません。より一般的には、「言語」ベースのレジストリ制限に向かって移動するほど、空想的な文字列からラベルを構築することは少なくなります。空想的な弦は「言葉」のひどい候補ですが、非常に優れた識別子を作るかもしれません。ASCII文字のみを使用して些細な例を挙げると、「RTR32W」、「RTR32X」、および「RTR32Z」は、特定のゾーンとアプリケーションに非常に優れたDNSラベルかもしれません。ただし、埋め込まれた数字と母音の不足を考えると、上記の「BC345DF」の例のように、有効な英語（またはドイツ語またはフランス語（など））の単語形式の最も表面的なテストでさえ失敗します。
It is worth noting that several DNS experts have suggested that a number of problems could be solved by prohibiting meaningful names in labels, requiring instead that the labels be random or nonsense strings. If methods similar to those discussed in this document were used to force identifiers to be closer to meaningful words in real languages, the result would be directly contradictory to those "random name" approaches.
いくつかのDNSの専門家が、ラベルの意味のある名前を禁止することで多くの問題を解決できることを示唆していることは注目に値します。このドキュメントで説明した方法と同様の方法を使用して、識別子を実際の言語で意味のある単語に近づけるように強制した場合、結果はそれらの「ランダム名」アプローチと直接矛盾します。
Interestingly, if one were trying to develop an "only words" system, a rather different -- but very restrictive -- model could be developed using lookups in a dictionary for the relevant language and a listing of valid business names for the relevant area. If a string did not appear in either, it would not be permitted to be registered. Models that require a prior national business listing (or registration) that is identical to the proposed domain name label have historically been used to restrict registrations in some country-code top level domains, so this is not a new idea. On the other hand, if look-alike characters are a concern, even that type of rule (or restriction) would still not avoid the need to consider character variants.
興味深いことに、「唯一の単語」システムを開発しようとしている場合、関連する言語の辞書のルックアップと関連領域の有効なビジネス名のリストを使用して、かなり異なる - 非常に制限的な - モデルを開発できます。文字列も表示されなかった場合、登録することは許可されません。提案されたドメイン名ラベルと同一の以前の国家ビジネスリスト（または登録）を必要とするモデルは、一部の国コードのトップレベルドメインの登録を制限するために歴史的に使用されてきたため、これは新しいアイデアではありません。一方、見た目のようなキャラクターが懸念事項である場合、そのタイプのルール（または制限）でさえ、キャラクターのバリエーションを考慮する必要性を避けません。
Consequently, registries applying the principles outlined in this document should be careful not to apply more severe restrictions than are reasonable and appropriate while, at the same time, being aware of how difficult it usually is to add restrictions at a later time.
したがって、このドキュメントで概説されている原則を適用するレジストリは、合理的かつ適切であると同時に、後で制限を追加することが通常どれほど難しいかを認識していると同時に、より厳しい制限を適用しないように注意する必要があります。
The JET model was designed for CJK characters. The discussion above implies that some extensions to it may be needed to handle the characteristics of various alphabetic scripts and the decisions that might be made about them in different zones. Those extensions might include facilities to process:
ジェットモデルは、CJK文字用に設計されています。上記の議論は、さまざまなアルファベットのスクリプトの特性と、異なるゾーンでそれらについて行われる可能性のある決定を処理するために、それに対するいくつかの拡張が必要になる可能性があることを意味します。これらの拡張機能には、処理する施設が含まれる場合があります。
o Two-character (or more) sequences, such as ligatures and typographic spelling conventions, as variants.
o バリエーションとして、字系や誤字のスペルコンベンションなどの2文字（またはそれ以上）シーケンス。
o Regular expressions or some other mechanism for dealing with string positions of characters (e.g., characters that must, or must not, appear at the beginning or end of strings).
o 文字列の位置を扱うための正規表現またはその他のメカニズム（たとえば、文字列の開始または終了時に表示されなければならない、またはしなければならない文字）。
o Delimiter breaks to permit multiple languages to be used, separately, within the same label. E.g., is it possible to define a label as consisting of two or more components, each in a different language, with some particular delimiter to define the boundaries of the components?
o Delimiterは、同じラベル内で別々に複数の言語を使用できるようにするために壊れます。たとえば、ラベルを2つ以上のコンポーネントで構成されるものとして定義することは可能ですか？それぞれが異なる言語で、コンポーネントの境界を定義するための特定の区切り文字を備えていますか？
After examining the implications of the potential use of the full range of characters permitted by IDNA in DNS labels, multiple groups, including IESG [IESG-IDN] and ICANN [ICANN-IDN] [ICANN-IDN2], have concluded that some restrictions are needed to prevent many forms of user confusion about the actual structure of a name or the word, phrase, or term that it appears to spell out. The best way to approach such restrictions appears to draw from the language and culture of the community of registrants and users in the relevant zone: if particular characters are likely to be surprising or unintelligible to both of those groups, it is probably wise to not permit them to be used in registrations. Registration restrictions can be carried much further than restricting permitted characters to a selected Unicode subset. The idea of a reserved "bundle" of related labels permits probably-confusing combinations or sets of characters to be bound together, under the control of a single registrant. While that registrant might still use the package in a way that confused his or her own users (the approach outlined here will not prevent either ill-though-out ideas or stupidity), the possibility of turning potential confusion into a hostile attack would be considerably reduced.
IDNAがDNSラベルで許可する全範囲の文字の潜在的な使用の意味を調べた後、IESG [IESG-IDN]やICANN [ICANN-IDN] [ICANN-IDN2]を含む複数のグループは、名前または単語の綴り、または用語の実際の構造に関するユーザー混乱の多くの形態のユーザー混乱を防ぐために、いくつかの制限が必要であると結論付けました。このような制限にアプローチする最良の方法は、関連するゾーンの登録者とユーザーのコミュニティの言語と文化から引き出されるように見えます。特定のキャラクターがこれらのグループの両方に驚くべきか理解できない可能性が高い場合、登録で使用することを許可しないことはおそらく賢明です。登録制限は、許可された文字を選択したユニコードサブセットに制限するよりもはるかに携帯することができます。関連するラベルの予約された「バンドル」のアイデアにより、おそらく1人の登録者の制御の下で、おそらく組み合わせた組み合わせまたはキャラクターのセットを一緒に結合することができます。その登録者は、自分のユーザーを混乱させる方法でパッケージを使用する可能性がありますが（ここで概説したアプローチは、不正なアイデアや愚かさのいずれかを防ぎません）が、潜在的な混乱を敵対的な攻撃に変える可能性はかなり減少します。
At the same time, excessive restrictions may make DNS identifiers less useful for their original purpose: identifying particular hosts and similar resources on the network in an orderly way. Registries creating rules and policies about what can be registered in particular zones -- whether those are based on the JET Guidelines or the suggestions in this document -- should balance the need for restrictions against the need for flexibility in constructing identifiers.
同時に、過度の制限により、DNS識別子が元の目的ではあまり役に立たない場合があります。特定のホストと同様のリソースを整然とした方法で識別します。特定のゾーンで登録できるものに関するルールとポリシーを作成するレジストリは、ジェットガイドラインまたはこのドキュメントの提案に基づいているかどうかにかかわらず、識別子を構築する柔軟性の必要性に対する制限の必要性のバランスをとる必要があります。
The discussion above provides many options that could be selected, defined, and applied in different ways in different registries (zones). Registrars and registrants would almost certainly prefer systems in which they can predict, at least to a first order approximation, the implications of a particular potential registration. Predictability of that sort probably requires more standards, and less flexibility, than the model itself might suggest.
上記の議論は、さまざまなレジストリ（ゾーン）で異なる方法で選択、定義、適用できる多くのオプションを提供します。レジストラと登録者は、少なくとも一次近似まで、特定の潜在的な登録の意味を予測できるシステムをほぼ確実に好むでしょう。その種の予測可能性には、おそらくモデル自体が示唆するよりも多くの標準と柔軟性が低下する必要があります。
The format of the table is meant to be machine-readable but not human-readable. It is fairly trivial to convert the table into one that can be read by people.
テーブルの形式は、機械可読ではありますが、人間が読み取ることはできません。テーブルを人々が読むことができるものに変換することはかなり些細なことです。
Each character in the table is given in the "U+" notation for Unicode characters. The lines of the table are terminated with either a carriage return character (ASCII 0x0D), a linefeed character (ASCII 0x0A), or a sequence of carriage return followed by linefeed (ASCII 0x0D 0x0A). The order of the lines in the table may or may not matter, depending on how the table is constructed.
テーブル内の各文字は、Unicode文字の「u」表記に記載されています。テーブルの線は、キャリッジリターン文字（ASCII 0x0D）、ラインフィード文字（ASCII 0x0A）、またはラインフィード（ASCII 0x0D 0x0A）のシーケンスのシーケンスで終了します。テーブル内の線の順序は、テーブルの構築方法に応じて、重要である場合とそうでない場合があります。
Comment lines in the table are preceded with a "#" character (ASCII 0x2C).
テーブルのコメント行の前には、「＃」文字（ASCII 0x2C）が付いています。
Each non-comment line in the table starts with the character that is allowed in the registry and expected to be used in registrations, which is also called the "base character". If the base character has any variants, the base character is followed by a vertical bar character ("|", ASCII 0x7C) and the variant string. If the base character has more than one variant, the variants are separated by a colon (":", ASCII 0x3A). Strings are given with a hyphen ("-", ASCII 0x2D) between each character. Comments beginning with a "#" (ASCII 0x2C), and may be preceded by spaces (" ", ASCII 0x20).
テーブル内の各非コメントラインは、レジストリで許可され、登録で使用されると予想される文字から始まります。これは「ベース文字」とも呼ばれます。ベース文字にバリアントがある場合、ベース文字の後に垂直バー文字（ "|"、ASCII 0x7c）とバリアント文字列が続きます。ベース文字に複数のバリアントがある場合、バリアントはコロン（ "："、ascii 0x3a）によって分離されます。文字列は、各文字の間にハイフン（ " - "、ascii 0x2d）で与えられます。「＃」（ASCII 0x2C）で始まるコメント、およびスペース（ ""、ASCII 0x20）が先行する場合があります。
The following is an example of how a table might look. The entries in this table are purposely silly and should not be used by any registry as the basis for choosing variants. For the example, assume that the registry:
以下は、テーブルがどのように見えるかの例です。この表のエントリは意図的に愚かであり、バリアントを選択するための基礎としてレジストリでは使用すべきではありません。例については、レジストリを想定してください。
o allows the FOR ALL character (U+2200) with no variants
o バリアントがないすべてのキャラクター（u2200）を許可します
o allows the COMPLEMENT character (U+2201) which has a single variant of LATIN CAPITAL LETTER C (U+0043)
o ラテン語のキャピタルレターC（U 0043）の単一のバリアントを持つ補数文字（U 2201）を許可します
o allows the PROPORTION character (U+2237) which has one variant which is the string COLON (U+003A) COLON (U+003A)
o ストリングコロン（u 003a）コロン（u 003a）である1つのバリアントを持つ比率文字（u 2237）を許可します
o allows the PARTIAL DIFFERENTIAL character (U+2202) which has two variants: LATIN SMALL LETTER D (U+0064) and GREEK SMALL LETTER DELTA (U+03B4)
o ラテンの小さな文字D（U 0064）とギリシャの小さな文字デルタ（U 03B4）の2つのバリエーションを持つ部分微分文字（U 2202）を許可します。
The table contents (after any required header information, see [IANA-language-registry] and the discussion in Section 7 below) would look like:
テーブルの内容（必要なヘッダー情報の後、[iana-language-registry]と以下のセクション7の議論を参照）は次のようになります。
# An example of a table
U+2200
U+2201|U+0043
U+2237|U+003A-U+003A # Note that the variant is a string
U+2202|U+0064:U+03B4 # Two variants for the same character
Implementers of table processors should remember that there are tens of thousands of characters whose codepoints are greater than 0xFFFF. Thus, any program that assumes that each character in the table is represented in exactly six octets ("U", "+", and four octets representing the character value) will fail with tables that use characters whose value is greater than 0xFFFF.
テーブルプロセッサの実装者は、コードポイントが0xffffを超える数万の文字があることを覚えておく必要があります。したがって、テーブル内の各文字が正確に6オクテット（ "u"、 ""、およびキャラクター値を表す4つのオクテット）で表されると仮定するプログラムは、値が0xffffを超える文字を使用するテーブルで失敗します。
This procedure has three inputs:
この手順には3つの入力があります。
1. the proposed base registration,
1. 提案された基本登録、
2. the language (or script, if the registration is script-based, but "language" is used for convenience below) for the proposed base registration, and
2. 言語（またはスクリプト、登録がスクリプトベースであるが、提案された基本登録のために「言語」が以下の利便性に使用される場合）、および
3. the processing table associated with that language.
3. その言語に関連付けられた処理テーブル。
The output of the process is either failure (the base registration cannot be registered at all), or a registration bundle that contains one or more labels (always including the base registration). As described earlier, the registration bundle should be stored with its date of creation so that issues with overlapping elements between bundles can later be resolved on a first-come, first-served basis.
プロセスの出力は、障害（基本登録はまったく登録できません）、または1つ以上のラベル（常に基本登録を含む）を含む登録バンドルです。前述のように、登録バンドルは作成日とともに保存する必要があります。そのため、バンドル間の重複要素の問題は、後で先着順で解決できます。
There are two steps to processing the registration:
登録を処理するための2つの手順があります。
1. Check whether the proposed base registration exists in any bundle. If it does, stop immediately with a failure.
1. 提案されたベース登録が任意のバンドルに存在するかどうかを確認してください。もしそうなら、障害ですぐに停止します。
2. Process the base registration with the mechanism described as "CreateBundle" in Section 6.1, below.
2. 以下のセクション6.1で「CreateBundle」として記述されたメカニズムを使用したベース登録を処理します。
Note that the process must be executed only once. The process must not be performed on any output of the process, only on the proposed base registration.
プロセスは一度だけ実行する必要があることに注意してください。プロセスは、プロセスの出力で、提案された基本登録でのみ実行されないでください。
The CreateBundle mechanism determines whether a registration bundle can be created and, if so, populates that bundle with valid labels.
CreateBundleメカニズムは、登録バンドルを作成できるかどうかを決定し、その場合、そのバンドルに有効なラベルを入力します。
During the processing, a "temporary bundle" contains partial labels, that is, labels that are being built and are not complete labels. The partial labels in the temporary bundle consist of strings.
処理中、「一時バンドル」には、部分的なラベル、つまり、構築されており、完全なラベルではないラベルが含まれています。一時的なバンドルの部分ラベルは、文字列で構成されています。
The steps are:
手順は次のとおりです。
1. Split the base registration into individual characters, called "candidate characters". Compare every candidate character against the base characters in the table. If any candidate character does not exist in the set of base characters, the system must stop and not register any names (that is, it must not register either the base registration or any labels that would have come from character variants).
1. ベース登録を「候補文字」と呼ばれる個々の文字に分割します。すべての候補文字をテーブル内のベース文字と比較します。候補文字がベース文字のセットに存在しない場合、システムは停止し、名前を登録しない必要があります（つまり、ベース登録または文字バリアントから来たラベルを登録しないでください）。
2. Perform the steps in IDNA's ToASCII sequence for the base registration. If ToASCII fails for the base registration, the system must stop and not register any label (that is, it must not register either the base registration or labels that might have been created from variants of characters contained in it). If ToASCII succeeds, place the base registration into the registration bundle.
2. 基本登録のためにIDNAのToasciiシーケンスの手順を実行します。Toasciiが基本登録に対して失敗した場合、システムはラベルを登録しないでください（つまり、基本登録またはその中に含まれる文字のバリエーションから作成された可能性のあるラベルのいずれかを登録してはなりません）。Toasciiが成功した場合は、基本登録を登録バンドルに配置します。
3. For every candidate character in the base registration, do the following: o Create the set of characters that consists of the candidate character and any variants.
3. 基本登録のすべての候補文字について、次のことを実行します。o候補文字と任意のバリアントで構成される文字のセットを作成します。
o For each character in the set from the previous step, duplicate the temporary bundle that resulted from the previous candidate character, and add the new character to the end of each partial label.
o 前のステップのセット内の各文字について、前の候補文字から生じる一時的なバンドルを複製し、各部分ラベルの最後に新しい文字を追加します。
4. The temporary bundle now contains zero or more labels that consist of Unicode characters. For every label in the temporary bundle, do the following:
4. 一時的なバンドルには、Unicode文字で構成されるゼロ以上のラベルが含まれています。一時的なバンドルのすべてのラベルについて、次のことを行います。
o Process the label with ToASCII to see if ToASCII succeeds. If it does, add the label to the registration bundle. Otherwise, do not process this label from the temporary bundle any further; it will not go into the registration bundle.
o Toasciiでラベルを処理して、Toasciiが成功するかどうかを確認します。もしそうなら、登録バンドルにラベルを追加します。それ以外の場合は、一時的なバンドルからこのラベルをさらに処理しないでください。登録バンドルには入りません。
The result of the processing outlined above is the registration bundle with the base registration and possibly other labels.
上記の処理の結果は、基本登録および場合によっては他のラベルを備えた登録バンドルです。
It is clear that, for many scripts, registries will choose to create tables without variants, either because variants are clearly not necessary or because they are determined to cause more confusion and overhead than is justified by the circumstances. For those situations the table model of Section 5 becomes a trivial listing of base characters and only the first two steps of CreateBundle (verifying that all candidate character are in the base ("valid") character list and verifying that the resulting characters will succeed in the ToASCII operation) are applicable. Even the second of those steps becomes pro forma if the advice in the next subsection is followed.
多くのスクリプトで、レジストリはバリアントのないテーブルを作成することを選択することは明らかです。なぜなら、バリアントは明らかに必要ではないか、状況によって正当化されるよりも多くの混乱と頭上を引き起こすと判断されているからです。これらの状況では、セクション5のテーブルモデルはベース文字の些細なリストになり、CreateBundleの最初の2つのステップのみ（すべての候補文字がベース（「有効」）文字リストにあることを確認し、結果のキャラクターがToascii操作で成功することを確認します）が適用可能であることを確認します。次のサブセクションのアドバイスに従えば、これらの手順の2番目でさえプロフォーマになります。
One of the functions of Nameprep, and IDNA more generally, is to map a large number of Unicode characters (code points) into a smaller number to avoid a different but overlapping set of confusion problems. For example, when a non-ASCII script makes distinctions between "upper case" and "lower case", nameprep maps the upper case characters to the lower case ones in order to simulate the DNS protocol's rule that ASCII characters are interpreted in a case-insensitive way. Unicode also contains many code points that are typographic variants on each other (e.g., forms with different widths and code points that designate font variations for mathematical uses), the Unicode standard explicitly identifies them that way, and Nameprep maps these onto base characters.
NAMEPREPおよびIDNAの機能の1つは、より一般的には、多数のユニコード文字（コードポイント）を少数の数字にマッピングして、異なるが重複する混乱の問題を回避することです。たとえば、ASCII以外のスクリプトが「大文字」と「小文字」を区別する場合、NamePrepはASCII文字がケースに依存しない方法で解釈されることをDNSプロトコルのルールをシミュレートするために、大文字の文字を小文字にマッピングします。Unicodeには、互いにタイポグラフィーバリアントである多くのコードポイント（たとえば、数学的使用のフォントバリエーションを指定する異なる幅とコードポイントを持つフォーム）を含み、Unicode標準はそれらをその方法で明示的に識別し、NamePrepはこれらをベース文字にマッピングします。
While having these mapping functions available during lookup may be quite helpful to users who type equivalent forms, registrations are probably best performed in terms of the IDNA base characters only, i.e., those characters that nameprep will not change. This will have two advantages.
ルックアップ中にこれらのマッピング関数を利用できるようにすることは、同等のフォームを入力するユーザーにとって非常に役立つ場合がありますが、登録はおそらくIDNAベース文字のみの観点から最もよく実行されること、つまりNAMEPREPが変更しない文字。これには2つの利点があります。
o Registrants will never find themselves in the rather confusing position of having submitted one string for registration and finding a different string in the registry database (which could otherwise occur even if the relevant language table does not contain variants).
o 登録者は、登録のために1つの文字列を送信し、レジストリデータベースに別の文字列を見つけるというかなり混乱する位置に自分自身を見つけることはありません（関連する言語テーブルにバリアントが含まれていない場合でも、それ以外の場合は発生する可能性があります）。
o Those who are interested in what characters are permitted by a given registry will only need to examine the relevant tables, rather than simulating the IDNA algorithm to determine the result of processing particular characters.
o 特定のレジストリで許可されている文字に興味がある人は、特定の文字を処理する結果を決定するためにIDNAアルゴリズムをシミュレートするのではなく、関連するテーブルを調べるだけでいいでしょう。
Under ICANN (not IETF) direction and management, the IANA has created a registry for language variant tables. The authoritative documentation for that registry is in [IANA-language-registry]. Since the registry exists and is being managed under ICANN direction, the material that follows is a review of the theory of this registry, rather than new instructions for IANA.
ICANN（IETFではなく）の方向性と管理の下で、IANAは言語バリアントテーブルのレジストリを作成しました。そのレジストリの権威ある文書は[iana-language-registry]にあります。レジストリは存在し、ICANN方向の下で管理されているため、次の資料は、IANAの新しい指示ではなく、このレジストリの理論のレビューです。
As described above and suggested in the JET Guidelines, the registration rules generally require only that:
上記とジェットガイドラインで提案されているように、登録規則には通常、それのみが必要です。
o The application be submitted or endorsed by a TLD registry, to ensure that someone cares about the particular table.
o アプリケーションは、誰かが特定のテーブルを気にすることを確認するために、TLDレジストリによって提出または承認されます。
o The table be identified by the following:
o テーブルは以下で識別されます。
* the name -- usually the top-level domain name -- of the submitting or endorsing registry;
* 名前（通常はトップレベルのドメイン名）が送信または承認のレジストリの名前。
* one of: a language designation (consistent with [RFC3066] or with some other system approved by the IANA), a script designation, a combination of the two, or a sequence number acceptable to IANA for this purpose;
* 1つ：言語指定（[RFC3066]またはIANAによって承認された他のシステムと一致）、スクリプト指定、2つの組み合わせ、またはこの目的のためにIANAに許容できるシーケンス番号。
* a version number; and
* バージョン番号。と
* a date.
* デート。
o Characters listed in the table be identified by Unicode code points, as discussed above.
o 表にリストされている文字は、上記で説明したように、Unicodeコードポイントで識別されます。
o The table format may correspond to that identified in [RFC3743], or in Section 5 above, or may be some variation on those themes appropriate to the local processing model (with or without variants).
o テーブル形式は、[RFC3743]または上記のセクション5で識別されたものに対応する場合があります。または、ローカル処理モデルに適したテーマ（バリエーションの有無にかかわらず）に適切なテーマのバリエーションがある場合があります。
This raises some issues that will need to be worked out as experiences accumulate. For example, more standardization of table formats would be desirable to allow processing by the same computer tools for different registries and languages. But standardization seems premature at this time due to differences in languages, processing, and requirements and lack of experience with them. Similarly, if a registry concludes that it should use a table that contains characters from several scripts, it is not clear how such a table should be designated. Identifying it with a language code (either according to [RFC3066] or an independent code registered with IANA) is likely to just introduce more confusion, especially given other Internet uses of the language codes. It appears that some other convention will be needed for those cases, and it should be developed (if it has not already been established by the time this document is published).
これにより、経験が蓄積されるため、解決する必要があるいくつかの問題が発生します。たとえば、さまざまなレジストリや言語の同じコンピューターツールで処理できるように、テーブル形式のより多くの標準化が望ましいでしょう。しかし、この時点では、言語の違い、処理、要件の違い、およびそれらとの経験の欠如により、標準化は時期尚早に思えます。同様に、レジストリがいくつかのスクリプトの文字を含むテーブルを使用する必要があると結論付けている場合、そのようなテーブルをどのように指定するかは明確ではありません。言語コード（[RFC3066]に従って、またはIANAに登録された独立したコードのいずれか）でそれを識別することは、特に言語コードの他のインターネット使用を考えると、より多くの混乱をもたらす可能性があります。これらのケースには他のいくつかの条約が必要であり、開発する必要があるようです（このドキュメントが公開されるまでにまだ確立されていない場合）。
This document specifies a model mechanism for registering Internationalized Domain Names (IDNs) that can be used to reduce confusion among similar-appearing names. The proposal is designed to facilitate internationalization while permitting a balance between internationalization concerns and concerns about keeping the Internet global and domain name system references unique in the perception of the user as well as in practice.
このドキュメントは、類似の名前間の混乱を減らすために使用できる国際化ドメイン名（IDN）を登録するためのモデルメカニズムを指定します。この提案は、国際化の懸念とインターネットのグローバルおよびドメイン名システムの参照に関する懸念のバランスを許可しながら、ユーザーの認識と実際にはユニークな状態にすることを許可しながら、国際化を促進するように設計されています。
Registration of labels in the DNS that contain essentially unrestricted sequences of arbitrary Unicode characters may introduce opportunities for either attacks or simple confusion. Some of these risks, such as confusion about which character (of several that look alike) is actually intended, may be associated with the presentation form of DNS names. Others may be linked to databases associated with the DNS, e.g., with the difficulty of finding an entry in a "Whois file" when it is not clear how to enter or to search for the characters that make up a name. This document discusses a family of restrictions on the names that can be registered. Restrictions of the type described can be imposed by a DNS zone ("registry"). The document also describes some possible tools for implementing such restrictions.
任意のユニコード文字の本質的に無制限のシーケンスを含むDNSのラベルの登録は、攻撃または単純な混乱のいずれかの機会を導入する可能性があります。これらのリスクのいくつかは、実際に意図されている（いくつかのものの）キャラクターがDNS名のプレゼンテーション形式に関連付けられている可能性があるという混乱など。その他は、DNSに関連付けられたデータベースにリンクされている場合があります。たとえば、名前を構成する文字を入力する方法や検索の方法が明確でない場合、「Whoisファイル」にエントリを見つけるのが難しい場合があります。このドキュメントでは、登録できる名前の制限の家族について説明します。説明されているタイプの制限は、DNSゾーン（「レジストリ」）によって課すことができます。このドキュメントでは、このような制限を実装するためのいくつかの可能なツールについても説明しています。
While the increased number and types of characters made available by Unicode considerably increases the scale of the potential problems, the problems addressed by this document are not new. No plausible set of restrictions will eliminate all problems and sources of confusion: for example, it has often been pointed out that, even in ASCII, the characters digit-one ("1") and lower case L ("l") can easily be confused in some display fonts. But, to the degree to which security may be aided by sensible risk reduction, these techniques may be helpful.
Unicodeによって利用可能にされる数と種類の文字の種類は、潜在的な問題のスケールを大幅に増加させますが、このドキュメントで扱われる問題は新しいものではありません。もっともらしい一連の制限は、すべての問題と混乱の原因を排除することはありません。たとえば、ASCIIでさえ、いくつかのディスプレイフォントでは、キャラクターDigit-One（ "1"）および小文字L（ "l"）が簡単に混乱することができることをしばしば指摘されています。しかし、賢明なリスク削減によってセキュリティが支援される程度まで、これらの手法が役立つ場合があります。
Discussions in the process of developing the JET Guidelines were vital in developing this document and all of the JET participants are consequently acknowledged. Attempts to explain some of the issues uncovered there to, and feedback from, Vint Cerf, Wendy Rickard, and members of the ICANN IDN Committee were also helpful in the thinking leading up to this document.
JETガイドラインの開発プロセスにおける議論は、このドキュメントの開発に不可欠であり、その結果、すべてのジェット参加者が認められています。Vint Cerf、Wendy Rickard、およびICANN IDN委員会のメンバーから発見された問題のいくつかを説明しようとする試みは、この文書に至るまでの考え方にも役立ちました。
An effort by Paul Hoffman to create a generic specification for registration restrictions of this type helped to inspire this document, which takes a somewhat different, more language-oriented, approach than his initial draft. While the initial version of that draft indicated that multiple languages (or multiple language tables) for a single zone were infeasible, more recent versions [Hoffman-reg] shifted to inclusion of language-based approaches. The current version of this document incorporates considerable text, and even more ideas, from those drafts, with Paul Hoffman's generous permission.
ポール・ホフマンがこのタイプの登録制限のための一般的な仕様を作成する努力は、この文書を刺激するのに役立ちました。そのドラフトの初期バージョンは、単一のゾーンの複数の言語（または複数の言語テーブル）が実行不可能であることを示しましたが、最近のバージョン[Hoffman-Reg]は言語ベースのアプローチの含有にシフトしました。このドキュメントの現在のバージョンには、ポールホフマンの寛大な許可を得て、これらのドラフトからかなりのテキストとさらに多くのアイデアが組み込まれています。
Feedback was provided by several registry operators (of both country code and generic TLDs), including Edmon Chung and Ram Mohan of Afilias, and by ICANN and IANA staff, notably Tina Dam and Theresa Swinehart. This feedback about issues encountered in registering tables and designing IDN implementations resulted in the addition of significant clarifying text to the current version of the document.
フィードバックは、アフィリアのエドモン・チョンとラム・モハンを含むいくつかのレジストリ演算子（カントリーコードとジェネリックTLDの両方）、およびICANNとIANAのスタッフ、特にティナダムとテレサスワインハートによって提供されました。テーブルの登録とIDN実装の設計で発生した問題に関するこのフィードバックにより、ドキュメントの現在のバージョンに重要な明確化テキストが追加されました。
The opinions expressed here are the sole responsibility of the author. Some of those whose ideas and comments are reflected in this document may disagree with the conclusions the author has drawn from them. The first draft version of this document was posted in June 2003.
ここで表明された意見は、著者の唯一の責任です。この文書にアイデアやコメントが反映されている人々のいくつかは、著者がそれらから引き出された結論に反対するかもしれません。このドキュメントの最初のドラフトバージョンは、2003年6月に投稿されました。
[Daniels] P.T. Daniels and W. Bright, The World's Writing Systems, Oxford: Oxford University Press: 1996.
[ダニエルズ] P.T.ダニエルズとW.ブライト、世界のライティングシステム、オックスフォード：オックスフォード大学出版局：1996。
[Drucker] Drucker, J., "The Alphabetic Labyrinth: The Letters in History and Imagination", 1995.
[Drucker] Drucker、J。、「The Alphabetic Labyrinth：The Letters in History and Imagination」、1995。
[Hoffman-reg] Hoffman, P., "A Method for Registering Internationalized Domain Names", Work in Progress, October 2003.
[Hoffman-Reg] Hoffman、P。、「国際化されたドメイン名を登録する方法」、2003年10月、進行中の作業。
[IESG-IDN] Internet Engineering Steering Group, IETF, "IESG Statement on IDN", IESG Statement available from http://www.ietf.org/IESG/STATEMENTS/IDNstatement.txt, February 2003.
[IESG-IDN] Internet Engineeringステアリンググループ、IETF、「IDNに関するIESGステートメント」、IESGステートメントhttp://www.ietf.org/iesg/statements/idnstatement.txt、2003年2月。
[ICANN-IDN] Internet Corporation for Assigned Names and Numbers (ICANN), "Guidelines for the Implementation of Internationalized Domain Names, Version 1.0", June 2003.
[ICANN-IDN]割り当てられた名前と番号（ICANN）のインターネットコーポレーション、「国際化されたドメイン名の実装に関するガイドライン、バージョン1.0」、2003年6月。
[ICANN-IDN2] Internet Corporation for Assigned Names and Numbers (ICANN), "Guidelines for the Implementation of Internationalized Domain Names, Version 2.0", September 2005.
[ICANN-IDN2]割り当てられた名前と番号（ICANN）のインターネットコーポレーション、「国際化されたドメイン名の実装に関するガイドライン、バージョン2.0」、2005年9月。
[IANA-language-registry] Internet Assigned Numbers Authority (IANA), "IDN Language Table Registry", April 2004.
[IANA-Language-Registry]インターネットが割り当てられた数字の権限（IANA）、「IDN Language Table Registry」、2004年4月。
[LTRU-Registry] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", Work in Progress, October 2005.
[ltru-registry]フィリップス、A。、編およびM.デイビス編、「言語を識別するためのタグ」、2005年10月、進行中の作業。
[RFC952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985.
[RFC952] Harrenstien、K.、Stahl、M。、およびE. Feinler、「Dodインターネットホストテーブル仕様」、RFC 952、1985年10月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] 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月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3491] Hoffman、P。およびM. Blanchet、「NamePrep：Internationalized Domain Name（IDN）のStringPrepプロファイル」、RFC 3491、2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492] Costello、A。、「Punycode：Applications（IDNA）の国際化ドメイン名のUnicodeのブートストリングエンコーディング」、RFC 3492、2003年3月。
[RFC3536] Hoffman, P., "Terminology Used in Internationalization in the IETF", RFC 3536, May 2003.
[RFC3536] Hoffman、P。、「IETFの国際化で使用される用語」、RFC 3536、2003年5月。
[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean", RFC 3743, April 2004.
[RFC3743] Konishi、K.、Huang、K.、Qian、H。、およびY. Ko、「国際化されたドメイン名（IDN）登録および中国語、日本、韓国の管理のための共同工学チーム（JET）ガイドライン」、RFC 3743、2004年4月。
[Unicode] The Unicode Consortium, "The Unicode Standard -- Version 3.0", January 2000.
[Unicode] Unicode Consortium、「Unicode Standard-バージョン3.0」、2000年1月。
[Unicode32] The Unicode Consortium, "Unicode Standard Annex #28: Unicode 3.2", March 2002.
[Unicode32] Unicode Consortium、 "Unicode Standard Annex＃28：Unicode 3.2"、2002年3月。
Author's Address
著者の連絡先
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョンCクレンシン1770マサチューセッツアベニュー、＃322ケンブリッジ、マサチューセッツ州02140 USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびwww.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。
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://ww.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エディター機能の資金は現在、インターネット協会によって提供されています。