[要約] RFC 4690は、国際化ドメイン名（IDN）に関するレビューと推奨事項を提供するものです。その目的は、IDNの実装と使用に関する問題を特定し、改善策を提案することです。
Network Working Group J. Klensin
Request for Comments: 4690 P. Faltstrom
Category: Informational Cisco Systems
C. Karp
Swedish Museum of Natural History
IAB
September 2006
Review and Recommendations for Internationalized Domain Names (IDNs)
国際化ドメイン名（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 (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This note describes issues raised by the deployment and use of Internationalized Domain Names. It describes problems both at the time of registration and for use of those names in the DNS. It recommends that IETF should update the RFCs relating to IDNs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF. In particular, it proposes that some changes be investigated for the Internationalizing Domain Names in Applications (IDNA) standard and its supporting tables, based on experience gained since those standards were completed.
このメモは、国際化されたドメイン名の展開と使用によって提起された問題について説明しています。登録時とDNSのそれらの名前の使用の両方の問題について説明します。IETFは、IDNSに関連するRFCと、その際に従うことに従うことを推奨し、IETFの外部で必要ないくつかの作業を要約および特定することをお勧めします。特に、これらの標準が完了してから得られた経験に基づいて、アプリケーション（IDNA）標準とそのサポート表の国際化ドメイン名のいくつかの変更を調査することを提案しています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. The Role of IDNs and This Document .........................3
1.2. Status of This Document and Its Recommendations ............4
1.3. The IDNA Standard ..........................................4
1.4. Unicode Documents ..........................................5
1.5. Definitions ................................................5
1.5.1. Language ............................................6
1.5.2. Script ..............................................6
1.5.3. Multilingual ........................................6
1.5.4. Localization ........................................7
1.5.5. Internationalization ................................7
1.6. Statements and Guidelines ..................................7
1.6.1. IESG Statement ......................................8
1.6.2. ICANN Statements ....................................8
2. General Problems and Issues ....................................11
2.1. User Conceptions, Local Character Sets, and Input issues ..11
2.2. Examples of Issues ........................................13
2.2.1. Language-Specific Character Matching ...............13
2.2.2. Multiple Scripts ...................................13
2.2.3. Normalization and Character Mappings ...............14
2.2.4. URLs in Printed Form ...............................16
2.2.5. Bidirectional Text .................................17
2.2.6. Confusable Character Issues ........................17
2.2.7. The IESG Statement and IDNA issues .................19
3. Migrating to New Versions of Unicode ...........................20
3.1. Versions of Unicode .......................................20
3.2. Version Changes and Normalization Issues ..................21
3.2.1. Unnormalized Combining Sequences ...................21
3.2.2. Combining Characters and Character Components ......22
3.2.3. When does normalization occur? .....................23
4. Framework for Next Steps in IDN Development ....................24
4.1. Issues within the Scope of the IETF .......................24
4.1.1. Review of IDNA .....................................24
4.1.2. Non-DNS and Above-DNS Internationalization
Approaches .........................................25
4.1.3. Security Issues, Certificates, etc. ................25
4.1.4. Protocol Changes and Policy Implications ...........27
4.1.5. Non-US-ASCII in Local Part of Email Addresses ......27
4.1.6. Use of the Unicode Character Set in the IETF .......27
4.2. Issues That Fall within the Purview of ICANN ..............28
4.2.1. Dispute Resolution .................................28
4.2.2. Policy at Registries ...............................28
4.2.3. IDNs at the Top Level of the DNS ...................29
5. Specific Recommendations for Next Steps ........................29
5.1. Reduction of Permitted Character List .....................29
5.1.1. Elimination of All Non-Language Characters .........30
5.1.2. Elimination of Word-Separation Punctuation .........30
5.2. Updating to New Versions of Unicode .......................30
5.3. Role and Uses of the DNS ..................................31
5.4. Databases of Registered Names .............................31
6. Security Considerations ........................................31
7. Acknowledgements ...............................................32
8. References .....................................................32
8.1. Normative References ......................................32
8.2. Informative References ....................................33
While IDNs have been advocated as the solution to a wide range of problems, this document is written from the perspective that they are no more and no less than DNS names, reflecting the same requirements for use, stability, and accuracy as traditional "hostnames", but using a much larger collection of permitted characters. In particular, while IDNs represent a step toward an Internet that is equally accessible from all languages and scripts, they, at best, address only a small part of that very broad objective. There has been controversy since IDNs were first suggested about how important they will actually turn out to be; that controversy will probably continue. Accessibility from all languages is an important objective, hence it is important that our standards and definitions for IDNs be smoothly adaptable to additional scripts as they are added to the Unicode character set.
The utility of IDNs must be evaluated in terms of their application by users and in protocols: the ability to simply put a name into the DNS and retrieve it is not, in and of itself, important. From this point of view, IDNs will be useful and effective if they provide stable and predictable references -- references that are no less stable and predictable, and no less secure, than their ASCII counterparts.
This combination of objectives and criteria has proven very difficult to satisfy. Experience in developing the IDNA standard and during the initial years of its implementation and deployment suggests that it may be impossible to fully satisfy all of them and that engineering compromises are needed to yield a result that is workable, even if not completely satisfactory. Based on that experience and issues that have been raised, it is now appropriate to review some of the implications of IDNs, the decisions made in defining them, and the foundation on which they rest and determine whether changes are needed and, if so, which ones.
この目的と基準の組み合わせは、満足するのが非常に困難であることが証明されています。IDNA標準の開発の経験とその実装と展開の最初の年の間に、それらすべてを完全に満足させることは不可能である可能性があり、完全に満足のいくものでなくても実行可能な結果を生み出すためにエンジニアリングの妥協が必要であることが示唆されています。提起されたその経験と問題に基づいて、IDNの意味の一部、それらを定義する上で行われた決定、およびそれらが休息して変更が必要かどうか、そしてもしそうなら、どちらを決定した基盤を確認することが適切です。一つ。
The design of the DNS itself imposes some additional constraints. If the DNS is to remain globally interoperable, there are specific characteristics that no implementation of IDNs, or the DNS more generally, can change. For example, because the DNS is a global hierarchal administrative namespace with only a single name at any given node, there is one and only one owner of each domain name. Also, when strings are looked up in the DNS, positive responses can only reflect exact matches: if there is no exact match, then one gets an error reply, not a list of near matches or other supplemental information. Searches and approximate matchings are not possible.
DNS自体の設計には、いくつかの追加の制約が課されます。DNSがグローバルに相互運用可能なままである場合、IDNの実装、またはより一般的にDNSの実装が変更されないという特定の特性があります。たとえば、DNSは、特定のノードに単一の名前のみを持つグローバルな階層管理名空間であるため、各ドメイン名の1つの所有者のみがあります。また、DNSで文字列が検索された場合、正の応答は正確な一致のみを反映します。正確な一致がない場合、エラー返信が取得され、ほぼマッチやその他の補足情報のリストではありません。検索とおおよそのマッチングは不可能です。
Finally, because the DNS is a distributed system where any server might cache responses, and later use those cached responses to attempt to satisfy queries before a global lookup is done, every server must use the same matching criteria.
最後に、DNSは、任意のサーバーが応答をキャッシュする可能性のある分散システムであり、後でそれらのキャッシュされた応答を使用してグローバルルックアップが完了する前にクエリを満たそうとするため、すべてのサーバーは同じ一致する基準を使用する必要があります。
This document reviews the IDN landscape from an IETF perspective and presents the recommendations and conclusions of the IAB, based partially on input from an ad hoc committee charged with reviewing IDN issues and the path forward (see Section 7). Its recommendations are advice to the IETF, or in a few cases to other bodies, for topics to be investigated and actions to be taken if those bodies, after their examinations, consider those actions appropriate.
このドキュメントでは、IETFの観点からIDNランドスケープをレビューし、IDNの問題とパスのレビューを担当するアドホック委員会からの入力に部分的に基づいて、IABの推奨事項と結論を提示します（セクション7を参照）。その推奨事項は、IETFへのアドバイス、またはいくつかのケースで他の団体へのアドバイスであり、調査対象のトピックと、それらの団体が試験の後、それらの行動を適切であると考える場合に行われるアクションが行われることです。
During 2002, the IETF completed the following RFCs that, together, define IDNs:
2002年に、IETFは、IDNを定義する次のRFCを完了しました。
RFC 3454 Preparation of Internationalized Strings ("Stringprep") [RFC3454]. Stringprep is a generic mechanism for taking a Unicode string and converting it into a canonical format. Stringprep itself is just a collection of rules, tables, and operations. Any protocol or algorithm that uses it must define a "Stringprep profile", which specifies which of those rules are applied, how, and with which characteristics.
RFC 3454国際化された文字列の準備（「StringPrep」）[RFC3454]。StringPrepは、Unicode文字列を使用して標準形式に変換するための一般的なメカニズムです。StringPrep自体は、ルール、テーブル、操作のコレクションにすぎません。使用するプロトコルまたはアルゴリズムは、「StringPrepプロファイル」を定義する必要があります。これは、それらのルールが適用されている、どのように、どの特性を適用しているかを指定する必要があります。
RFC 3490 Internationalizing Domain Names in Applications (IDNA) [RFC3490]. IDNA is the base specification in this group. It specifies that Nameprep is used as the Stringprep profile for domain names, and that Punycode is the relevant encoding mechanism for use in generating an ASCII-compatible ("ACE") form of the name. It also applies some additional conversions and character filtering that are not part of Nameprep.
RFC 3490アプリケーションの国際化ドメイン名（IDNA）[RFC3490]。IDNAは、このグループの基本仕様です。NamePrepはドメイン名のStringPrepプロファイルとして使用され、Punycodeは、名前のASCII互換（「ACE」）形式を生成する際に使用する関連するエンコーディングメカニズムであることを指定します。また、NamePrepの一部ではないいくつかの追加の変換と文字フィルタリングも適用されます。
RFC 3491 Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) [RFC3491]. Nameprep is designed to meet the specific needs of IDNs and, in particular, to support case-folding for scripts that support what are traditionally known as upper- and lowercase forms of the same letters. The result of the Nameprep algorithm is a string containing a subset of the Unicode Character set, normalized and case-folded so that case-insensitive comparison can be made.
RFC 3491 NAMEPREP：国際化ドメイン名（IDN）のStringPrepプロファイル[RFC3491]。NAMEPREPは、IDNの特定のニーズを満たすように設計されています。特に、同じ文字の上部および小文字として伝統的に知られているものをサポートするスクリプトのケースフォールディングをサポートするように設計されています。NAMEPREPアルゴリズムの結果は、ユニコード文字セットのサブセットを含む文字列であり、正規化され、ケース折り畳まれているため、ケース非感受性の比較を行うことができます。
RFC 3492 Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) [RFC3492]. Punycode is a mechanism for encoding a Unicode string in ASCII characters. The characters used are the same the subset of characters that are allowed in the hostname definition of DNS, i.e., the "letter, digit, and hyphen" characters, sometimes known as "LDH".
RFC 3492 Punycode：アプリケーションの国際化ドメイン名のユニコードのブートストリングエンコーディング（IDNA）[RFC3492]。Punycodeは、ASCII文字でユニコード文字列をエンコードするメカニズムです。使用される文字は、DNSのホスト名定義で許可されている文字のサブセット、つまり「LDH」として知られる「文字、数字、およびハイフン」文字と同じです。
Unicode is used as the base, and defining, character set for IDNs. Unicode is standardized by the Unicode Consortium, and synchronized with ISO to create ISO/IEC 10646 [ISO10646]. At the time the RFCs mentioned earlier were created, Unicode was at Version 3.2. For reasons explained later, it was necessary to pick a particular, then-current, version of Unicode when IDNA was adopted. Consequently, the RFCs are explicitly dependent on Unicode Version 3.2 [Unicode32]. There is, at present, no established mechanism for modifying the IDNA RFCs to use newer Unicode versions (see Section 3.1).
Unicode is a very large and complex character set. (The term "character set" or "charset" is used in a way that is peculiar to the IETF and may not be the same as the usage in other bodies and contexts.) The Unicode Standard and related documents are created and maintained by the Unicode Technical Committee (UTC), one of the committees of the Unicode Consortium.
Unicodeは非常に大きく複雑な文字セットです。（「文字セット」または「チャーセット」という用語は、IETFに特有の方法で使用され、他のボディやコンテキストの使用と同じではない場合があります。）Unicode標準および関連文書は、Unicode Technical Committee（UTC）、Unicode Consortiumの委員会の1つ。
The Consortium first published The Unicode Standard [Unicode10] in 1991, and continues to develop standards based on that original work. Unicode is developed in conjunction with the International Organization for Standardization, and it shares its character repertoire with ISO/IEC 10646. Unicode and ISO/IEC 10646 function equivalently as character encodings, but The Unicode Standard contains much more information for implementers, covering -- in depth -- topics such as bitwise encoding, collation, and rendering. The Unicode Standard enumerates a multitude of character properties, including those needed for supporting bidirectional text. The Unicode Consortium and ISO standards do use slightly different terminology.
コンソーシアムは、1991年に最初にUnicode Standard [Unicode10]を公開し、その元の作業に基づいて標準を開発し続けています。Unicodeは、国際標準化機関と併せて開発されており、ISO/IEC 10646とのキャラクターレパートリーを共有しています。UnicodeおよびISO/IEC 10646関数は、文字エンコーディングと同等ですが、Unicode標準には、実装者のカバー、カバーの情報がはるかに多く含まれています。詳細 - ビットワイズエンコード、照合、レンダリングなどのトピック。Unicode標準は、双方向テキストをサポートするために必要なものを含む、多数の文字特性を列挙します。Unicode ConsortiumおよびISO Standardsは、わずかに異なる用語を使用しています。
The following terms and their meanings are critical to understanding the rest of this document and to discussions of IDNs more generally. These terms are derived from [RFC3536], which contains additional discussion of some of them.
以下の用語とその意味は、このドキュメントの残りの部分を理解し、より一般的にIDNの議論をするために重要です。これらの用語は[RFC3536]から派生しており、それらのいくつかの追加の議論が含まれています。
A language is a way that humans interact. The use of language occurs in many forms, including speech, writing, and signing.
言語は、人間が相互作用する方法です。言語の使用は、スピーチ、ライティング、署名など、さまざまな形で発生します。
Some languages have a close relationship between the written and spoken forms, while others have a looser relationship. RFC 3066 [RFC3066] discusses languages in more detail and provides identifiers for languages for use in Internet protocols. Computer languages are explicitly excluded from this definition. The most recent IETF work in this area, and on script identification (see below), is documented in [RFC4645] and [RFC4646].
いくつかの言語は、書かれた形と話し言葉の間に密接な関係を持っていますが、他の言語はよりゆるい関係を持っています。RFC 3066 [RFC3066]は、言語についてより詳細に議論し、インターネットプロトコルで使用する言語の識別子を提供します。コンピューター言語は、この定義から明示的に除外されています。この領域での最新のIETF作業、およびスクリプト識別（以下を参照）では、[RFC4645]および[RFC4646]で文書化されています。
A script is a set of graphic characters used for the written form of one or more languages. This definition is the one used in [ISO10646].
スクリプトは、1つ以上の言語の書かれた形式に使用されるグラフィック文字のセットです。この定義は、[ISO10646]で使用される定義です。
Examples of scripts are Arabic, Cyrillic, Greek, Han (the so-called ideographs used in writing Chinese, Japanese, and Korean), and "Latin". Arabic, Greek, and Latin are, of course, also names of languages.
スクリプトの例は、アラビア語、キリル語、ギリシャ語、漢（中国語、日本、韓国語の書面で使用されるいわゆる表意図）と「ラテン語」です。もちろん、アラビア語、ギリシャ語、ラテン語は言語の名前でもあります。
Historically, the script that is known as "Latin" in Unicode and most contexts associated with information technology standards is known in the linguistic community as "Roman" or "Roman-derived". The latter terminology distinguishes between the Latin language and the characters used to write it, especially in Republican times, from the much richer and more decorated script derived and adapted from those characters. Since IDNA is defined using Unicode and that standard used the term "LATIN" in its character names and descriptions, that terminology will be used in this document as well except when "Roman-derived" is needed for clarity. However, readers approaching this document from a cultural or linguistic standpoint should be aware that the use of, or references to, "Latin script" in this document refers to the entire collection of Roman-derived characters, not just the characters used to write the Latin language. Some other issues with script identification and relationships with other standards are discussed in [RFC4646].
歴史的に、ユニコードで「ラテン語」として知られているスクリプトと情報技術標準に関連するほとんどのコンテキストは、言語コミュニティで「ローマ」または「ローマ由来」として知られています。後者の用語は、ラテン語と、特に共和党の時代にそれを書くために使用されるキャラクターを区別し、それらのキャラクターから派生し、より豊かで装飾されたスクリプトが導き出されます。IDNAはUnicodeを使用して定義されており、その標準はキャラクター名と説明で「ラテン語」という用語を使用しているため、その用語は、「ローマ由来」が明確にするために必要な場合を除き、このドキュメントでも使用されます。ただし、文化的または言語的観点からこのドキュメントに近づく読者は、このドキュメントの「ラテンスクリプト」の使用または参照は、ローマ由来のキャラクターのコレクション全体を指していることに注意する必要があります。ラテン語。スクリプトの識別と他の標準との関係に関する他のいくつかの問題については、[RFC4646]で説明しています。
The term "multilingual" has many widely-varying definitions and thus is not recommended for use in standards. Some of the definitions relate to the ability to handle international characters; other definitions relate to the ability to handle multiple charsets; and still others relate to the ability to handle multiple languages.
「多言語」という用語には、多くの広く変動する定義があるため、標準での使用には推奨されません。定義のいくつかは、国際的なキャラクターを処理する能力に関連しています。他の定義は、複数の充電器を処理する機能に関連しています。さらに、複数の言語を処理する能力に関連しています。
While this term has been deprecated for IETF-related uses and does not otherwise appear in this document, a discussion here seemed appropriate since the term is still widely used in some discussions of IDNs.
この用語はIETF関連の使用のために非推奨であり、このドキュメントには登場しませんが、この用語はIDNのいくつかの議論でまだ広く使用されているため、ここでの議論は適切と思われました。
Localization is the process of adapting an internationalized application platform or application to a specific cultural environment. In localization, the same semantics are preserved while the syntax or presentation forms may be changed.
ローカライズは、国際化されたアプリケーションプラットフォームまたはアプリケーションを特定の文化環境に適応させるプロセスです。ローカリゼーションでは、同じセマンティクスが保存され、構文またはプレゼンテーションフォームが変更される場合があります。
Localization is the act of tailoring an application for a different language or script or culture. Some internationalized applications can handle a wide variety of languages. Typical users understand only a small number of languages, so the program must be tailored to interact with users in just the languages they know.
ローカライズは、異なる言語や台本、文化のためのアプリケーションを調整する行為です。一部の国際化されたアプリケーションは、さまざまな言語を処理できます。典型的なユーザーは、少数の言語のみを理解しているため、プログラムは、知っている言語のみでユーザーと対話するように調整する必要があります。
Somewhat different definitions for localization and internationalization (see below) are used by groups other than the IETF. See [W3C-Localization] for one example.
IETF以外のグループでは、ローカリゼーションと国際化のための多少異なる定義（以下を参照）が使用されています。一例については[W3C-Localization]を参照してください。
In the IETF, the term "internationalization" is used to describe adding or improving the handling of non-ASCII text in a protocol. Other bodies use the term in other ways, often with subtle variation in meaning. The term "internationalization" is often abbreviated "i18n" (and localization as "l10n").
Many protocols that handle text only handle the characters associated with one script (often, a subset of the characters used in writing English text), or leave the question of what character set is used up to local guesswork (which leads to interoperability problems). Adding non-ASCII text to such a protocol allows the protocol to handle more scripts, with the intention of being able to include all of the scripts that are useful in the world. It is naive (sic) to believe that all English words can be written in ASCII, various mythologies notwithstanding.
テキストを処理する多くのプロトコルは、1つのスクリプトに関連付けられた文字のみを処理します（多くの場合、英語のテキストを書く際に使用される文字のサブセット）、またはどの文字セットがローカル推測に使用されているかという問題を残します（これは相互運用性の問題につながります）。このようなプロトコルに非ASCIIテキストを追加すると、プロトコルがより多くのスクリプトを処理できます。すべての英語の単語はASCIIで書くことができると信じることは素朴です。
When the IDNA RFCs were published, the IESG and ICANN made statements that were intended to guide deployment and future work. In recent months, ICANN has updated its statement and others have also made contributions. It is worth noting that the quality of understanding of internationalization issues as applied to the DNS has evolved considerably over the last few years. Organizations that took specific positions a year or more ago might not make exactly the same statements today.
IDNA RFCSが公開されたとき、IESGとICANNは、展開と将来の作業を導くことを目的としたステートメントを作成しました。ここ数か月で、ICANNはその声明を更新し、他の人も貢献しました。DNSに適用された国際化の問題の理解の質が、ここ数年でかなり進化したことは注目に値します。1年以上前に特定の役職を科した組織は、今日まったく同じ声明を出さないかもしれません。
The IESG made a statement on IDNA [IESG-IDN]:
IESGは、IDNA [IESG-IDN]について声明を発表しました。
IDNA, through its requirement of Nameprep [RFC3491], uses equivalence tables that are based only on the characters themselves; no attention is paid to the intended language (if any) for the domain name. However, for many domain names, the intended language of one or more parts of the domain name actually does matter to the users.
IDNAは、NamePrep [RFC3491]の要件を通じて、文字自体のみに基づいている等価表を使用します。ドメイン名の意図した言語（もしあれば）には注意が払われていません。ただし、多くのドメイン名では、ドメイン名の1つ以上の部分の意図された言語が実際にユーザーにとって重要です。
Similarly, many names cannot be presented and used without ambiguity unless the scripts to which their characters belong are known. In both cases, this additional information should be of concern to the registry.
同様に、キャラクターが属するスクリプトが知られていない限り、多くの名前を曖昧さなしに提示して使用することはできません。どちらの場合も、この追加情報はレジストリにとって懸念されるべきです。
The statement is longer than this, but these paragraphs are the important ones. The rest of the statement consists of explanations and examples.
声明はこれよりも長いですが、これらの段落は重要なものです。ステートメントの残りの部分は、説明と例で構成されています。
Soon after the IDNA standards were adopted, ICANN produced an initial version of its "IDN Guidelines" [ICANNv1]. This document was intended to serve two purposes. The first was to provide a basis for releasing the Generic Top Level Domain (gTLD) registries that had been established by ICANN from a contractual restriction on the registration of labels containing hyphens in the third and fourth positions. The second was to provide a general framework for the development of registry policies for the implementation of IDNs.
IDNA標準が採用されてすぐに、ICANNは「IDNガイドライン」[ICANNV1]の初期バージョンを作成しました。このドキュメントは、2つの目的を果たすことを目的としていました。1つ目は、3番目と4番目のポジションにハイフンを含むラベルの登録に関する契約上の制限からICANNによって確立されたジェネリックトップレベルドメイン（GTLD）レジストリをリリースするための基礎を提供することでした。2つ目は、IDNSの実装のためのレジストリポリシーの開発のための一般的なフレームワークを提供することでした。
One of the key components of this framework prescribed strict compliance with RFCs 3490, 3491, and 3492. With the framework, ICANN specified that IDNA was to be the sole mechanism to be used in the DNS to represent IDNs.
このフレームワークの重要なコンポーネントの1つは、RFCS 3490、3491、および3492に厳密なコンプライアンスを規定しました。フレームワークにより、ICANNはIDNAがIDNを表すためにDNSで使用される唯一のメカニズムであることを指定しました。
Limitations on the characters available for inclusion in IDNs were mandated by two mechanisms. The first was by requiring an "inclusion-based approach (meaning that code points that are not explicitly permitted by the registry are prohibited) for identifying permissible code points from among the full Unicode repertoire." The second mechanism required the association of every IDN with a specific language, with additional policies also being language based:
IDNに含めるために利用可能な文字の制限は、2つのメカニズムによって義務付けられていました。1つ目は、「包含ベースのアプローチ（レジストリによって明示的に許可されていないコードポイントが禁止されていることを意味する）を要求することでした。2番目のメカニズムでは、すべてのIDNと特定の言語との関連付けが必要であり、追加のポリシーも言語に基づいています。
"In implementing the IDN standards, top-level domain registries will (a) associate each registered internationalized domain name with one language or set of languages, (b) employ language-specific registration and administration rules that are documented and publicly available, such as the reservation of all domain names with equivalent character variants in the languages associated with the registered domain name, and, (c) where the registry finds that the registration and administration rules for a given language would benefit from a character variants table, allow registrations in that language only when an appropriate table is available. ... In implementing the IDN standards, top-level domain registries should, at least initially, limit any given domain label (such as a second-level domain name) to the characters associated with one language or set of languages only."
「IDN標準を実装する際、トップレベルのドメインレジストリは（a）登録された各国際化ドメイン名を1つの言語または言語セットに関連付けます。登録ドメイン名に関連付けられた言語の同等の文字バリアントを持つすべてのドメイン名の留保、および（c）特定の言語の登録と管理ルールが文字バリアントテーブルの恩恵を受けることをレジストリが発見した場合、登録を許可します適切なテーブルが利用可能な場合にのみその言語。... IDN標準を実装する際に、トップレベルのドメインレジストリは、少なくとも最初は、特定のドメインラベル（セカンドレベルのドメイン名など）を関連付けられた文字に制限する必要があります1つの言語または言語のセットのみ。」
It was left to each TLD registry to define the character repertoire it would associate with any given language. This led to significant variation from registry to registry, with further heterogeneity in the underlying language-based IDN policies. If the guidelines had made provision for IDN policies also being based on script, a substantial amount of the resulting ambiguity could have been avoided. However, they did not, and the sequence of events leading to the present review of IDNA was thus triggered.
One of the responses of the TLD registries to what was widely perceived as a crisis situation was to invoke the mechanism described in the initial guidelines: "As the deployment of IDNs proceeds, ICANN and the IDN registries will review these Guidelines at regular intervals, and revise them as necessary based on experience."
危機的状況として広く認識されていたものに対するTLDレジストリの回答の1つは、最初のガイドラインで説明されているメカニズムを呼び出すことでした。経験に基づいて必要に応じて修正します。」
The pivotal requirement was the modification of the guidelines to permit script-based policies for IDNs. Further concern was expressed about the need for realistically implementable mechanisms for the propagation of TLD registry policies into the lower levels of their name trees. In addition to the anticipated increase of constraint on the protocol level, one obvious additional approach would be to replace the guidelines by an instrument that itself had clear status in the IETF's normative framework. A BCP was therefore seen as the appropriate focus for longer-term effort. The most pressing issues would be dealt with in the interim by incremental modification to the guidelines, but no need was seen for the detailed further development of those guidelines once that incremental modification was complete.
重要な要件は、IDNのスクリプトベースのポリシーを許可するためのガイドラインの変更でした。TLDレジストリポリシーを名前ツリーのより低いレベルに伝播するための現実的に実装可能なメカニズムの必要性についてさらに懸念が表明されました。プロトコルレベルでの制約の予想される増加に加えて、1つの明らかな追加のアプローチは、IETFの規範的フレームワークで明確なステータスを持っている機器にガイドラインを置き換えることです。したがって、BCPは、長期的な努力の適切な焦点と見なされていました。最も差し迫った問題は、ガイドラインへの増分変更により暫定的に対処されますが、インクリメンタルな変更が完了したら、これらのガイドラインの詳細なさらなる開発については必要ありませんでした。
The outcome of this action was a version 2.0 of the guidelines [ICANNv2], which was endorsed by the ICANN Board on November 8, 2005 for a period of nine months. The Board stated further that it "tasks the IDN working group to continue its important work and return to the board with specific IDN improvement recommendations before the ICANN Meeting in Morocco" and "supports the working group's continued action to reframe the guidelines completely in a manner appropriate for further development as a Best Current Practices (BCP) document, to ensure that the Guideline directions will be used deeper into the DNS hierarchy and within TLD's where ICANN has a lesser policy relationship."
このアクションの結果は、ガイドライン[ICANNV2]のバージョン2.0であり、2005年11月8日に9か月間ICANN委員会によって承認されました。理事会はさらに、「モロッコでのICANN会議の前に、IDNワーキンググループに重要な作業を継続し、特定のIDN改善の推奨事項で取締役会に戻るためにタスクを課し、「ワーキンググループの継続的な行動をサポートし、ガイドラインを完全に再構成するための継続的な行動をサポートしています。ガイドラインの指示がDNS階層のより深く、ICANNがより低い政策関係を持っているTLD内で、ガイドラインの指示がより深く使用されるようにするために、最良の現在のプラクティス（BCP）文書としてのさらなる開発に適しています。」
Retaining the inclusion-based approach established in version 1.0, the crucial addition to the policy framework is that:
"All code points in a single label will be taken from the same script as determined by the Unicode Standard Annex #24: Script Names at http://www.unicode.org/reports/tr24. Exception to this is permissible for languages with established orthographies and conventions that require the commingled use of multiple scripts. In such cases, visually confusable characters from different scripts will not be allowed to coexist in a single set of permissible codepoints unless a corresponding policy and character table is clearly defined."
「単一のラベルのすべてのコードポイントは、Unicode Standard Annex＃24：http://www.unicode.org/reports/tr24でスクリプト名によって決定されたのと同じスクリプトから取得されます。これの例外は、言語では許容されます。複数のスクリプトの混合された使用を必要とする確立された正書法と慣習。そのような場合、異なるスクリプトからの視覚的に混乱しやすい文字は、対応するポリシーと文字テーブルが明確に拒否されない限り、許容される単一のコードポイントのセットで共存することは許可されません。」
Additionally:
さらに：
"Permissible code points will not include: (a) line symbol-drawing characters (as those in the Unicode Box Drawing block), (b) symbols and icons that are neither alphanumeric nor ideographic language characters, such as typographic and pictographic dingbats, (c) characters with well-established functions as protocol elements, (d) punctuation marks used solely to indicate the structure of sentences."
「許容されるコードポイントには以下が含まれません。（a）シンボルドラウング文字（Unicode Box Drawing Blockのように）、（b）誤字や絵文字のDingbatsなどの英数字または表意文字の文字のいずれでもないシンボルとアイコン（b）c）プロトコル要素として十分に確立された機能を持つ文字、（d）文の構造を示すためだけに使用される句読点。」
Attention has been called to several points that are not adequately dealt with (if at all) in the version 2.0 guidelines but that ought to be included in the policy framework without waiting for the production and release of a document based on a "best practices" model. The term "BCP" above does not necessarily refer to an IETF consensus document.
バージョン2.0のガイドラインでは（もしあれば）適切に対処されていないいくつかのポイントに注意が呼ばれていますが、「ベストプラクティス」に基づいたドキュメントの生産とリリースを待つことなくポリシーフレームワークに含めるべきです。モデル。上記の「BCP」という用語は、必ずしもIETFコンセンサス文書を参照するものではありません。
The intention in November 2005 was for the recommended major revision to be put to the ICANN Board prior to its meeting in Morocco (in late June 2006), but for the changes to be collated incrementally and appear in interim version 2.n releases of the guidelines. The IAB's understanding is that, while there has been some progress with this, other issues relating to IDNs subsequently diverted much of the energy that was intended to be devoted to the more extensive treatment of the guidelines.
2005年11月の意図は、モロッコでの会議（2006年6月下旬）で行われる前にICANN委員会に推奨される大規模な改訂を行うことでしたが、変更が段階的に照合され、暫定バージョン2に表示されることでした。ガイドライン。IABの理解は、これにいくつかの進歩があったが、IDNに関連する他の問題は、その後、ガイドラインのより広範な扱いに専念することを目的としたエネルギーの多くを迂回させたということです。
This section interweaves problems and issues of several types. Each subsection outlines something that is perceived to be a problem or issue "with IDNs", therefore needing correction. Some of these issues can be at least partially resolved by making changes to elements of the IDNA protocol or tables. Others will exist as long as people have expectations of IDNs that are inconsistent with the basic DNS architecture. It is important to identify this entire range of problems because users, registrants, and policy makers often do not understand the protocol and other technical issues but only the difference between what they believe happens or should happen and what actually happens. As long as those differences exist, there will be demands for functionality or policy changes for IDNs. Of course, some of these demands will be less realistic than others, but even the realistic ones should be understood in the same context as the others.
Most of the issues that have been raised, and that are discussed in this document, exist whether IDNA remains tied to Unicode 3.2 or whether migration to new Unicode versions is contemplated. A migration path is necessary to accommodate newly-coded scripts and to permit the maximum number of languages and scripts to be represented in domain names. However, the migration issues are largely separate from those involving a single Unicode version or Version 3.2 in particular, so they have been separated into this section and Section 3.
提起された問題のほとんど、およびこのドキュメントで説明されている問題のほとんどは、IDNAがUnicode 3.2に結び付けられたままであるかどうか、または新しいUnicodeバージョンへの移行が検討されているかどうかが存在します。新しくコーディングされたスクリプトに対応し、ドメイン名で最大数の言語とスクリプトを表現できるようにするには、移行パスが必要です。ただし、移行の問題は、特に単一のユニコードバージョンまたはバージョン3.2を含むものとほぼ別個のものであるため、このセクションとセクション3に分離されています。
The labels of the DNS are just strings of characters that are not inherently tied to a particular language. As mentioned briefly in the Introduction, DNS labels that could not lexically be words in any language are possible and indeed common. There appears to be no reason to impose protocol restrictions on IDNs that would restrict them more than all-ASCII hostname labels have been restricted. For that reason, even describing DNS labels or strings of them as "names" is something of a misnomer, one that has probably added to user confusion about what to expect.
Ordinarily, people use "words" when they think of things and wish others to think of them too, for example, "orange", "tree", "restaurant" or "Acme Inc". Words are normally in a specific language, such as English or Swedish. The character-string labels supported by the DNS are, as suggested above, not inherently "words". While it is useful, especially for mnemonic value or to identify objects, for actual words to be used as DNS labels, other constraints on the DNS make it impossible to guarantee that it will be possible to represent every word in every language as a DNS label, internationalized or not.
通常、人々は物事を考えるときに「言葉」を使用し、他の人も「オレンジ」、「ツリー」、「レストラン」、「ACME Inc」など、他の人を考えてほしいと願っています。言葉は通常、英語やスウェーデン語などの特定の言語です。DNSでサポートされているキャラクター弦ラベルは、上記のように、本質的に「単語」ではありません。特にニーモニック値やオブジェクトを識別することは有用ですが、実際の単語をDNSラベルとして使用するために、DNSのその他の制約により、すべての言語のすべての単語をDNSラベルとして表現できることを保証することが不可能になります。、国際化かどうか。
When writing or typing the label (or word), a script must be selected and a charset must be picked for use with that script. The choice of charset is typically not under the control of the user on a per-word or per-document basis, but may depend on local input devices, keyboard or terminal drivers, or other decisions made by operating system or even hardware designers and implementers.
ラベル（または単語）を作成または入力するときは、スクリプトを選択する必要があり、そのスクリプトで使用するためにcharsetを選択する必要があります。憲章の選択は通常、単語ごとまたはドキュメントごとにユーザーの制御下にありませんが、ローカル入力デバイス、キーボードまたは端末ドライバー、またはオペレーティングシステムまたはハードウェアデザイナーや実装者によって行われたその他の決定に依存する場合があります。。
If that charset, or the local charset being used by the relevant operating system or application software, is not Unicode, a further conversion must be performed to produce Unicode. How often this is an issue depends on estimates of how widely Unicode is deployed as the native character set for hardware, operating systems, and applications. Those estimates differ widely, but it should be noted that, among other difficulties:
o ISO 8859 versions [ISO.8859.2003] and even national variations of ISO 646 [ISO.646.1991], are still widely used in parts of Europe;
o ISO 8859バージョン[ISO.8859.2003]およびISO 646 [ISO.646.1991]の国家的バリエーションでさえ、ヨーロッパの一部でまだ広く使用されています。
o code-table switching methods, typically based on the techniques of ISO 2022 [ISO.2022.1986] are still in general use in many parts of the world, especially in Japan with Shift-JIS and its variations; and
o 通常、ISO 2022 [ISO.2022.1986]の手法に基づいたコードテーブルスイッチング方法は、世界の多くの地域、特にシフトJISとそのバリエーションを備えた日本で一般的に使用されています。と
o computing, systems, and communications in China tend to use one or more of the national "GB" standards rather than native Unicode.
o 中国のコンピューティング、システム、および通信は、ネイティブユニコードではなく、1つ以上の国家「GB」基準を使用する傾向があります。
Additionally, not all charsets define their characters in the same way and not all preexisting coding systems were incorporated into Unicode without changes. Sometimes local distinctions were made that Unicode does not make or vice versa. Consequently, conversion from other systems to Unicode may potentially lose information.
さらに、すべてのcharセットが同じ方法でキャラクターを定義するわけではなく、すべての既存のコーディングシステムが変更なしでUnicodeに組み込まれたわけではありません。Unicodeが行わない、またはその逆の局所的な区別が作成された場合があります。その結果、他のシステムからUnicodeへの変換により、情報が失われる可能性があります。
The Unicode string that results from this processing -- processing that is trivial in a Unicode-native system but that may be significant in others -- is then used as input to IDNA.
この処理から生じるユニコード文字列 - ユニコードネイティブシステムでは些細なものであるが、他の人には重要かもしれない - はIDNAへの入力として使用されます。
While much of the discussion below is stated in terms of Unicode codings and associated rules, the IAB believes that some of the issues are actually not about the Unicode character set per se, but about how distributed matching systems operate in reality, and about what implications the distributed delayed search for stored data that characterizes the DNS has on the mapping algorithms.
以下の議論の多くはUnicode Codingsと関連するルールの観点から述べていますが、IABは、いくつかの問題は実際にはUnicode文字セット自体ではなく、分散型マッチングシステムが実際にどのように機能するか、そしてどのような意味合いについてであると考えています。マッピングアルゴリズムにDNSがあることを特徴付ける保存されたデータの分散遅延検索。
There are similar words that can be expressed in multiple languages. Consider, for example, the name Torbjorn in Norwegian and Swedish. In Norwegian it is spelled with the character U+00F8 (LATIN SMALL LETTER O WITH STROKE) in the second syllable, while in Swedish it is spelled with U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS). Those characters are not treated as equivalent according to the Unicode Standard and its Annexes while most people speaking Swedish, Danish, or Norwegian probably think they are equivalent.
複数の言語で表現できる同様の単語があります。たとえば、ノルウェーとスウェーデン語のTorbjornという名前を考えてみましょう。ノルウェー語では、2番目の音節でキャラクターU 00F8（ストローク付きラテンスモールレターO）で綴られますが、スウェーデン語ではU 00F6（ダイアエレス付きラテン小文字o）で綴られています。これらのキャラクターは、ユニコード標準とその併合に従って同等とは扱われませんが、ほとんどの人がスウェーデン、デンマーク、またはノルウェー語を話すことはおそらく同等だと考えています。
It is neither possible nor desirable to make these characters equivalent on a global basis. To do so would, for this example, rationalize the situation in Sweden while causing considerable confusion in Germany because the U+00F8 character is never used in the German language. But the "variant" model introduced in [RFC3743] and [RFC4290] can be used by a registry to prevent the worst consequence of the possible confusion, by ensuring either that both names are registered to the same party in a given domain or that one of them is completely prohibited.
これらのキャラクターをグローバルベースで同等にすることは不可能でも望ましいことでもありません。そうすることは、この例では、U 00F8文字がドイツ語では使用されないため、ドイツでかなりの混乱を引き起こしながら、スウェーデンの状況を合理化します。しかし、[RFC3743]および[RFC4290]で導入された「バリアント」モデルは、レジストリによって使用され、可能性のある混乱の最悪の結果を防ぐことができます。そのうちは完全に禁止されています。
There are languages in the world that can be expressed using multiple scripts. For example, some Eastern European and Central Asian languages can be expressed in either Cyrillic or Latin (see Section 1.5.2) characters, or some African and Southeast Asian languages can be expressed in either Arabic or Latin characters. A few languages can even be written in three different scripts. In other cases, the language is typically written in a combination of scripts (e.g., Kanji, Kana, and Romaji for Japanese; Hangul and Hanji for Korean). Because of this, the same word, in the same language, can be expressed in different ways. For some languages, only a single script is normally used to write a single word; for others, mixed scripts are required; and, for still others, special circumstances may dictate mixing scripts in labels although that is not normally done for "words". For IDN purposes, these variations make the definition of "script" extremely sensitive, especially since ICANN is now recommending that it be used as the primary basis for registry policies. However essential it may be to prohibit mixed-script labels, additional policy nuance is required for "languages with established orthographies and conventions that require the commingled use of multiple scripts".
Unicode contains several different models for representing characters. The Chinese (Han)-derived characters of the "CJK" (Chinese, Japanese, and Korean) languages are "unified", i.e., characters with common derivation and similar appearances are assigned to the same code point. European characters derived from a Greek-Latin base are separated into separate code blocks for Latin, Greek, and Cyrillic even when individual characters are identical in both form and semantics. Separate code points based on font differences alone are generally prohibited, but a large number of characters for "mathematical" use have been assigned separate code points even though they differ from base ASCII characters only by font attributes such as "script", "bold", or "italic". Some characters that often appear together are treated as typographical digraphs with specific code points assigned to the combination, others require that the two-character sequences be used, and still others are available in both forms. Some Roman-derived letters that were developed as decorated variations on the basic Latin letter collection (e.g., by addition of diacritical marks) are assigned code points as individual characters, others must be built up as two (or more) character sequences using "combining characters".
Unicodeには、文字を表現するためのいくつかの異なるモデルが含まれています。「CJK」（中国語、日本、韓国語）の中国人（han）由来の文字は「統一」されています。つまり、一般的な派生と同様の外観を持つキャラクターが同じコードポイントに割り当てられます。ギリシャラチンベースから派生したヨーロッパのキャラクターは、個々の文字が形式とセマンティクスの両方で同一である場合でも、ラテン語、ギリシャ語、キリル語の個別のコードブロックに分けられます。フォントの違いのみに基づいた個別のコードポイントは一般に禁止されていますが、「数学的」使用の多数の文字が、「スクリプト」、「太字」などのフォント属性によってのみベースASCII文字とは異なりますが、個別のコードポイントが割り当てられています。、または「イタリック」。しばしば一緒に表示される文字は、組み合わせに割り当てられた特定のコードポイントを備えたタイポグラフィのディグラフとして扱われ、他の文字は2文字のシーケンスを使用する必要があり、さらに他の文字は両方の形式で利用可能です。基本的なラテン文字コレクションの装飾されたバリエーションとして開発されたローマ由来の文字（例えば、異文性マークの追加による）は、個々の文字としてコードポイントを割り当てられ、他の文字は「組み合わせて2つ（またはそれ以上）の文字シーケンスとして構築する必要があります。文字」。
Many of these differences result from the desire to maintain backward compatibility while the standard evolved historically, and are hence understandable. However, the DNS requires precise knowledge of which codes and code sequences represent the same character and which ones do not. Limiting the potential difficulties with confusable characters (see Section 2.2.6) requires even more knowledge of which characters might look alike in some fonts but not in others. These variations make it difficult or impossible to apply a single set of rules to all of Unicode and, in doing so, satisfy everyone and their perceived needs. Instead, more or less complex mapping tables, defined on a character-by-character basis, are required to "normalize" different representations of the same character to a single form so that matching is possible.
これらの違いの多くは、標準が歴史的に進化した一方で、後方互換性を維持したいという欲求に起因し、したがって理解できます。ただし、DNSは、どのコードとコードシーケンスが同じ文字を表し、どの文字を表しているかについての正確な知識を必要とします。潜在的な困難を混乱させるキャラクター（セクション2.2.6を参照）で制限するには、一部のフォントではどのキャラクターが似ているかについてさらに多くの知識が必要です。これらのバリエーションにより、すべてのUnicodeに単一のルールセットを適用することが困難または不可能になり、そうすることで、すべての人と知覚されたニーズを満たします。代わりに、キャラクターごとに定義された多かれ少なかれ複雑なマッピングテーブルは、同じ文字の異なる表現を単一のフォームに「正規化」するために必要で、マッチングが可能になります。
Unless normalization rules, such as those that underlie Nameprep, are applied, characters that are essentially identical will not match in the DNS, creating many opportunities for problems. The most common of these problems is that, due to the processing applied (and discussed above) before a word is represented as a Unicode string, a single word can end up being expressed as several different Unicode strings. Even if normalization rules are applied, some strings that are considered identical by users will not compare equal. That problem is discussed in more detail elsewhere in this document, particularly in Section 3.2.1.
NAMEPREPの根底にあるものなどの正規化ルールが適用されない限り、本質的に同一の文字はDNSで一致しないため、問題の多くの機会が生まれます。これらの問題の最も一般的なのは、単語がユニコード文字列として表される前に適用された処理（および上記で説明した）により、単語がいくつかの異なるユニコード文字列として表されることになる可能性があることです。正規化ルールが適用されていても、ユーザーによって同一と見なされる文字列の一部は、等しく比較されません。この問題については、このドキュメントの他の場所、特にセクション3.2.1で詳細に説明します。
IDNA attempts to compensate for these problems by using a normalization algorithm defined by the Unicode Consortium. This algorithm can change a sequence of one or more Unicode characters to another set of characters. One example is that the base character U+0061 (LATIN SMALL LETTER A) followed by U+0308 (COMBINING DIAERESIS) is changed to the single Unicode character U+00E4 (LATIN SMALL LETTER A WITH DIAERESIS).
IDNAは、Unicodeコンソーシアムによって定義された正規化アルゴリズムを使用して、これらの問題を補償しようとします。このアルゴリズムは、1つ以上のUnicode文字のシーケンスを別の文字セットに変更できます。1つの例は、ベース文字u 0061（ラテンスモールレターa）に続くu 0308（diaeresisを組み合わせて）が単一のユニコード文字u 00e4（diaeresisを使用したラテン小文字a）に変更されることです。
This Unicode normalization process accounts only for simple character equivalences, not equivalences that are language or script dependent. For example, as mentioned above, the characters U+00F8 (LATIN SMALL LETTER O WITH STROKE) and U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS) are considered to match in Swedish (and some other languages), but not for all languages that use either of the characters. Having these characters be treated as equivalent in some contexts and not in others requires decisions and mechanisms that, in turn, depend much more on context than either IDNA or the Unicode character-based normalization tables can provide.
このユニコード正規化プロセスは、言語またはスクリプトに依存する等価性ではなく、単純な文字の同等性を説明します。たとえば、上記のように、文字U 00F8（ストローク付きラテンスモールレターO）およびU 00F6（ダイアエレシス付きラテンスモールレターO）は、スウェーデン語（および他の言語）で一致すると考えられていますが、使用するすべての言語ではそうではありません。どちらかの文字。これらの文字をいくつかのコンテキストで同等に扱うことであり、他の文脈ではそうではなく、IDNAまたはユニコード文字ベースの正規化テーブルが提供できるよりもはるかにコンテキストに依存する決定とメカニズムが必要です。
Additional complications occur if the sequences are more complicated or if an attacker is making a deliberate effort to confuse the normalization process. For example, if the sequence U+0069 U+0307 (LATIN SMALL LETTER I followed by COMBINING DOT ABOVE) appears, the Unicode Normalization Method known as NFKC maps it into U+00EF (LATIN SMALL LETTER I WITH DIAERESIS), which is what one would predict. But consider U+0131 U+0308 (LATIN SMALL LETTER DOTLESS I and COMBINING DIAERESIS): is that the same character? Is U+0131 U+0307 U+0307 (dotless i and two combining dot-above characters) equivalent to U+00EF or U+0069, or neither? NFKC does not appear to tell us, nor does the definition of U+0307 appear to tell us what happens when it is combined with other "symbol above" arrangements (unlike some of the "accent above" combining characters, which more or less specify kerning). Similar issues arise when U+00EF is combined with various dot-above combining characters. Each of these questions provides some opportunities for spoofing if different display implementations interpret the rules in different ways.
シーケンスがより複雑である場合、または攻撃者が正規化プロセスを混乱させるために意図的な努力をしている場合、追加の合併症が発生します。たとえば、シーケンスU 0069 U 0307（上記のDOTを組み合わせたラテンスモールレターIが上記のDOTを組み合わせた場合）が表示される場合、NFKCと呼ばれるユニコード正規化方法は、それをU 00EF（Diaeresisを備えたラテンスモールレターI）にマッピングします。。しかし、u 0131 u 0308（ラテン語の小さな文字ドットレスiとdiaeresisを組み合わせてください）：それは同じキャラクターですか？U 0131 U 0307 U 0307（ドットレスIと2つの組み合わせドットアブローブ文字）は、U 00EFまたはU 0069に相当しますか？NFKCは、U 0307の定義が他の「上記のシンボル」の配置と組み合わされたときに何が起こるかを教えてくれないようには見えません（文字を組み合わせた「上記のアクセント」の一部とは異なり、Kerningを指定します。）。U 00EFがさまざまなDOT-ABOVEを組み合わせた文字と組み合わせると、同様の問題が発生します。これらの質問のそれぞれは、異なる表示実装がルールを異なる方法で解釈する場合、スプーフィングの機会を提供します。
If we leave Latin scripts and examine those based on Chinese characters, we see there is also an absence of specific, lexigraphic, rules for transformations between Traditional and Simplified Chinese. Even if there were such rules, unification of Japanese and Korean characters with Chinese ones would make it impossible to normalize Traditional Chinese into Simplified Chinese ones without causing problems in Japanese and Korean use of the same characters.
More generally, while some mappings, such as those between precomposed Latin script characters and the equivalent multiple code point composed character sequences, depend only on the characters themselves, in many or most cases, such as the case with Swedish above, the mapping is language or culturally dependent. There have been discussions as to whether different canonicalization rules (in addition to or instead of Unicode normalization) should be, or could be, applied differently to different languages or scripts. The fact that most scripts included in Unicode have been initially incorporated by copying an existing standard more or less intact has impact on the optimization of these algorithms and on forward compatibility. Even if the language is known and language-specific rules can be defined, dependencies on the language do not disappear. Canonicalization operations are not possible unless they either depend only on short sequences of text or have significant context available that is not obvious from the text itself. DNS lookups and many other operations do not have a way to capture and utilize the language or other information that would be needed to provide that context.
より一般的には、事前に登録されたラテンスクリプト文字と同等の複数のコードポイント構成文字シーケンスの間のいくつかのマッピングは、スウェーデンの場合など、多くの場合、またはほとんどの場合、マッピングはマッピングは言語です。または文化的に依存しています。異なる標準化ルール（ユニコードの正規化に加えて、またはその代わりに）が異なる言語やスクリプトに異なる方法であるべきか、それとも異なる方法で適用できるかについての議論がありました。Unicodeに含まれるほとんどのスクリプトが、既存の標準の多かれ少なかれ無傷をコピーすることにより最初に組み込まれているという事実は、これらのアルゴリズムの最適化と前方互換に影響を与えます。言語が既知で、言語固有のルールを定義できる場合でも、言語の依存関係は消えません。標準化操作は、テキストの短いシーケンスのみに依存したり、テキスト自体から明らかではない重要なコンテキストを利用できる場合を除き、不可能です。DNSルックアップや他の多くの操作には、そのコンテキストを提供するために必要な言語やその他の情報をキャプチャして利用する方法がありません。
These variations in languages and in user perceptions of characters make it difficult or impossible to provide uniform algorithms for matching Unicode strings in a way that no end users are ever surprised by the result. For closely-related scripts or characters, surprises may even be frequent. However, because uniform algorithms are required for mappings that are applied when names are looked up in the DNS, the rules that are chosen will always represent an approximation that will be more or less successful in minimizing those user surprises. The current Nameprep and Stringprep algorithms use mapping tables to "normalize" different representations of the same text to a single form so that matching is possible.
言語のこれらのバリエーションと文字のユーザー認識は、結果に驚かないようにユニコード文字列を一致させるための均一なアルゴリズムを提供することを困難または不可能にします。密接に関連したスクリプトやキャラクターの場合、驚きが頻繁に起こるかもしれません。ただし、DNSで名前を調べたときに適用されるマッピングには均一なアルゴリズムが必要であるため、選択されたルールは常に、ユーザーの驚きを最小限に抑えることに成功する近似を表します。現在のNAMEPREPおよびSTRINGPREPアルゴリズムは、マッピングテーブルを使用して、同じテキストの異なる表現を単一のフォームに「正規化」するため、マッチングが可能になります。
More details on the creation of the normalization algorithms can be found in the Unicode Specification and the associated Technical Reports [UTR] and Annexes. Technical Report #36 [UTR36] and [UTR39] are specifically related to the IDN discussion.
正規化アルゴリズムの作成の詳細については、Unicode仕様と関連する技術レポート[UTR]および付録に記載されています。テクニカルレポート＃36 [UTR36]および[UTR39]は、特にIDNディスカッションに関連しています。
URLs and other identifiers appear, not only in electronic forms from which they can (at least in principle) be accurately copied and "pasted" but in printed forms from which the user must transcribe them into the computer system. This is often known as the "side-of-the-bus problem" because a particularly problematic version of it requires that the user be able to observe and accurately remember a URL that is quickly glimpsed in a transient form -- a billboard seen while driving, a sign on the side of a passing vehicle, a television advertisement that is not frequently repeated or on-screen for a long time, and so on.
URLおよびその他の識別子は、（少なくとも原則として）正確にコピーして「貼り付け」できる電子形式だけでなく、ユーザーがコンピューターシステムに転写する必要がある印刷された形式で表示されます。これは「バスの側面の問題」としてしばしば知られています。なぜなら、特に問題のあるバージョンでは、ユーザーが一時的な形ですぐに垣間見るURLを観察し、正確に覚えることができることを要求するためです。運転、通過する車両の側面のサイン、頻繁に繰り返されたり、画面上に繰り返されたりしないテレビ広告など。
The difficulty, in short, is that two Unicode strings that are actually different might look exactly the same, especially when there is no time to study them. This is because, for example, some glyphs in Cyrillic, Greek, and Latin do look the same, but have been assigned different code points in Unicode. Worse, one needs to be reasonably familiar with a script and how it is used to understand how much characters can reasonably vary as the result of artistic fonts and typography. For example, there are a few fonts for Latin characters that are sufficiently highly ornamented that an observer might easily confuse some of the characters with characters in Thai script. Uppercase ITC Blackadder (a registered trademark of International Typeface Corporation) and Curlz MT are two fairly obvious examples; these fonts use loops at the end of serifs, creating a resemblance to Thai (in some fonts) for some characters.
要するに、難易度は、実際に異なる2つのユニコード文字列がまったく同じように見えるかもしれないことです。特に、それらを研究する時間がない場合です。これは、たとえば、キリル語、ギリシャ語、ラテン語の一部のグリフが同じように見えますが、ユニコードで異なるコードポイントが割り当てられているためです。さらに悪いことに、芸術的なフォントとタイポグラフィの結果として合理的に変化するキャラクターの量を理解するために、スクリプトに合理的に精通している必要があります。たとえば、オブザーバーがいくつかのキャラクターをタイスクリプトのキャラクターと簡単に混同する可能性があるため、十分に装飾されているラテン文字用のいくつかのフォントがあります。大文字のITC BlackAdder（International Thipface Corporationの登録商標）とCurlz MTは、かなり明白な2つの例です。これらのフォントは、セリフの端でループを使用して、一部の文字のタイ（一部のフォント）に似ています。
Some scripts (and because of that some words in some languages) are written not left to right, but right to left. And, to complicate things, one might have something written in Arabic script right to left that includes some characters that are read from left to right, such as European-style digits. This implies that some texts might have a mixed left-to-right AND right-to-left order (even though in most implementations, and in IDNA, all texts have a major direction, with the other as an exception).
いくつかのスクリプト（そして、そのため、一部の言語ではいくつかの単語のため）は、左から右ではなく右から左に書かれています。そして、物事を複雑にするために、ヨーロッパスタイルの数字など、左から右に読まれたいくつかのキャラクターを含む、左から左のアラビア語のスクリプトに書かれたものがあるかもしれません。これは、一部のテキストには左から右への混合順序と右から左右の順序がある可能性があることを意味します（ほとんどの実装でも、IDNAでも、すべてのテキストには大きな方向性があり、他のテキストは例外があります）。
IDNA permits the inclusion of European digits in a label that is otherwise a sequence of right-to-left characters, but prohibits most other mixed-directional (or bidirectional) strings. This prohibition can cause other problems such as the rejection of some otherwise linguistically and culturally sensible strings. As Unicode and conventions for handling so-called bidirectional ("BIDI") strings evolve, the prohibition in IDNA should be reviewed and reevaluated.
IDNAは、左から左へのキャラクターのシーケンスであるラベルにヨーロッパの数字を含めることを許可しますが、他のほとんどの混合方向（または双方向）文字列を禁止しています。この禁止は、言語的および文化的に賢明な文字列を拒否するなど、他の問題を引き起こす可能性があります。いわゆる双方向（「bidi」）文字列が進化するためのユニコードと規則として、IDNAの禁止をレビューして再評価する必要があります。
Similar-looking characters in identifiers can cause actual problems on the Internet since they can result, deliberately or accidentally, in people being directed to the wrong host or mailbox by believing that they are typing, or clicking on, intended characters that are different from those that actually appear in the domain name or reference. See Section 4.1.3 for further discussion of this issue.
識別子の似たように見える文字は、インターネット上で実際の問題を引き起こす可能性があります。なぜなら、それらがタイピングしている、またはクリックしていると信じていると信じて、間違ったホストまたはメールボックスに向けられている人に向けて、意図したキャラクターとは異なる文字とは異なるキャラクターに向けられているため、インターネット上で実際の問題を引き起こす可能性があります。それは実際にドメイン名または参照に表示されます。この問題の詳細については、セクション4.1.3を参照してください。
IDNs complicate these issues, not only by providing many additional characters that look sufficiently alike to be potentially confused, but also by raising new policy questions. For example, if a language can be written in two different scripts, is a label constructed from a word written in one script equivalent to a label constructed from the same word written in the other script? Is the answer the same for words in two different languages that translate into each other?
IDNは、これらの問題を複雑にします。これは、潜在的に混乱するのに十分に似ているように見える多くの追加のキャラクターを提供するだけでなく、新しいポリシーの質問を提起することによっても複雑になります。たとえば、言語を2つの異なるスクリプトで書くことができる場合、1つのスクリプトで書かれた単語から作成されたラベルは、他のスクリプトで書かれた同じ単語から構築されたラベルに相当するものですか？答えは、互いに翻訳される2つの異なる言語の単語についても同じですか？
It is now generally understood that, in addition to the collision problems of possibly equivalent words and hence labels, it is possible to utilize characters that look alike -- "confusable" characters -- to spoof names in order to mislead or defraud users. That issue, driven by particular attacks such as those known as "phishing", has introduced stronger requirements for registry efforts to prevent problems than were previously generally recognized as important.
現在、一般的に、おそらく同等の単語の衝突問題、したがってラベルの問題に加えて、ユーザーを誤解させたり詐欺したりするために、「混乱しやすい」キャラクターを呼び起こすように見えるように見える文字を使用することが可能であることが一般的に理解されています。この問題は、「フィッシング」として知られているような特定の攻撃によって推進されており、以前は一般に重要であると認識されていたよりも、問題を防ぐためのレジストリ努力のためのより強力な要件を導入しました。
One commonly-proposed approach is to have a registry establish restrictions on the characters, and combinations of characters, it will permit to be included in a string to be registered as a label. Taking the Swedish top-level domain, .SE, as an example, a rule might be adopted that the registry "only accepts registrations in Swedish, using Latin script, and because of this, Unicode characters Latin-a, -b, -c,...". But, because there is not a 1:1 mapping between country and language, even a Country Code Top Level Domain (ccTLD) like .SE might have to accept registrations in other languages. For example, there may be a requirement for Finnish (the second most-used language in Sweden). What rules and code points are then defined for Finnish? Does it have special mappings that collide with those that are defined for Swedish? And what does one do in countries that use more than one script? (Finnish and Swedish use the same script.) In all cases, the dispute will ultimately be about whether two strings are the same (or confusingly similar) or not. That, in turn, will generate a discussion of how one defines "what is the same" and "what is similar enough to be a problem".
一般的に提案されているアプローチの1つは、レジストリにキャラクターに制限を確立することと、文字の組み合わせを作成することで、文字列にレーベルとして登録されるように含めることができます。例として、スウェーデンのトップレベルドメイン、.seを使用すると、レジストリは「スウェーデン語の登録のみを受け入れ、ラテン語のスクリプトを使用し、そのため、Unicode文字LATIN -A、-B、-Cが採用される可能性があります。、...」。しかし、国と言語の間に1：1のマッピングがないため、.SEのような国コードトップレベルのドメイン（CCTLD）でさえ、他の言語の登録を受け入れる必要があるかもしれません。たとえば、フィンランド語（スウェーデンで2番目に使用されている言語）には要件があるかもしれません。フィンランド語で定義されているルールとコードポイントは何ですか？スウェーデンのために定義されているものと衝突する特別なマッピングがありますか？そして、複数のスクリプトを使用する国では何をしますか？（フィンランド人とスウェーデン人は同じスクリプトを使用します。）すべての場合において、紛争は最終的に、2つの文字列が同じ（または混乱して類似した）かどうかについてです。それは、「同じことが何であるか」と「問題になるのに十分な類似点」をどのように定義するかについての議論を生み出します。
Another example arose recently that further illustrates the problem. If one were to use Cyrillic characters to represent the country code for Russia in a localized equivalent to the ccTLD label, the characters themselves would be indistinguishable from the Latin characters "P" and "Y" (in either lower- or uppercase) in most fonts. We presume this might cause some consternation in Paraguay.
最近、問題をさらに説明する別の例が発生しました。キリル文字を使用して、CCTLDラベルに相当するロシアのカントリーコードを表す場合、キャラクター自体は、ほとんどの場合、ラテン語のキャラクター「P」および「Y」（低いまたは大文字）と見分けがつかないでしょう。フォント。これは、パラグアイで驚きを引き起こす可能性があると思います。
These difficulties can never be completely eliminated by algorithmic means. Some of the problem can be addressed by appropriate tuning of the protocols and their tables, other parts by registry actions to reduce confusion and conflicts, and still other parts can be addressed by careful design of user interfaces in application programs. But, ultimately, some responsibility to avoid being tricked or harmfully confused will rest with the user.
これらの困難は、アルゴリズム手段によって完全に排除されることはありません。いくつかの問題は、プロトコルとそのテーブルの適切な調整、混乱や競合を減らすためのレジストリアクションによる他の部分、およびアプリケーションプログラムのユーザーインターフェイスの慎重な設計によって対処することができます。しかし、最終的には、だまされたり、有害に混乱したりしないようにする責任は、ユーザーにかかっています。
Another registry technique that has been extensively explored involves looking at confusable characters and confusion between complete labels, restricting the labels that can be registered based on relationships to what is registered already. Registries that adopt this approach might establish special mapping rules such as:
広範囲に調査されている別のレジストリ手法は、紛らわしいキャラクターと完全なラベル間の混乱を調べることで、すでに登録されているものとの関係に基づいて登録できるラベルを制限します。このアプローチを採用するレジストリは、次のような特別なマッピングルールを確立する可能性があります。
1. If you register something with code point A, domain names with B instead of A will be blocked from registration by others (where B is a character at a separate code point that has a confusingly similar appearance to A).
1. コードポイントAに何かを登録すると、aの代わりにbでドメイン名が登録されます。他の人による登録からブロックされます（bは、aと混乱するような外観を持つ別のコードポイントの文字です）。
2. If you register something with code point A, you also get domain name with B instead of A.
2. コードポイントAで何かを登録すると、Aの代わりにBでドメイン名も取得します。
These approaches are discussed in more detail for "CJK" characters in RFC 3743 [RFC3743] and more generally in RFC 4290 [RFC4290].
これらのアプローチについては、RFC 3743 [RFC3743]の「CJK」文字、より一般的にはRFC 4290 [RFC4290]の「CJK」文字について詳しく説明しています。
The issues above, at least as they were understood at the time, provided the background for the IESG statement included in Section 1.6.1 (which, in turn, was part of the basis for the initial ICANN Guidelines) that a registry should have a policy about the scripts, languages, code points and text directions for which registrations will be accepted. While "accept all" might be an acceptable policy, it implies there is also a dispute resolution process that takes the problems listed above into account. This process must be designed for dealing with all types of potential disputes. For example, issues might arise between registrant and registry over a decision by the registry on collisions with already registered domain names and between registrant and trademark holder (that a domain name infringes on a trademark). In both cases, the parties disagreeing have different views on whether two strings are "equivalent" or not. They may believe that a string that is not allowed to be registered is actually different from one that is already registered. Or they might believe that two strings are the same, even though the rules adopted by the registry to prevent confusion define them as two different domain names.
上記の問題は、少なくともその時点で理解されていたように、セクション1.6.1（次に、最初のICANNガイドラインの根拠の一部である）に含まれるIESGステートメントの背景を提供しました。登録が受け入れられるスクリプト、言語、コードポイント、およびテキストの指示に関するポリシー。「すべてを受け入れる」は許容可能なポリシーかもしれませんが、上記の問題を考慮に入れる紛争解決プロセスもあることを意味します。このプロセスは、あらゆる種類の潜在的な紛争を扱うために設計する必要があります。たとえば、登録済みのドメイン名との衝突に関するレジストリによる決定に関する決定に関する問題が発生する可能性があります。どちらの場合も、同意しない当事者は、2つの文字列が「同等」であるかどうかについて異なる見解を持っています。彼らは、登録を許可されていない文字列は、実際には既に登録されている文字列とは異なると信じるかもしれません。または、混乱がそれらを2つの異なるドメイン名として定義するのを防ぐためにレジストリで採用されているルールであっても、2つの文字列が同じであると信じるかもしれません。
While opinions differ about how important the issues are in practice, the use of Unicode and its supporting tables for IDNA appears to be far more sensitive to subtle changes than it is in typical Unicode applications. This may be, at least in part, because many other applications are internally sensitive only to the appearance of characters and not to their representation. Or those applications may be able to take effective advantage of script, language, or character class identification. The working group that developed IDNA concluded that attempting to encode any ancillary character information into the DNS label would be impractical and unwise, and the IAB, based in part on the comments in the ad hoc committee, saw no reason to review that decision.
問題が実際にどれほど重要であるかについて意見は異なりますが、UnicodeとIDNAのサポート表の使用は、典型的なUnicodeアプリケーションよりも微妙な変化にはるかに敏感であるように見えます。これは、少なくとも部分的には、他の多くのアプリケーションが文字の外観のみに内部的に敏感であり、その表現ではなく、内部的に敏感であるためです。または、それらのアプリケーションは、スクリプト、言語、またはキャラクタークラスの識別を効果的に活用できる場合があります。IDNAを開発したワーキンググループは、補助文字情報をDNSラベルにエンコードしようとすることは非現実的で賢明ではないと結論付け、Ad Hoc委員会のコメントに一部基づいているIABは、その決定を検討する理由を見なかったと結論付けました。
The Unicode Consortium has sometimes used the likelihood of a combination of characters actually appearing in a natural language as a criterion for the safety of a possible change. However, as discussed above, DNS names are often fabrications -- abbreviations, strings deliberately formed to be unusual, members of a series sequenced by numbers or other characters, and so on. Consequently, a criterion that considers a change to be safe if it would not be visible in properly-constructed running text is not helpful for DNS purposes: a change that would be safe under that criterion could still be quite problematic for the DNS.
Unicodeコンソーシアムは、可能性のある変化の安全性の基準として、実際に自然言語で現れるキャラクターの組み合わせの可能性を使用することがあります。ただし、上記で説明したように、DNS名はしばしば製造であり、略語、意図的に珍しいように形成された文字列、数字や他のキャラクターでシーケンスされたシリーズのメンバーなどです。したがって、適切に構成された実行されたテキストでは、変更を安全であると考える基準は、DNSの目的では役に立ちません。その基準の下で安全な変更は、DNSにとって依然として非常に問題がある可能性があります。
This sensitivity to changes has made it quite difficult to migrate IDNA from one version of Unicode to the next if any changes are made that are not strictly additive. A change in a code point assignment or definition may be extremely disruptive if a DNS label has been defined using the earlier form and any of its previous components has been moved from one table position or normalization rule to another. Unicode normalization tables, tables of scripts or languages and characters that belong to them, and even tables of confusable characters as an adjunct to security recommendations may be very helpful in designing registry restrictions on registrations and applications provisions for avoiding or identifying suspicious names. Ironically, they also extend the sensitivity of IDNA and its implementations to all forms of change between one version of Unicode and the next. Consequently, they make Unicode version migration more difficult.
この変化に対するこの感度により、厳密に加算的でない変更が行われた場合、IDNAをユニコードのあるバージョンから次のバージョンに移行することが非常に困難になりました。コードポイントの割り当てまたは定義の変更は、以前のフォームを使用してDNSラベルが定義されており、以前のコンポーネントのいずれかがあるテーブル位置または正規化ルールに別のコンポーネントに移動された場合、非常に破壊的な場合があります。ユニコードの正規化テーブル、スクリプトまたは言語の表、文字の表、およびセキュリティの推奨事項の補助として混乱する文字の表でさえ、疑わしい名前を啓示または識別するための登録および申請規定のレジストリ制限を設計するのに非常に役立つかもしれません。皮肉なことに、彼らはまた、IDNAの感度とその実装を、あるバージョンのUnicodeと次のバージョンの間のあらゆる形態の変化に拡張します。その結果、Unicodeバージョンの移行がより困難になります。
An example of the type of change that appears to be just a small correction from one perspective but may be problematic from another was the correction to the normalization definition in 2004 [Unicode-PR29]. Community input suggested that the change would cause problems for Stringprep, but the Unicode Technical Committee decided, on balance, that the change was worthwhile. Because of difficulties with consistency, some deployed implementations have decided to adopt the change and others have not, leading to subtle incompatibilities.
ある観点からのわずかな補正であると思われるが、別の観点から問題があるかもしれない変化のタイプの例は、2004年の正規化定義への修正でした[Unicode-PR29]。コミュニティの入力は、この変更がStringPrepの問題を引き起こすことを示唆しましたが、Unicode技術委員会は、変更には価値があると判断しました。一貫性の難しさのため、展開された実装の一部が変更を採用することを決定し、他の展開されていないため、微妙な非互換性につながります。
This situation leads to a dilemma. On the one hand, it is completely unacceptable to freeze IDNA at a Unicode version level that excludes more recently-defined characters and scripts that are important to those who use them. On the other hand, it is equally unacceptable to migrate from one version of Unicode to the next if such migration might invalidate an existing registered DNS name or some of its registered properties or might make the string or representation of that name ambiguous. If IDNA is to be modified to accommodate new versions of Unicode, the IETF will need to work with the Unicode Consortium and other bodies to find an appropriate balance in this area, but progress will be possible only if all relevant parties are able to fairly consider and discuss possible decisions that may be very difficult and unpalatable.
この状況はジレンマにつながります。一方では、UnicodeバージョンレベルでIDNAをフリーズすることは完全に受け入れられません。これは、最近定義された文字を使用している人にとって重要な文字とスクリプトを除外します。一方、そのような移行が既存の登録DNS名またはその登録プロパティの一部を無効にするか、その名前の文字列または表現を曖昧にする可能性がある場合、1つのバージョンのUnicodeから次のバージョンに移行することも同様に受け入れられません。Unicodeの新しいバージョンに対応するためにIDNAを変更する場合、IETFはUnicodeコンソーシアムおよびその他の団体と連携してこのエリアで適切なバランスを見つける必要がありますが、すべての関連当事者が公正に検討できる場合にのみ進捗状況が可能になります。そして、非常に困難で不快な可能性のある可能性のある決定について話し合います。
It would also prove useful if, during the course of that dialog, the need for Unicode Consortium concern with security issues in applications of the Unicode character set could be clarified. It would be unfortunate from almost every perspective considered here, if such matters slowed the inclusion of as yet unencoded scripts.
また、そのダイアログの過程で、Unicode文字セットのアプリケーションにおけるセキュリティ問題に関するUnicode Consortiumの懸念の必要性が明確になる可能性がある場合にも役立ちます。このような問題がまだまだ不可能なスクリプトの包含を遅くした場合、ここで考慮されるほぼすべての視点からは残念です。
One of the advantages of the Unicode model of combining characters, as with previous systems that use character overstriking to accomplish similar purposes, is that it is possible to use sequences of code points to generate characters that are not explicitly provided for in the character set. However, unless sequences that are not explicitly provided for are prohibited by some mechanism (such as the normalization tables), such combining sequences can permit two related dangers.
文字を組み合わせる以前のシステムと同様の目的を達成する以前のシステムと同様に、キャラクターを組み合わせたユニコードモデルの利点の1つは、コードポイントのシーケンスを使用して、文字セットで明示的に提供されていない文字を生成することができることです。ただし、明示的に提供されていないシーケンスが、いくつかのメカニズム（正規化テーブルなど）によって禁止されていない限り、そのような結合シーケンスは2つの関連する危険を可能にする可能性があります。
o The first is another risk of character confusion, especially if the relationship of the combining character with characters it combines with are not precisely defined or unexpected combinations of combining characters are used. That issue is discussed in more detail, with an example, in Section 2.2.3.
o 1つ目は、特に組み合わせキャラクターと組み合わされたキャラクターの関係が正確に定義されていないか、キャラクターを組み合わせた組み合わせの組み合わせが使用されていない場合、キャラクターの混乱の別のリスクです。その問題については、セクション2.2.3の例で、より詳細に説明します。
o These same issues also inherently impact the stability of the normalization tables. Suppose that, somewhere in the world, there is a character that looks like a Roman-derived lowercase "i", but with three (not one or two) dots above it. And suppose that the users of that character agree to represent it by combining a traditional "i" (U+0069) with a combining diaeresis (U+0308). So far, no problem. But, later, a broader need for this character is discovered and it is coded into Unicode either as a single precomposed character or, more likely under existing rules, by introducing a three-dot-above combining character. In either case, that version of Unicode should include a rule in NFKC that maps the "i"-plus-diaeresis sequence into the new, approved, one. If one does not do so, then there is arguably a normalization that should occur that does not. If one does so, then strings that were valid and normalized (although unanticipated) under the previous versions of Unicode become unnormalized under the new version. That, in turn, would impact IDNA comparisons because, effectively, it would introduce a change in the matching rules.
o これらの同じ問題は、正規化表の安定性にも本質的に影響します。世界のどこかに、ローマ由来の小文字の「I」のように見えるキャラクターがあると仮定しますが、その上には3つ（1つか2つではない）ドットがあります。そして、そのキャラクターのユーザーが、伝統的な「私」（U 0069）と組み合わせの拡張（U 0308）を組み合わせることにより、それを表現することに同意すると仮定します。これまでのところ、問題ありません。しかし、後で、このキャラクターのより広範なニーズが発見され、単一の偏位型の文字として、または既存のルールの下で、3ドットを組み合わせたキャラクターを導入することにより、既存のルールの下でより可能性が高いものとしてコード化されます。どちらの場合でも、Unicodeのそのバージョンには、「i」 - 拡張型のシーケンスを新しい、承認された、1つにマッピングするルールをNFKCに含める必要があります。そうしない場合、おそらく発生するはずの正規化があります。そうする場合は、以前のバージョンのUnicodeの下で有効で正規化された文字列（予期せぬ）の文字列は、新しいバージョンの下で非正規化されます。それは、それが効果的に一致するルールの変更をもたらすため、IDNAの比較に影響を与えるでしょう。
It would be useful to consider rules that would avoid or minimize these problems with the understanding that, for reasons given elsewhere, simply minimizing it may not be good enough for IDNA. One partial solution might be to ban any combination of a base character and a combining character that does not appear in a hypothetical "anticipated combinations" table from being used in a domain name label. The next subsection discusses a more radical, if impractical, view of the problem and its solutions.
他の場所で与えられた理由のために、単にそれを最小化するだけではIDNAにとって十分ではないかもしれないという理解で、これらの問題を回避または最小化するルールを検討することは有用です。部分的な解決策の1つは、ベース文字と、仮説的な「予想される組み合わせ」テーブルに表示されない組み合わせ文字の組み合わせをドメイン名ラベルで使用することから禁止することです。次のサブセクションでは、問題とその解決策のより根本的な、非現実的であるとしても、より根本的な見方について説明します。
For several reasons, including those discussed above, one thing that increases IDNA complexity and the need for normalization is that combining characters are permitted. Without them, complexity might be reduced enough to permit easier transitions to new versions. The community should consider the impact of entirely prohibiting combining characters from IDNs. While it is almost certainly unfeasible to introduce this change into Unicode as it is now defined and doing so would be extremely disruptive even if it were feasible, the thought experiment can be helpful in understanding both the issues and the implications of the paths not taken. For example, one consequence of this, of course, is that each new language or script, and several existing ones, would require that all of its characters have Unicode assignments to specific, precomposed, code points.
上記のものを含むいくつかの理由で、IDNAの複雑さを高め、正規化の必要性が増加することの1つは、文字を組み合わせて許可されていることです。それらがなければ、新しいバージョンへの移行を容易にするために、複雑さが十分に低下する可能性があります。コミュニティは、IDNSのキャラクターを完全に禁止することの影響を考慮する必要があります。この変更をUnicodeに導入することはほぼ確実ですが、現在は定義されているため、実行可能であっても非常に破壊的ですが、思考実験は、問題と実行されていないパスの意味の両方を理解するのに役立ちます。たとえば、これの結果の1つは、もちろん、新しい言語またはスクリプト、およびいくつかの既存の言語、およびそのすべての文字が、特定の不定期のコードポイントに対するユニコード割り当てを持つことを要求することです。
Note that this is not currently permitted within Unicode for Latin scripts. For non-Latin scripts, some such code points have been defined. The decisions that govern the assignment of such code points are managed entirely within the Unicode Consortium. Were the IETF to choose to reduce IDNA complexity by excluding combining characters, no doubt there would be additional input to the Unicode Consortium from users and proponents of scripts that precomposed characters be required. The IAB and the IETF should examine whether it is appropriate to press the Unicode Consortium to revise these policies or otherwise to recommend actions that would reduce the need for normalization and the related complexities. However, we have been told that the Technical Committee does not believe it is reasonable or feasible to add all possible precomposed characters to Unicode. If Unicode cannot be modified to contain the precomposed characters necessary to support existing languages and scripts, much less new ones, this option for IDN restrictions will not be feasible.
これは現在、ラテンスクリプトのUnicode内で許可されていないことに注意してください。非ラチンスクリプトの場合、そのようなコードポイントの一部が定義されています。このようなコードポイントの割り当てを支配する決定は、Unicodeコンソーシアム内で完全に管理されます。文字を組み合わせることでIDNAの複雑さを減らすことを選択するIETFは、ユーザーからUnicodeコンソーシアムに追加の入力が必要であることは間違いありません。IABとIETFは、Unicodeコンソーシアムを押してこれらのポリシーを修正するか、その他の方法で正規化と関連する複雑さを減らすアクションを推奨することが適切かを調べる必要があります。ただし、技術委員会は、可能なすべての不定期の文字をUnicodeに追加することが合理的または実行可能であるとは考えていないと言われています。Unicodeを変更して、既存の言語とスクリプトをサポートするために必要な具体的な文字を含めるように変更できない場合、IDN制限のこのオプションは実行不可能です。
In many Unicode applications, the preferred solution is to pick a style of normalization and require that all text that is stored or transmitted be normalized to that form. (This is the approach taken in ongoing work in the IETF on a standard Unicode text form [net-utf8]). IDNA does not impose this requirement. Text is normalized and case-reduced at registration time, and only the normalized version is placed in the DNS. However, there is no requirement that applications show only the native (and lower-case where appropriate) characters associated with the normalized form in discussions or references such as URLs. If conventions used for all-ASCII DNS labels are to be extended to internationalized forms, such a requirement would be unreasonable, since it would prohibit the use of mixed-case references for clarity or market identification. It might even be culturally inappropriate. However, without that restriction, the comparison that will ultimately be made in the DNS will be between strings normalized at different times and under different versions of Unicode. The assertion that a string in normalized form under one version of Unicode will still be in normalized form under all future versions is not sufficient. Normalization at different times also requires that a given source string always normalizes to the same target string, regardless of the version under which it is normalized. That criterion is much more difficult to fulfill. The discussion above suggests that it may even be impossible.
多くのユニコードアプリケーションでは、優先ソリューションは正規化のスタイルを選択し、保存または送信されるすべてのテキストをそのフォームに正規化することを要求することです。（これは、標準のユニコードテキストフォーム[Net-UTF8]のIETFで進行中の作業で採用されたアプローチです）。IDNAはこの要件を課しません。テキストは登録時に正規化され、ケース削減され、DNSに正規化されたバージョンのみが配置されます。ただし、アプリケーションは、URLなどのディスカッションまたは参照で正規化されたフォームに関連付けられたネイティブ（および必要に応じて）文字のみを表示するという要件はありません。ALL-ASCII DNSラベルに使用される慣習が国際化されたフォームに拡張される場合、そのような要件は、明確性または市場識別のための混合ケース参照の使用を禁止するため、不合理になります。それは文化的に不適切かもしれません。ただし、その制限がなければ、最終的にDNSで行われる比較は、異なる時間と異なるバージョンの異なるバージョンで正規化された文字列の間に行われます。Unicodeの1つのバージョンの下に正規化された形式の文字列は、すべての将来のバージョンの下でまだ正規化された形式であるという主張では十分ではありません。また、異なる時間に正規化するには、特定のソース文字列が正規化されているバージョンに関係なく、常に同じターゲット文字列に正規化する必要があります。その基準は、達成するのがはるかに困難です。上記の議論は、それが不可能でさえあるかもしれないことを示唆しています。
Ignoring these issues with combining characters entirely, as IDNA effectively does today, may leave us "stuck" at Unicode 3.2, leading either to incompatibility differences in applications that otherwise use a modern version of Unicode (while IDN remains at Unicode 3.2) or to painful transitions to new versions. If decisions are made quickly, it may still be possible to make a one-time version upgrade to Version 4.1 or Version 5 of Unicode. However, unless we can impose sufficient global restrictions to permit smooth transitions, upgrading to versions beyond that one are likely to be painful (e.g., potentially requiring changing strings already in the DNS or even a new Punycode prefix) or impossible.
IDNAが今日効果的に行っているように、キャラクターを完全に組み合わせることでこれらの問題を無視すると、Unicode 3.2で「立ち往生」する可能性があり、それ以外の場合はUnicodeの最新バージョンを使用するアプリケーションの非互換性の違い（IDNがUnicode 3.2に残る）または痛みを伴う可能性があります。新しいバージョンへの移行。決定が迅速に行われた場合でも、Unicodeのバージョン4.1またはバージョン5に1回限りのバージョンをアップグレードすることができる場合があります。ただし、スムーズな移行を可能にするのに十分なグローバルな制限を課すことができない限り、それを超えたバージョンにアップグレードすることは痛みを伴う可能性が高い（たとえば、DNSまたは新しいPunycodeのプレフィックスで既に変更を変更する必要がある可能性が高い）または不可能。
The IETF should consider reviewing RFCs 3454, 3490, 3491, and/or 3492, and update, replace, or supplement them to meet the criteria of this paragraph (one or more of them may prove impractical after further study). Any new versions or additional specifications should be adapted to the version of Unicode that is current when they are created. Ideally, they should specify a path for adapting to future versions of Unicode (some suggestions below may facilitate this). The IETF should also consider whether there are significant advantages to mapping some groups of characters, such as code points assigned to font variations, into others or whether clarity and comprehensibility for the user would be better served by simply prohibiting those characters. More generally, it appears that it would be worthwhile for the IETF to review whether the Unicode normalization rules now invoked by the Stringprep profile in Nameprep are optimal for the DNS or whether more restrictive rules, or an even more restrictive set of permitted character combinations, would provide better support for DNS internationalization.
IETFは、RFCS 3454、3490、3491、および/または3492のレビューを検討し、この段落の基準を満たすためにそれらを更新、更新、補足する必要があります（それらの1つ以上がさらなる研究の後に非実用的であることが証明される場合があります）。新しいバージョンまたは追加の仕様は、作成時に最新のUnicodeのバージョンに適合する必要があります。理想的には、Unicodeの将来のバージョンに適応するためのパスを指定する必要があります（以下の提案はこれを容易にする可能性があります）。IETFは、フォントのバリエーションに割り当てられたコードポイントなど、一部のコードポイント、他のグループにマッピングすることに大きな利点があるかどうか、またはユーザーの明確さと理解可能性が、単にそれらの文字を禁止することでより良いサービスを提供するかどうかを検討する必要があります。より一般的には、IETFがNAMEPREPのStringPrepプロファイルによって現在呼び出されるユニコード正規化ルールがDNSに最適であるか、より制限的なルール、またはさらに制限的な許可された文字の組み合わせセットであるかどうかを確認するのは価値があると思われます。DNSの国際化をより良いサポートを提供します。
The IAB has concluded that there is a consensus within the broader community that lists of code points should be specified by the use of an inclusion-based mechanism (i.e., identifying the characters that are permitted), rather than by excluding a small number of characters from the total Unicode set as Stringprep and Nameprep do today. That conclusion should be reviewed by the IETF community and action taken as appropriate.
IABは、少数の文字を除外するのではなく、インクルージョンベースのメカニズムを使用する（つまり、許可されている文字を識別する）ことにより、コードポイントのリストを指定する必要があるという、より広範なコミュニティ内にコンセンサスがあると結論付けています。StringPrepとNamePrepが今日行っているように、合計Unicodeセットから。その結論は、IETFコミュニティと、必要に応じて取られたアクションによってレビューされるべきです。
We suggest that the individuals doing the review of the code points should work as a specialized design team. To the extent possible, that work should be done jointly by people with experience from the IETF and deep knowledge of the constraints of the DNS and application design, participants from the Unicode Consortium, and other people necessary to be able to reach a generally-accepted result. Because any work along these lines would be modifications and updates to standards-track documents, final review and approval of any proposals would necessarily follow normal IETF processes.
コードポイントのレビューを行う個人は、専門の設計チームとして機能することをお勧めします。可能な限り、その作業は、IETFからの経験とDNSの制約とアプリケーション設計、Unicodeコンソーシアムの参加者、および一般的に受け入れられることに到達するために必要な他の人々が共同で行う必要があります。結果。これらの回線に沿った作業は、標準トラックドキュメントの変更と更新であるため、提案の最終的なレビューと承認は、必然的に通常のIETFプロセスに従います。
It is worth noting that sufficiently extreme changes to IDNA would require a new Punycode prefix, probably with long-term support for both the old prefix and the new one in both registration arrangements and applications. An alternative, which is almost certainly impractical, would be some sort of "flag day", i.e., a date on which the old rules are simultaneously abandoned by everyone and the new ones adopted. However, preliminary analysis indicates that few, if any, of the changes recommended for consideration elsewhere in this document would require this type of version change. For example, suppose additional restrictions, such as those implied above, are imposed on what can be registered. Those restrictions might require policy decisions about how labels are to be disposed of if they conformed to the earlier rules but not to the new ones. But they would not inherently require changes in the protocol or prefix.
IDNAへの十分に極端な変更には、おそらく登録の取り決めとアプリケーションの両方で古い接頭辞と新しいものの両方に長期的なサポートがある新しいPunycodeプレフィックスが必要になることは注目に値します。ほぼ間違いなく非現実的な代替案は、ある種の「フラグデー」、つまり、すべての人と新しいルールが採用した古いルールが同時に放棄される日付です。ただし、予備分析では、このドキュメントの他の場所で考慮するために推奨される変更のほとんどが、このタイプのバージョンの変更が必要になることを示しています。たとえば、上記の暗示されているような追加の制限が登録できるものに課されると仮定します。これらの制限は、ラベルが以前のルールに準拠していたが、新しい規則に適合した場合に、ラベルがどのように処分されるかについての政策決定を必要とする場合があります。しかし、それらは本質的にプロトコルまたはプレフィックスの変更を必要としません。
The IETF should once again examine the extent to which it is appropriate to try to solve internationalization problems via the DNS and what place the many varieties of so-called "keyword systems" or other Internet navigational techniques might have. Those techniques can be designed to impose fewer constraints, or at least different constraints, than IDNA and the DNS. As discussed elsewhere in this document, IDNA cannot support information about scripts, languages, or Unicode versions on lookup. As a consequence of the nature of DNS lookups, characters and labels either match or do not match; a near-match is simply not a possible concept in the DNS. By contrast, observation of near-matching is common in human communication and in matching operations performed by people, especially when they have a particular script or language context in mind. The DNS is further constrained by a fairly rigid internal aliasing system (via CNAME and DNAME resource records), while some applications of international naming may require more flexibility. Finally, the rigid hierarchy of the DNS --and the tendency in practice for it to become flat at levels nearest the root-- and the need for names to be unique are more suitable for some purposes than others and may not be a good match for some purposes for which people wish to use IDNs. Each of these constraints can be relaxed or changed by one or more systems that would provide alternatives to direct use of the DNS by users. Some of the issues involved are discussed further in Section 5.3 and various ideas have been discussed in detail in the IETF or IRTF. Many of those ideas have even been described in Internet Drafts or other documents. As experience with IDNs and with expectations for them accumulates, it will probably become appropriate for the IETF or IRTF to revisit the underlying questions and possibilities.
4.1.3. Security Issues, Certificates, etc.
4.1.3. セキュリティの問題、証明書など
Some characters look like others, often as the result of common origins. The problem with these "confusable" characters, often incorrectly called homographs, has always existed when characters are presented to humans who interpret what is displayed and then make decisions based on what is seen. This is not a problem that exists only when working with internationalized domain names, but they make the problem worse. The result of a survey that would explain what the problems are might be interesting. Many of these issues are mentioned in Unicode Technical Report #36 [UTR36].
一部のキャラクターは、一般的な起源の結果として、しばしば他のキャラクターのように見えます。しばしば誤ってホモグラフと呼ばれるこれらの「混乱しやすい」キャラクターの問題は、表示されているものを解釈し、見られるものに基づいて決定を下す人間にキャラクターが提示されたときに常に存在していました。これは、国際化されたドメイン名を操作するときにのみ存在する問題ではありませんが、問題を悪化させます。問題が何であるかを説明する調査の結果は興味深いかもしれません。これらの問題の多くは、Unicodeテクニカルレポート＃36 [UTR36]で言及されています。
In this and other issues associated with IDNs, precise use of terminology is important lest even more confusion result. The definition of the term 'homograph' that normally appears in dictionaries and linguistic texts states that homographs are different words that are spelled identically (for example, the adjective 'brief' meaning short, the noun 'brief' meaning a document, and the verb 'brief' meaning to inform). By definition, letters in two different alphabets are not the same, regardless of similarities in appearance. This means that sequences of letters from two different scripts that appear to be identical on a computer display cannot be homographs in the accepted sense, even if they are both words in the dictionary of some language. Assuming that there is a language written with Cyrillic script in which "cap" is a word, regardless of what it might mean, it is not a homograph of the Latin-script English word "cap".
IDNSに関連するこの問題およびその他の問題では、用語の正確な使用がさらに多くの混乱の結果をもたらさないことが重要です。通常、辞書や言語テキストに表示される「ホモグラフ」という用語の定義は、ホモグラフは同一に綴られている異なる単語であると述べています（たとえば、形容詞の「短い」意味が短く、「名詞」を意味するドキュメントを意味し、動詞情報を提供する「簡単な」意味）。定義上、2つの異なるアルファベットの文字は、外観の類似点に関係なく同じではありません。これは、コンピューターディスプレイで同一であると思われる2つの異なるスクリプトからの一連の文字が、たとえそれらがどちらもある言語の辞書の単語であっても、受け入れられた意味でのホモグラフではないことを意味します。「キャップ」が言葉であるキリル文字で書かれた言語があると仮定すると、それが何を意味するのかに関係なく、それはラテンスクリプトの英語の単語「キャップ」のホモグラフではありません。
When the security implications of visually confusable characters were brought to the forefront in 2005, the term homograph was used to designate any instance of graphic similarity, even when comparing individual characters. This usage is not only incorrect, but risks introducing even more confusion and hence should be avoided. The current preferred terminology is to describe these similar-looking characters as "confusable characters" or even "confusables".
2005年に視覚的に混乱しやすいキャラクターのセキュリティへの影響が最前線に持ち込まれたとき、ホモグラフという用語は、個々の文字を比較する場合でも、グラフィックの類似性のインスタンスを指定するために使用されました。この使用法は間違っているだけでなく、さらに多くの混乱をもたらすリスクがあるため、避けるべきです。現在の好ましい用語は、これらの似たように見えるキャラクターを「混乱しやすいキャラクター」または「混乱したもの」として説明することです。
Many people have suggested that confusable characters are a problem that must be addressed, at least in part, directly in the user interfaces of application software. While it should almost certainly be part of a complete solution, that approach creates it own set of difficulties. For example, a user switching between systems, or even between applications on the same system, may be surprised by different types of behavior and different levels of protection. In addition, it is unclear how a secure setup for the end user should be designed. Today, in the web browser, a padlock is a traditional way of describing some level of security for the end user. Is this binary signaling enough? Should there be any connection between a risk for a displayed string including confusable characters and the padlock or similar signaling to the user?
多くの人々は、紛らわしいキャラクターは、少なくとも部分的には、アプリケーションソフトウェアのユーザーインターフェイスで直接対処する必要がある問題であると示唆しています。ほぼ間違いなく完全なソリューションの一部であるはずですが、そのアプローチはそれ自体の困難セットを作成します。たとえば、システム間を切り替えるユーザー、または同じシステム上のアプリケーション間でさえ、さまざまな種類の動作とさまざまなレベルの保護に驚く場合があります。さらに、エンドユーザーの安全なセットアップをどのように設計するかは不明です。今日、Webブラウザでは、南京錠はエンドユーザーのある程度のセキュリティを説明する従来の方法です。このバイナリシグナルは十分ですか？混乱しやすい文字を含む表示された文字列のリスクと、ユーザーへのパドロックまたは同様の信号の間には、何らかの接続が必要ですか？
Many web browsers have adopted a convention, based on a "whitelist" or similar technique, of restricting the display of native characters to subdomains of top-level domains that are deemed to have safe practices for the registration of potentially confusable labels. IDNs in other domains are displayed as Punycode. These techniques may not be sufficiently sensitive to differences in policies among top-level domains and their subdomains and so, while they are clearly helpful, they may not be adequate. Are other methods of dealing with confusable characters possible? Would other methods of identifying and listing policies about avoiding confusing registrations be feasible and helpful?
多くのWebブラウザは、「ホワイトリスト」または同様の手法に基づいて、潜在的に混乱しやすいラベルの登録のための安全な慣行があるとみなされるトップレベルドメインのサブドメインにネイティブ文字の表示を制限するコンベンションを採用しています。他のドメインのIDNSは、プニコードとして表示されます。これらの手法は、トップレベルのドメインとそのサブドメイン間のポリシーの違いに十分に敏感ではない可能性があるため、明らかに役立つが、適切ではないかもしれません。紛らわしいキャラクターを扱う他の方法は可能ですか？登録を避けることに関するポリシーを特定してリストする他の方法は、実行可能かつ役立つでしょうか？
It would be interesting to see a more coordinated effort in establishing guidelines for user interfaces. If nothing else, the current whitelists are browser specific and both can, and do, differ between implementations.
ユーザーインターフェイスのガイドラインを確立するために、より調整された取り組みを見るのは興味深いでしょう。他に何もなければ、現在のホワイトリストはブラウザ固有であり、両方とも実装間で異なります。
Some potential protocol or table changes raise important policy issues about what to do with existing, registered, names. Should such changes be needed, their impact must be carefully evaluated in the IETF, ICANN, and possibly other forums. In particular, protocol or policy changes that would not permit existing names to be registered under the newer rules should be considered carefully, balancing their importance against possible disruption and the issues of invalidating older names against the importance of consistency as seen by the user.
一部の潜在的なプロトコルまたはテーブルの変更は、既存の登録済みの名前をどうするかについて重要なポリシーの問題を提起します。そのような変更が必要な場合、それらの影響は、IETF、ICANN、および場合によっては他のフォーラムで慎重に評価する必要があります。特に、既存の名前を新しいルールに基づいて登録することを許可しないプロトコルまたはポリシーの変更は、ユーザーが見た一貫性の重要性に対して古い名前を無効にする問題とのバランスをとることで、慎重に検討する必要があります。
Work is going on in the IETF related to the local part of email addresses. It should be noted that the local part of email addresses has much different syntax and constraints than a domain name label, so to directly apply IDNA on the local part is not possible.
Unicode and the closely-related ISO 10646 are the only coded character sets that aspire to include all of the world's characters. As such, they permit use of international characters without having to identify particular character coding standards or tables. The requirement for a single character set is particularly important for use with the DNS since there is no place to put character set identification. The decision to use Unicode as the base for IETF protocols going forward is discussed in [RFC2277]. The IAB does not see any reason to revisit the decision to use Unicode in IETF protocols.
Unicodeと密接に関連するISO 10646は、世界のすべてのキャラクターを含めることを目指している唯一のコード化された文字セットです。そのため、特定の文字コーディング標準や表を特定することなく、国際的なキャラクターの使用を許可しています。単一の文字セットの要件は、文字セットの識別を入力する場所がないため、DNSでの使用に特に重要です。UnicodeをIETFプロトコルの前進のベースとして使用する決定は、[RFC2277]で説明されています。IABは、IETFプロトコルでUnicodeを使用する決定を再訪する理由を見ていません。
IDNs create new types of collisions between trademarks and domain names as well as collisions between domain names. These have impact on dispute resolution processes used by registries and otherwise. It is important that deployment of IDNs evolve in parallel with review and updating of ICANN or registry-specific dispute resolution processes.
IDNSは、商標とドメイン名の間に新しいタイプの衝突を作成し、ドメイン名間の衝突を作成します。これらは、レジストリなどで使用される紛争解決プロセスに影響を与えます。IDNSの展開は、ICANNまたはレジストリ固有の紛争解決プロセスのレビューと更新と並行して進化することが重要です。
The IAB recommends that registries use an inclusion-based model when choosing what characters to allow at the time of registration. This list of characters is in turn to be a subset of what is allowed according to the updated IDNA standard. The IAB further recommends that registries develop their inclusion-based models in parallel with dispute resolution process at the registry itself.
IABは、登録時に許可する文字を選択する際に、レジストリがインクルージョンベースのモデルを使用することを推奨します。この文字のリストは、更新されたIDNA標準に従って許可されているもののサブセットになります。IABはさらに、レジストリ自体での紛争解決プロセスと並行して、レジストリがインクルージョンベースのモデルを開発することを推奨しています。
Most established policies for dealing with claimed or apparent confusion or conflicts of names are based on dispute resolution. Decisions about legitimate use or registration of one or more names are resolved at or after the time of registration on a case-by-case basis and using policies that are specific to the particular DNS zone or jurisdiction involved. These policies have generally not been extended below the level of the DNS that is directly controlled by the top-level registry.
主張されたまたは明らかな混乱または名前の対立に対処するためのほとんどの確立されたポリシーは、紛争解決に基づいています。正当な使用または1つまたは複数の名前の登録に関する決定は、ケースバイケースで登録時に登録時に解決され、特定のDNSゾーンまたは関与する管轄権に固有のポリシーを使用します。これらのポリシーは、一般に、トップレベルのレジストリによって直接制御されるDNSのレベルよりも拡張されていません。
Because of the number of conflicts that can be generated by the larger number of available and confusable characters in Unicode, we recommend that registration-restriction and dispute resolution policies be developed to constrain registration of IDNs and zone administrators at all levels of the DNS tree. Of course, many of these policies will be less formal than others and there is no requirement for complete global consistency, but the arguments for reduction of confusable characters and other issues in TLDs should apply to all zones below that specific TLD.
Unicodeで利用可能で混乱しやすい文字の数が多いことで生成できる競合の数が多いため、DNSツリーのすべてのレベルでのIDNとゾーン管理者の登録を制約するために、登録制限と紛争解決ポリシーを開発することをお勧めします。もちろん、これらのポリシーの多くは他のポリシーよりも形式的ではなく、完全なグローバルな一貫性の要件はありませんが、TLDの混乱しやすいキャラクターやその他の問題の削減に関する議論は、その特定のTLDの下のすべてのゾーンに適用する必要があります。
Consistency across all zones can obviously only be accomplished by changes to the protocols. Such changes should be considered by the IETF if particular restrictions are identified that are important and consistent enough to be applied globally.
すべてのゾーンにわたる一貫性は、明らかにプロトコルの変更によってのみ達成できます。このような変更は、グローバルに適用するのに十分であり、一貫性がある特定の制限が特定されている場合は、IETFによって考慮される必要があります。
Some potential protocol changes or changes to character-mapping tables might, if adopted, have profound registry policy implications. See Section 4.1.4.
いくつかの潜在的なプロトコルの変更またはキャラクターマッピングテーブルの変更は、採用された場合、登録ポリシーの深い意味を持つ可能性があります。セクション4.1.4を参照してください。
The IAB has concluded that there is not one issue with IDNs at the top level of the DNS (IDN TLDs) but at least three very separate ones:
IABは、DNS（IDN TLD）の最上位レベルにIDNSに1つの問題がないと結論付けていますが、少なくとも3つの非常に別々の問題があります。
o If IDNs are to be entered in the root zone, decisions must first be made about how these TLDs are to be named and delegated. These decisions fall within the traditional IANA scope and are ICANN issues today.
o IDNがルートゾーンに入力される場合、まずこれらのTLDの名前と委任される方法について決定する必要があります。これらの決定は、従来のIANA範囲内にあり、今日のICANNの問題です。
o There has been discussion of permitting some or all existing TLDs to be referenced by multiple labels, with those labels presumably representing some understanding of the "name" of the TLD in different languages. If actual aliases of this type are desired for existing domains, the IETF may need to consider whether the use of DNAME records in the root is appropriate to meet that need, what constraints, if any, are needed, whether alternate approaches, such as those of [RFC4185], are appropriate or whether further alternatives should be investigated. But, to the extent to which aliases are considered desirable and feasible, decisions presumably must be made as to which, if any, root IDN labels should be associated with DNAME records and which ones should be handled by normal delegation records or other mechanisms. That decision is one of DNS root-level namespace policy and hence falls to ICANN although we would expect ICANN to pay careful attention to any technical, operational, or security recommendations that may be produced by other bodies.
o 一部またはすべての既存のTLDが複数のラベルで参照されることを許可することについての議論がありました。これらのラベルは、おそらく異なる言語でのTLDの「名前」のある程度の理解を表しています。このタイプの実際のエイリアスが既存のドメインに対して望ましい場合、IETFは、ルート内のDNAMEレコードの使用がそのニーズを満たすのに適しているかどうかを検討する必要があります。[rfc4185]の場合、またはさらなる代替を調査する必要があるかどうか。しかし、エイリアスが望ましいと実現可能と見なされる範囲では、おそらく、ルートIDNラベルがDNAMEレコードに関連付けられている必要がある場合、そして通常の委任記録またはその他のメカニズムによって処理されるべきかについて、おそらく決定を下す必要があります。その決定は、DNSルートレベルの名前空間ポリシーの1つであるため、ICANNは他の団体によって生成される可能性のある技術的、運用的、またはセキュリティの推奨事項に注意を払うことを期待していますが、ICANNに該当します。
o Finally, if IDN labels are to be placed in the root zone, there are issues associated with how they are to be encoded and deployed. This area may have implications for work that has been done, or should be done, in the IETF.
o 最後に、IDNラベルをルートゾーンに配置する場合、エンコードおよび展開する方法に関連する問題があります。この領域は、IETFで行われた、または行われるべき仕事に影響を与える可能性があります。
Consistent with the framework described above, the IAB offers these recommendations as steps for further consideration in the identified groups.
上記のフレームワークと一致して、IABは、特定されたグループでさらに検討するための手順としてこれらの推奨事項を提供します。
Generalize from the original "hostname" rules to non-ASCII characters, permitting as few characters as possible to do that job. This would involve a restrictive model for characters permitted in IDN labels, thus contrasting with the approach used to develop the original IDNA/Nameprep tables. That approach was to include all Unicode characters that there was not a clear reason to exclude.
オリジナルの「ホスト名」ルールからASCII以外の文字に一般化し、その仕事をするためにできるだけ少ないキャラクターを許可します。これには、IDNラベルで許可されている文字の制限モデルが含まれ、したがって、元のIDNA/NamePrepテーブルの開発に使用されるアプローチとは対照的です。そのアプローチは、除外する明確な理由がなかったすべてのユニコード文字を含めることでした。
The specific recommendation here is to specify such internationalized hostnames. Such an activity would fall to the IETF, although the task of developing the appropriate list of permitted characters will require effort both in the IETF and elsewhere. The effort should be as linguistically and culturally sensitive as possible, but smooth and effective operation of the DNS, including minimizing of complexity, should be primary goals. The following should be considered as possible mechanisms for achieving an appropriate minimum number of characters.
ここでの具体的な推奨事項は、このような国際化されたホスト名を指定することです。このようなアクティビティはIETFに落ちますが、許可されたキャラクターの適切なリストを開発するタスクには、IETFと他の場所の両方で努力が必要になります。努力は可能な限り言語的および文化的に敏感でなければなりませんが、複雑さを最小限に抑えるなど、DNSのスムーズで効果的な運用が主要な目標であるべきです。適切な最低数の文字を達成するための可能なメカニズムとして以下を考慮する必要があります。
Unicode characters that are not needed to write words or numbers in any of the world's languages should be eliminated from the list of characters that are appropriate in DNS labels. In addition to such characters as those used for box-drawing and sentence punctuation, this should exclude punctuation for word structure and other delimiters. While DNS labels may conveniently be used to express words in many circumstances, the goal is not to express words (or sentences or phrases), but to permit the creation of unambiguous labels with good mnemonic value.
世界の言語のいずれかで単語や数字を書くために必要ではないユニコード文字は、DNSラベルで適切な文字のリストから排除する必要があります。箱の描画や文の句読点に使用されるようなキャラクターに加えて、これは単語構造やその他の区切り文字の句読点を除外する必要があります。DNSラベルは多くの状況で単語を表現するために便利に使用される場合がありますが、目標は単語（または文章やフレーズ）を表現することではなく、ニーモニック価値のある明確なラベルの作成を許可することです。
The inclusion of the hyphen in the original hostname rules is a historical artifact from an older, flat, namespace. The community should consider whether it is appropriate to treat it as a simple legacy property of ASCII names and not attempt to generalize it to other scripts. We might, for example, not permit claimed equivalents to the hyphen from other scripts to be used in IDNs. We might even consider banning use of the hyphen itself in non-ASCII strings or, less restrictively, strings that contained non-Latin characters.
元のホスト名ルールにハイフンを含めることは、古いフラットの名前空間からの歴史的なアーティファクトです。コミュニティは、ASCII名の単純なレガシープロパティとして扱うことが適切かどうかを検討し、他のスクリプトに一般化しようとしないかどうかを検討する必要があります。たとえば、IDNSで使用する他のスクリプトからハイフンに相当すると主張することは許可されていない場合があります。ハイフン自体の使用を非ASCII弦での使用、または非ラチン文字を含む文字列ではない文字列を禁止することさえ検討するかもしれません。
As new scripts, to support new languages, continue to be added to Unicode, it is important that IDNA track updates. If it does not do so, but remains "stuck" at 3.2 or some single later version, it will not be possible to include labels in the DNS that are derived from words in languages that require characters that are available only in later versions. Making those upgrades is difficult, and will continue to be difficult, as long as new versions require, not just addition of characters, but changes to canonicalization conventions, normalization tables, or matching procedures (see Section 3.1). Anything that can be done to lower complexity and simplify forward transitions should be seriously considered.
新しい言語をサポートする新しいスクリプトとして、Unicodeに追加され続けるため、IDNAが更新を追跡することが重要です。そうしないが、3.2またはいくつかのシングルバージョンで「スタック」のままである場合、後のバージョンでのみ利用可能な文字を必要とする言語の単語から派生したDNSにラベルを含めることはできません。これらのアップグレードを作成することは困難であり、キャラクターの追加だけでなく、標準化規則、正規化表、または一致手順の変更が必要な限り、引き続き困難になります（セクション3.1を参照）。複雑さを低下させ、前方の移行を簡素化するためにできることはすべて、真剣に検討する必要があります。
We wish to remind the community that there are boundaries to the appropriate uses of the DNS. It was designed and implemented to serve some specific purposes. There are additional things that it does well, other things that it does badly, and still other things it cannot do at all. No amount of protocol work on IDNs will solve problems with alternate spellings, near-matches, searching for appropriate names, and so on. Registration restrictions and carefully-designed user interfaces can be used to reduce the risk and pain of attempts to do some of these things gone wrong, as well as reducing the risks of various sort of deliberate bad behavior, but, beyond a certain point, use of the DNS simply because it is available becomes a bad tradeoff. The tradeoff may be particularly unfortunate when the use of IDNs does not actually solve the proposed problem. For example, internationalization of DNS names does not eliminate the ASCII protocol identifiers and structure of URIs [RFC3986] and even IRIs [RFC3987]. Hence, DNS internationalization itself, at any or all levels of the DNS tree, is not a sufficient response to the desire of populations to use the Internet entirely in their own languages and the characters associated with those languages.
DNSの適切な用途には境界があることをコミュニティに思い出させたいと思います。特定の目的を果たすために設計および実装されました。それがうまくいく追加のこと、それがひどく行うこと、そしてそれがまったくできない他のことがあります。IDNSでのプロトコル作業の量は、代替スペル、ニアマッチ、適切な名前の検索などで問題を解決しません。登録制限と慎重に設計されたユーザーインターフェイスを使用して、これらのことのいくつかを間違えようとする試みのリスクと痛みを軽減することができ、さまざまな種類の意図的な悪い行動のリスクを減らすことができますが、特定のポイントを超えて、使用することができます。DNSが利用可能であるという理由だけで、悪いトレードオフになります。IDNSの使用が実際に提案された問題を解決しない場合、トレードオフは特に不幸な場合があります。たとえば、DNS名の国際化では、URIS [RFC3986]および虹彩の構造[RFC3987]のASCIIプロトコル識別子と構造を排除しません。したがって、DNSツリーのいずれかまたはすべてまたはすべてのレベルでのDNS国際化自体は、インターネットを独自の言語とそれらの言語に関連付けられたキャラクターで完全に使用したいという集団の欲求に対する十分な反応ではありません。
These issues are discussed at more length, and alternatives presented, in [RFC2825], [RFC3467], [INDNS], and [DNS-Choices].
これらの問題は、[RFC2825]、[RFC3467]、[INDNS]、および[DNS-Choices]で、より長い長さで説明されており、代替案が提示されています。
In addition to their presence in the DNS, IDNs introduce issues in other contexts in which domain names are used. In particular, the design and content of databases that bind registered names to information about the registrant (commonly described as "whois" databases) will require review and updating. For example, the whois protocol itself [RFC3912] has no standard capability for handling non-ASCII text: one cannot search consistently for, or report, either a DNS name or contact information that is not in ASCII characters. This may provide some additional impetus for a switch to IRIS [RFC3981] [RFC3982] but also raises a number of other questions about what information, and in what languages and scripts, should be included or permitted in such databases.
DNSでの存在に加えて、IDNSはドメイン名が使用される他のコンテキストで問題を導入します。特に、登録名を登録者に関する情報にバインドするデータベースの設計とコンテンツ（一般に「WHOIS」データベースと呼ばれる）には、レビューと更新が必要です。たとえば、WHOISプロトコル自体[RFC3912]には、ASCII以外のテキストを処理するための標準機能はありません。ASCII文字にないDNS名または連絡先情報を一貫して検索または報告することはできません。これにより、IRIS [RFC3981] [RFC3982]への切り替えに追加の推進力が提供される可能性がありますが、そのようなデータベースにどのような情報、およびどの言語とスクリプトを含めるか、許可されるかについて他の多くの質問も提起します。
This document is simply a discussion of IDNs and IDNA issues; it raises no new security concerns. However, if some of its recommendations to reduce IDNA complexity, the number of available characters, and various approaches to constraining the use of confusable characters, are followed and prove successful, the risks of name spoofing and other problems may be reduced.
このドキュメントは、単にIDNSとIDNAの問題に関する議論です。それは新しいセキュリティの懸念を提起しません。ただし、IDNAの複雑さを減らすための推奨事項の一部、利用可能な文字の数、および混乱しやすい文字の使用を制約するためのさまざまなアプローチに従い、成功した場合、名前のスプーフィングやその他の問題のリスクが軽減される場合があります。
The contributions to this report from members of the IAB-IDN ad hoc committee are gratefully acknowledged. Of course, not all of the members of that group endorse every comment and suggestion of this report. In particular, this report does not claim to reflect the views of the Unicode Consortium as a whole or those of particular participants in the work of that Consortium.
IAB-IDNアドホック委員会のメンバーからのこのレポートへの貢献は、感謝されています。もちろん、そのグループのメンバーのすべてが、このレポートのすべてのコメントと提案を支持するわけではありません。特に、この報告書は、ユニコードコンソーシアム全体またはそのコンソーシアムの仕事の特定の参加者の見解を反映していると主張していません。
The members of the ad hoc committee were: Rob Austein, Leslie Daigle, Tina Dam, Mark Davis, Patrik Faltstrom, Scott Hollenbeck, Cary Karp, John Klensin, Gervase Markham, David Meyer, Thomas Narten, Michael Suignard, Sam Weiler, Bert Wijnen, Kurt Zeilenga, and Lixia Zhang.
Thanks are due to Tina Dam and others associated with the ICANN IDN Working Group for contributions of considerable specific text, to Marcos Sanz and Paul Hoffman for careful late-stage reading and extensive comments, and to Pete Resnick for many contributions and comments, both in conjunction with his former IAB service and subsequently. Olaf M. Kolkman took over IAB leadership for this document after Patrik Faltstrom and Pete Resnick stepped down in March 2006.
Members of the IAB at the time of approval of this document were: Bernard Aboba, Loa Andersson, Brian Carpenter, Leslie Daigle, Patrik Faltstrom, Bob Hinden, Kurtis Lindqvist, David Meyer, Pekka Nikander, Eric Rescorla, Pete Resnick, Jonathan Rosenberg and Lixia Zhang.
この文書の承認時のIABのメンバーは、バーナード・アボバ、ロア・アンダーソン、ブライアン・カーペンター、レスリー・デイグル、パトリック・ファートストローム、ボブ・ヒンデン、クルティス・リンドクヴィスト、デビッド・マイヤー、ペッカ・ニカンダー、エリック・レスカルラ、ペテ・レスニック、ジョナサン・ロゼンベルグ、リキシア・チャン。
[ISO10646] International Organization for Standardization, "Information Technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane"", ISO/IEC 10646-1:2000, October 2000.
[ISO10646]国際標準化機関、「情報技術 - ユニバーサルマルチオクテットコード化された文字セット（UCS） - パート1：アーキテクチャと基本多言語平面」、ISO/IEC 10646-1：2000、2000年10月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454] Hoffman、P。およびM. Blanchet、「国際化された文字列の準備（「StringPrep」）」、RFC 3454、2002年12月。
[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.
[Unicode32] The Unicode Consortium, "The Unicode Standard, Version 3.0", 2000. (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5). Version 3.2 consists of the definition in that book as amended by the Unicode Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/) and by the Unicode Standard Annex #28: Unicode 3.2 (http://www.unicode.org/reports/tr28/).
[Unicode32] Unicode Consortium、「Unicode Standard、バージョン3.0」、2000。（Reading、Ma、Addison-Wesley、2000。ISBN0-201-61633-5）バージョン3.2は、Unicode Standard Annex＃27：Unicode 3.1（http://www.unicode.org/reports/tr27/）およびUnicode Standard Annex＃28：Unicode 3.2（http（http）によって修正されたその本の定義で構成されています。：//www.unicode.org/reports/tr28/）。
[DNS-Choices] Faltstrom, P., "Design Choices When Expanding DNS", Work in Progress, June 2005.
[DNS-Choices] Faltstrom、P。、「DNSを拡大するときの設計の選択」、2005年6月、進行中の作業。
[ICANNv1] ICANN, "Guidelines for the Implementation of Internationalized Domain Names, Version 1.0", March 2003, <http://www.icann.org/general/ idn-guidelines-20jun03.htm>.
[ICANNV1] ICANN、「国際化されたドメイン名の実装に関するガイドライン、バージョン1.0」、2003年3月<http://www.icann.org/general/ idnguidelines-20jun03.htm>。
[ICANNv2] ICANN, "Guidelines for the Implementation of Internationalized Domain Names, Version 2.0", November 2005, <http://www.icann.org/general/ idn-guidelines-20sep05.htm>.
[ICANNV2] ICANN、「国際化されたドメイン名の実装に関するガイドライン、バージョン2.0」、2005年11月、<http://www.icann.org/general/ idn-guidelines-20sep05.htm>。
[IESG-IDN] Internet Engineering Steering Group (IESG), "IESG Statement on IDN", IESG Statements IDN Statement, February 2003, <http://www.ietf.org/IESG/ STATEMENTS/IDNstatement.txt>.
[IESG-IDN]インターネットエンジニアリングステアリンググループ（IESG）、「IDNに関するIESGステートメント」、IESGステートメントIDNステートメント、2003年2月、<http://www.ietf.org/iesg/ statements/idnstatement.txt>。
[INDNS] National Research Council, "Signposts in Cyberspace: The Domain Name System and Internet Navigation", National Academy Press ISBN 0309- 09640-5 (Book) 0309-54979-5 (PDF), 2005, <http:// www7.nationalacademies.org/cstb/pub_dns.html>.
[INDNS] National Research Council、「サイバースペースのサインポスト：ドメイン名システムとインターネットナビゲーション」、National Academy Press ISBN 0309- 09640-5（Book）0309-54979-5（PDF）、2005、<http：// www7.nationalacademies.org/cstb/pub_dns.html>。
[ISO.2022.1986] International Organization for Standardization, "Information Processing: ISO 7-bit and 8-bit coded character sets: Code extension techniques", ISO Standard 2022, 1986.
[ISO.2022.1986]国際標準化機関、「情報処理：ISO 7ビットおよび8ビットコード化された文字セット：コード拡張技術」、ISO Standard 2022、1986。
[ISO.646.1991] International Organization for Standardization, "Information technology - ISO 7-bit coded character set for information interchange", ISO Standard 646, 1991.
[ISO.646.1991]国際標準化機関、「情報技術 - 情報交換用のISO 7ビットコード化された文字セット」、ISO Standard 646、1991。
[ISO.8859.2003] International Organization for Standardization, "Information processing - 8-bit single-byte coded graphic character sets - Part 1: Latin alphabet No. 1 (1998) - Part 2: Latin alphabet No. 2 (1999) - Part 3: Latin alphabet No. 3 (1999) - Part 4: Latin alphabet No. 4 (1998) - Part 5: Latin/Cyrillic alphabet (1999) - Part 6: Latin/ Arabic alphabet (1999) - Part 7: Latin/Greek alphabet (2003) - Part 8: Latin/Hebrew alphabet (1999) - Part 9: Latin alphabet No. 5 (1999) - Part 10: Latin alphabet No. 6 (1998) - Part 11: Latin/Thai alphabet (2001) - Part 13: Latin alphabet No. 7 (1998) - Part 14: Latin alphabet No. 8 (Celtic) (1998) - Part 15: Latin alphabet No. 9 (1999) - Part 16: Part 16: Latin alphabet No. 10 (2001)", ISO Standard 8859, 2003.
[ISO.8859.2003]国際標準化機関、「情報処理 - 8ビットシングルバイトコード化されたグラフィック文字セット - パート1：ラテンアルファベットNo. 1（1998） - パート2：ラテンアルファベットNo. 2（1999） - パートパート3：ラテンアルファベットNo. 3（1999） - パート4：ラテンアルファベットNo. 4（1998） - パート5：ラテン/キリリックアルファベット（1999） - パート6：ラテン/アラビア語のアルファベット（1999） - パート7：ラテン/ラテン/ギリシャ語アルファベット（2003） - パート8：ラテン/ヘブライ語のアルファベット（1999） - パート9：ラテンアルファベットNo. 5（1999） - パート10：ラテンアルファベットNo. 6（1998） - パート11：ラテン/タイアルファベット（2001） - パート13：ラテンアルファベットNo. 7（1998） - パート14：ラテンアルファベットNo. 8（ケルティック）（1998） - パート15：ラテンアルファベットNo. 9（1999） - パート16：パート16：ラテンアルファベット番号。10（2001） "、ISO Standard 8859、2003。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[RFC2825] IAB and L. Daigle, "A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols", RFC 2825, May 2000.
[RFC2825] IABおよびL. Daigle、「もつれたWeb：I18N、ドメイン名、およびその他のインターネットプロトコルの問題」、RFC 2825、2000年5月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[RFC3467] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, February 2003.
[RFC3467]クレンシン、J。、「ドメイン名システムの役割（DNS）」、RFC 3467、2003年2月。
[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月。
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004.
[RFC3912] Daigle、L。、「Whois Protocol Specification」、RFC 3912、2004年9月。
[RFC3981] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005.
[RFC3981] Newton、A。およびM. Sanz、「Iris：The Internet Registry Information Service（IRIS）コアプロトコル」、RFC 3981、2005年1月。
[RFC3982] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS)", RFC 3982, January 2005.
[RFC3982] Newton、A。およびM. Sanz、「IRIS：インターネットレジストリ情報サービス（IRIS）のドメインレジストリ（DREG）タイプ」、RFC 3982、2005年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] Duerst、M。およびM. Suignard、「国際化されたリソース識別子（IRIS）」、RFC 3987、2005年1月。
[RFC4185] Klensin, J., "National and Local Characters for DNS Top Level Domain (TLD) Names", RFC 4185, October 2005.
[RFC4185]クレンシン、J。、「DNSトップレベルドメイン（TLD）名前の国家および地元のキャラクター」、RFC 4185、2005年10月。
[RFC4290] Klensin, J., "Suggested Practices for Registration of Internationalized Domain Names (IDN)", RFC 4290, December 2005.
[RFC4290]クレンシン、J。、「国際化されたドメイン名（IDN）の登録のための提案された慣行」、RFC 4290、2005年12月。
[RFC4645] Ewell, D., "Initial Language Subtag Registry", RFC 4645, September 2006.
[RFC4645] Ewell、D。、「初期言語サブタグレジストリ」、RFC 4645、2006年9月。
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.
[RFC4646] Phillips、A。およびM. Davis、「言語を識別するためのタグ」、BCP 47、RFC 4646、2006年9月。
[UTR] Unicode Consortium, "Unicode Technical Reports", <http://www.unicode.org/reports/>.
[UTR] Unicode Consortium、「Unicode Technical Reports」、<http://www.unicode.org/reports/>。
[UTR36] Davis, M. and M. Suignard, "Unicode Technical Report #36: Unicode Security Considerations", November 2005, <http://www.unicode.org/draft/ reports/tr36/tr36.html>.
[UTR36] Davis、M。and M. Suignard、「Unicode Technical Report＃36：Unicode Security Scominsations」、2005年11月、<http://www.unicode.org/draft/ Reports/TR36/TR36.html>。
[UTR39] Davis, M. and M. Suignard, "Unicode Technical Standard #39 (proposed): Unicode Security Considerations", July 2005, <http:// www.unicode.org/draft/reports/tr39/tr39.html>.
[UTR39] Davis、M。and M. Suignard、「Unicode Technical Standard＃39（提案）：Unicodeセキュリティ上の考慮事項」、2005年7月、<http：// www.unicode.org/draft/reports/tr39/tr39.html>。
[Unicode-PR29] The Unicode Consortium, "Public Review Issue #29: Normalization Issue", Unicode PR 29, February 2004.
[Unicode-Pr29] Unicode Consortium、「Public Review Issue＃29：正規化問題」、Unicode PR 29、2004年2月。
[Unicode10] The Unicode Consortium, "The Unicode Standard,
[Unicode10] Unicodeコンソーシアム、「Unicode標準、
Version 1.0", 1991.
バージョン1.0 "、1991年。
[W3C-Localization] Ishida, R. and S. Miller, "Localization vs. Internationalization", W3C International/ questions/qa-i18n.txt, December 2005.
[W3C-Localization] Ishida、R。およびS. Miller、「Localization vs. Internationalization」、W3C International/ Questions/ QA-I18n.txt、2005年12月。
[net-utf8] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", Work in Progress, April 2006.
[Net-UTF8] Klensin、J。およびM. Padlipsky、「ネットワークインターチェンジのユニコード形式」、2006年4月、進行中の作業。
Authors' Addresses
著者のアドレス
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Patrik Faltstrom Cisco Systems
Patrik Faltstrom Cisco Systems
EMail: paf@cisco.com
Cary Karp Swedish Museum of Natural History Box 50007 Stockholm SE-10405 Sweden
キャリーカープスウェーデン自然史博物館ボックス50007ストックホルムSE-10405スウェーデン
Phone: +46 8 5195 4055
EMail: ck@nrm.museum
IAB
iab
EMail: iab@iab.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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.
この文書は、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 provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。