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).
著作権（C）インターネット協会（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がそうすること、ならびに要約及びIETFの外側に必要とされるいくつかの作業を識別する際に従うべきIDNのフレームワークに関連するRFCを更新する必要があることをお勧めします。特に、いくつかの変更は、これらの基準が完成したことから得られた経験に基づいて、アプリケーション（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.
IDNのは、広範囲の問題に対する解決策として提唱されてきたが、この文書は、従来の「ホスト名」として使用するために、同じ要件を反映して、安定性、および精度、彼らはDNS名以下でかつ劣らないという観点から書かれていますしかし、許可された文字の非常に大きなコレクションを使用。 IDNは、すべての言語やスクリプトからも同様にアクセス可能であり、インターネットに向けたステップを表しながら、特に、彼らは、最高の状態で、その非常に広い目的のほんの一部に取り組みます。 IDNのは、最初、彼らが実際にあることが判明する方法が重要について提案されて以来、論争がありました。その論争は、おそらく継続されます。すべての言語からのアクセシビリティとは、したがって、彼らがUnicode文字セットに追加されるIDNのための当社の基準や定義が追加スクリプトにスムーズに適応していることが重要である、重要な目的です。
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.
IDNの有用性は、ユーザーによるそれらのアプリケーションの観点とプロトコルで評価する必要があります。単にDNSに名前を入れて、それを取得する機能は、それ自体が、重要ではありません。彼らのASCIIの対応よりも、劣らず安定した予測、および劣らず安全です参照 - 彼らは安定した予測の参照を提供する場合、この観点からは、IDNのは便利で有効となります。
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で検索された場合も、陽性反応が完全一致のみを反映することができます正確に一致が存在しない場合は、1がエラー応答ではなく、近くにマッチやその他の補足情報の一覧を取得します。検索とおおよそのマッチングはできません。
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の風景をレビューし、IABのお薦めや結論を提示（セクション7を参照）、前方IDNの問題とパスの見直しで起訴。その勧告は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.
国際化された文字列（ "のstringprep"）[RFC3454]のRFC 3454の調製。 。文字列はUnicode文字列を取り、標準的なフォーマットに変換するための一般的なメカニズムです。 。文字列自体はただのルール、テーブル、および操作のコレクションです。それがどのように、どの特性と、適用されるこれらの規則のかを指定する「の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プロファイルとして使用されることを指定し、ピュニコードは、名前の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）[RFC3491]のためのstringprepプロフィール。 NAMEPREPは、大文字小文字を区別し、伝統的に同じ文字の大文字と小文字の形として知られているものをサポートするスクリプトのを支援するために、IDNの特定のニーズを満たすように設計され、特にれます。 NAMEPREPアルゴリズムの結果は、大文字と小文字を区別しない比較を行うことができるように、Unicode文字セットのサブセットを含む文字列が、正規化およびケース折り畳まれます。
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ピュニコード：アプリケーションにおける国際化ドメイン名のUnicodeのブートストリング符号化（IDNA）[RFC3492]。ピュニコードはASCII文字にUnicode文字列を符号化するための仕組みです。使用される文字は、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は、IDNのためのベース、および定義し、文字セットとして使用されています。 Unicodeは、ユニコードコンソーシアムによって標準化、およびISO / IEC 10646 [ISO10646]を作成するために、ISOと同期しています。前述のRFCが作成された時点では、Unicodeがバージョン3.2にありました。理由は後述するため、IDNAを採用した場合のUnicodeの特定の、その時点で、バージョンを選択する必要がありました。その結果、RFCはUnicodeバージョン3.2 [Unicode32]に明示的に依存しています。新しいUnicodeのバージョンを使用するIDNAのRFCを修正するための確立された機構（セクション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の技術委員会（UTC）、ユニコードコンソーシアムの委員会の一つ。
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標準[Unicode10]を発表し、その本来の仕事に基づいて基準を開発し続けています。ユニコードは、国際標準化機構と共同で開発し、それが同等の文字エンコーディングとしてISO / IEC 10646 UnicodeとISO / IEC 10646の機能とその文字レパートリを共有しますが、Unicode標準ではカバーし、実装のためのより多くの情報が含まれています - 深さ - などビット単位の符号化、照合、およびレンダリングなどのトピック。 Unicode標準は、双方向テキストをサポートするために必要なものを含む文字属性の多くを列挙します。ユニコードコンソーシアムおよびISO規格は、わずかに異なる用語を使用します。
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].
このスクリプトは、一の以上の言語の表記に使用するグラフィック文字のセットです。この定義は、[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を使用して定義され、その標準は、その文字の名前と説明で用語「LATIN」を使用しているので、その用語は、「ローマの由来は、」明確にするために必要とされるときを除いて、同様にこの文書で使用されます。しかし、文化や言語的な観点から、この文書に近づい読者がこの文書に記載されている、または参照「ラテン文字」、への使用はローマ由来の文字のコレクション全体を指していることに注意する必要があり、だけではなく文字を書き込むために使用しますラテン語。スクリプトの識別と他の規格との関係を持ついくつかの他の問題は、[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以外のグループによって使用されています。 1例えば[W3C-ローカライズ]を参照してください。
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").
IETFにおいて、用語「国際」は追加またはプロトコルに非ASCIIテキストの取り扱いを改善説明するために使用されます。その他の体は、多くの場合、意味の微妙な変化で、他の方法で用語を使用しています。用語「国際化」が多い（「ローカライゼーション」などとローカリゼーション）「国際化」と略されます。
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.
テキストを扱う多くのプロトコルは、唯一のスクリプト（多くの場合、英語のテキストを書くに使用する文字のサブセット）、または（相互運用性の問題につながる）ローカル当て推量まで使用されているものの文字セットの問題を残すに関連した文字を処理します。そのようなプロトコルに非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のRFCのが公開されたときは、IESGとICANNは、展開と今後の作業を導くために意図されていた発言を行っております。ここ数カ月の間には、ICANNは、そのステートメントを更新しており、他の人にも貢献をしました。 DNSに適用される国際化の問題の理解の質は過去数年間で大幅に進化してきたことは注目に値します。一年以上前に特定の位置を取った組織は今日まったく同じ文を作成しない場合があります。
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つの目的を果たすことを意図していました。最初は、第3および第4の位置にハイフンを含むラベルの登録上の契約制限からICANNによって確立されていたジェネリックトップレベルドメイン（gTLDの）レジストリを解除するための基礎を提供することでした。第二は、IDNを実施するためのレジストリポリシーの開発のための一般的なフレームワークを提供することでした。
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.
RFC 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のメカニズムは、追加のポリシーもベースの言語であることで、特定の言語で、すべての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）言語の一つの言語またはセットで登録された各国際化ドメイン名を関連付けし、（b）は、言語固有の登録と管理ルールを採用し、文書化し、公的に利用可能であること、などレジストリは、特定の言語のための登録と管理規則は、文字の恩恵を受けることが判明相当する文字の登録ドメイン名に関連付けられている言語の変種、および、（C）を持つすべてのドメイン名の予約がテーブルをバリアントに登録を許可します適切なテーブルが利用可能であるのみその言語... IDN標準を実装するには、トップレベルドメインレジストリは、少なくとも最初は、関連付けられた文字に（例えば、第二レベルドメイン名のような）任意のドメインラベルを制限しなければなりません一つの言語または言語のみの設定。」
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.
それは、それは任意の言語に関連付けるだろう文字レパートリを定義するために、各TLDのレジストリに残っていました。これは、基礎となる言語ベースのIDN政策の更なる異質で、レジストリにレジストリから大きな変動につながりました。ガイドラインは、スクリプトに基づいているIDNポリシーのために準備をしていた場合は、結果の曖昧さのかなりの量が回避されている可能性が。しかし、彼らはしませんでした、とIDNAの現在見直しにつながる一連のイベントは、このように誘発されました。
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レジストリの回答の一つは、初期の指針に記述メカニズムを呼び出すことだった：「定期的にこれらのガイドラインを見直すのIDNが進み、ICANNとIDNレジストリの展開としては、と経験に基づいて、必要に応じて変更します。」
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."
このアクションの結果は、9ヶ月の期間2005年11月8日にICANN理事会によって承認されたガイドライン[ICANNv2]、バージョン2.0でした。審議会は、「タスクのIDNワーキンググループはその重要な仕事を継続し、モロッコでのICANN会議の前に、特定のIDN改善勧告にボードに戻るには、」と「の方法で完全にガイドラインをリフレームするワーキンググループの継続的なアクションをサポートしていることをさらに述べましたガイドラインの方向はDNS階層にとICANNが低いポリシーの関係を持っているTLDの中に深く使用されることを確実にするために、最も良い現在のプラクティス（BCP）ドキュメントとしてのさらなる発展のための適切な。」
Retaining the inclusion-based approach established in version 1.0, the crucial addition to the policy framework is that:
バージョン1.0で確立包含ベースのアプローチを保持し、ポリシーフレームワークの重要な添加は、ということです。
"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."
＃24附属書Unicode標準によって決定された「単一のラベルのすべてのコードポイントは同じスクリプトから取得されます：スクリプト名を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）のラインシンボルの描画（ユニコードボックス描画ブロックのもののように）文字を、（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.
お勧めの主要な改正は（2006年6月下旬で）モロッコでの会議に先立ち、ICANN理事会に置くことをするために2005年11月に意向だったが、の2.nリリースをするために変更が漸増照合することと暫定バージョンで表示されますガイドライン。 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.
このセクションでは、いくつかの種類の問題や課題を織り交ぜ。各サブセクションは、したがって、補正を必要とする、「IDNを持つ」問題や課題であることを認識されている何かを概説します。これらの問題のいくつかは、少なくとも部分的にIDNAプロトコルやテーブルの要素に変更を加えることで解決できます。その他には限り人々が基本的なDNSアーキテクチャと矛盾するのIDNの期待を持っているとして存在します。これにより、ユーザーは、登録者、および政策立案者は、多くの場合、彼らが起こるか起こるべきで、何を実際に起こる信じるものの間のプロトコルやその他の技術的な問題が、唯一の違いを理解していないので、問題のこの全体の範囲を特定することが重要です。限り、それらの違いが存在するとして、IDNのための機能やポリシーの変更の要求があるでしょう。もちろん、これらの要求の一部は、他よりも少ない現実的になりますが、でも現実的なものは、他の人と同じ文脈で理解されるべきです。
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のバージョンへの移行が想定されているかどうかを縛られたままかどうか存在します。移行パスは、新たに符号化されたスクリプトに対応するために、ドメイン名で表現される言語およびスクリプトの最大数を可能にするために必要です。しかし、移行の問題は、特に、単一の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.
DNSのラベルは、本質的に特定の言語に縛られていない文字の文字列だけです。はじめに簡潔に述べたように、辞書的に任意の言語の単語であることができなかったDNSラベルが可能と確かに共通しています。より多くのホスト名のラベルが制限されているすべての-ASCIIよりも、それらを制限することになるのIDN上のプロトコルの制限を課すする理由はないように見えます。その理由も「名前」としてDNSラベルやそれらの文字列を記述するための誤った名称の何か、おそらく期待するかについて、ユーザーの混乱に追加したものです。
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.
彼らは物事との願い他人を考えるとき通常、人々は、例えば、「オレンジ」、「木」、「レストラン」や「アクメ社」あまりにもそれらを考えるために、「言葉」を使用します。言葉は、英語やスウェーデン語などの特定の言語、にあるのが普通です。 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.
書き込みまたはラベル（またはワード）を入力すると、スクリプトを選択しなければならないと文字セットは、そのスクリプトで使用するために選ばれなければなりません。文字セットの選択は、単語ごとまたは文書に基づいて、ユーザの制御下で、一般的ではありませんが、でも、ローカル入力デバイス、キーボードやターミナルドライバー、またはオペレーティングシステムによって行われた他の決定やハードウェア設計者や実装に依存してもよいです。
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:
その文字セット、または関連するオペレーティングシステムまたはアプリケーションソフトウェアによって使用されているローカル文字セットは、ユニコードでない場合、さらなる変換は、Unicodeを生成するために実行されなければなりません。どのくらいの頻度でこれが問題であることはユニコードは、ハードウェア、オペレーティング・システム、およびアプリケーションのネイティブ文字セットとして展開されている方法を広くの見積りに依存します。他の困難の中で、これらの見積りとは大きく異なり、それが点に留意すべきです。
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;
ISO 8859のバージョン[ISO.8859.2003]およびISO 646の偶数国立バリエーション[ISO.646.1991]、まだ広くヨーロッパの一部で使用されるO、
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
典型的には、ISO 2022の技術に基づいO符号表の切り替え方法、[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・コンピューティング、システム、および中国での通信は、国家の「GB」の基準ではなく、ネイティブのUnicodeの一つ以上を使用する傾向があります。
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.
また、すべての文字セットは、同じように自分のキャラクターを定義し、すべてではない既存のコーディングシステムは変更せずにユニコードに組み込まれたではありません。時には地元の区別は、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.
ユニコードネイティブシステムに自明であるが、それは他に重要であるかもしれ処理 - - この処理から生じるUnicode文字列は、その後、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のコーディングと関連規則の用語で記述された議論の多くは、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を考えてみましょう。スウェーデン語では、U + 00F6（分音符号付きラテン小文字o）で綴られている間ノルウェー語では、第二音節の文字U + 00F8（ストローク付きラテン小文字O）で綴られています。スウェーデン語、デンマーク語、またはノルウェーを話すほとんどの人はおそらく、彼らは同等であると思いながら、これらの文字はUnicode規格とその付属書によると同等に扱われていません。
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".
複数のスクリプトを使用して表現することができる世界では言語があります。例えば、一部の東欧と中央アジアの言語は、アラビア語やラテン文字のいずれかで表現することができるキリル文字またはラテン語（1.5.2項を参照）の文字、またはいくつかのアフリカや東南アジアの言語のいずれかで表現することができます。いくつかの言語でも三つの異なるスクリプトで記述することができます。他の場合には、言語は、典型的には、スクリプトの組み合わせで書かれている（例えば、漢字、かな、および日本語ローマ字、韓国語のためのハングルと韓紙）。このため、同じ単語は、同じ言語で、さまざまな方法で表現することができます。いくつかの言語では、唯一つのスクリプトは、通常、単一の単語を書くために使用されます。他人のために、混合スクリプトが必要とされています。そして、まだ他の人のために、特別の事情がそれは通常、「言葉」のために行われていませんが、ラベルにスクリプトを混入指示することができます。 IDNの目的のためには、これらの変動は、ICANNは今それがレジストリ政策の主要な基礎として使用することを推奨している、特に以来、「スクリプト」の定義は非常に敏感にします。しかし、基本的なことは、混合スクリプトラベルを禁止することも、追加のポリシーニュアンスは、「複数のスクリプトの合同使用する必要が設立のつづりや規則を持つ言語」のために必要とされます。
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」の由来文字（中国語、日本語、および韓国語）言語、すなわち、共通の導出と同様の外観を有する文字が同じコードポイントに割り当てられ、「統一」です。ギリシャ語、ラテン語の塩基から誘導される欧州文字が個々の文字は、フォームおよびセマンティクスの両方で同じであってもラテン語、ギリシャ語、およびキリル文字用の別のコードブロックに分離されます。単独のフォントの違いに基づいて別々のコード・ポイントは、一般的に禁止されていますが、「数学」の使用のために大量の文字は、「大胆」、彼らは唯一、このような「スクリプト」としてフォント属性によってベース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項を参照）との潜在的な困難を制限する文字が一部のフォントではなく、他の人に似ている可能性があるのも、より多くの知識が必要です。これらの変化は、それが困難または不可能ユニコードのすべてにルールの単一のセットを適用し、そうすることで、誰もが、その認知ニーズを満たすために作ります。代わりに、より多くの又はより少ない文字ごとに定義された複雑なマッピングテーブル、マッチングが可能であるように、単一のフォームに同じ文字の異なる表現を「正規化」する必要があります。
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には一致しません。単語が単一の単語は、いくつかの異なるUnicode文字列として表現されてしまうことができ、Unicode文字列として表現される前に、これらの問題の最も一般的な原因処理に適用する（及び上述）、ということです。正規化ルールが適用されている場合でも、ユーザーが同一とみなされ、いくつかの文字列が等しいとしません。その問題は、特に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文字の順序を変更することができます。一例では、U + 0308に続く基本文字U + 0061（ラテン小文字のA）が（分音符号を組み合わせる）は、単一のユニコード文字U + 00E4（分音記号付きラテン小文字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.
このUnicodeの正規化プロセスは単純な文字等価ではなく、言語やスクリプトに依存している等価を占めています。上述したように、例えば、文字U + 00F8（ストローク付きラテン小文字O）とU + 00F6（分音記号付きラテン小文字O）は、すべての言語スウェーデン語（およびいくつかの他の言語）に一致すると考えられるが、されていませんそれは、文字のいずれかを使用します。これらの文字は、いくつかの状況において同等ではなく、他のように扱われたことはIDNAまたはUnicode文字ベースの正規化テーブルのいずれかを提供することができますよりも、今度は、文脈にはるかに依存し、意思決定とメカニズムが必要です。
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 ABOVEを組み合わせることで、その後LATIN SMALL LETTER）が表示された場合、NFKCとして知られているUnicode正規化の方法は何であるU + 00EF（分音記号WITH SMALL LATIN LETTER I）、にそれをマップします一つは予測します。しかし、U + 0131 U + 0308（LATIN SMALL LETTER DOTLESS Iとダイエレシスを組み合わせることを）考えてみます。同じ文字ということですか？ U + 0131 U + 0307 U + 0307 U + 00EFまたはU + 0069に相当（ドットなしiと2がドット以上の文字を組み合わせて）、またはどちらですか？ NFKCは、私たちに伝えるためには表示されません、またU + 0307の定義は、それが多かれ少なかれ指定結合文字「上記のアクセント」の一部とは異なりアレンジメント（、他の「上記の記号」と組み合わせたときに何が起こるかを教えているように見えるん）カーニング。 U + 00EFは種々ドット上記合成文字と組み合わされるとき、同様の問題が生じます。異なる表示の実装が異なる方法でルールを解釈するならば、これらの質問のそれぞれには、なりすましのためのいくつかの機会を提供しています。
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.
私たちはラテン語のスクリプトを残して、漢字をベースにしたものを調べると、私たちは、簡体字および繁体字中国語の間の変換のための具体的な、lexigraphic、ルールが存在しない場合もある参照してください。このようなルールがあったとしても、中国のものと日本語と韓国語の文字の統一は不可能同じ文字の日本語と韓国語の使用に問題を生じさせることなく、簡体字中国語ものに繁体字中国語を正規化することになるだろう。
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.
言語の文字のユーザーの認識におけるこれらの変化は、それが困難または不可能一切エンドユーザーは、これまでの結果に驚いされていないような方法でUnicode文字列を一致させるための均一なアルゴリズムを提供することを可能にします。密接に関連するスクリプトや文字の場合は、驚きでも頻繁にあります。しかし、均一なアルゴリズムは名前が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つのUnicode文字列がまったく同じに見えるかもしれないということです。例えば、キリル文字、ギリシャ語、およびラテン語で、いくつかのグリフが同じように見えるけど、Unicodeで異なるコード・ポイントが割り当てられているためです。さらに悪いことに、一つはスクリプトを使用して合理的に精通している必要があり、それが合理的に芸術的なフォントとタイポグラフィの結果として変化することができますどのくらいの文字理解するために使用される方法。例えば、観察者が簡単にタイ文字の文字と文字の一部を混乱させる可能性があることを十分に非常に飾られているラテン文字のためのいくつかのフォントがあります。大文字ITCブラックアダー（国際書体社の登録商標）と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).
いくつかのスクリプト（およびそのためには、いくつかの言語のいくつかの単語）が左から右へ、しかし、右から左に書かれていません。そして、物事を複雑にし、1は、このようなヨーロッパスタイルの数字として、左から右に読まれるいくつかの文字が含まれて右から左にアラビア文字で書かれた何かがあるかもしれません。これは、いくつかのテキストが（例外として他に、ほとんどの実装では、と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は、そうでない場合は、右から左への文字のシーケンスであるラベルで、欧州の数字を含めることを可能にし、他のほとんどの混合方向（または双方向）文字列を禁止しています。この禁止は、このようないくつかのそれ以外の言語的および文化的に賢明な文字列の拒否など、他の問題を引き起こす可能性があります。 Unicodeとは、いわゆる双方向（「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のは、潜在的に混同されるのに十分に似ている多くの追加の文字を提供することにより、だけでなく、新しいポリシーの質問を上げることによってだけでなく、これらの問題を複雑にしています。言語は二つの異なるスクリプトで記述することができた場合、ラベルは、他のスクリプトで記述された同じ単語から構築されたラベルに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文字ラテンA、-B、-C 、... "。 1が存在しないので、しかし、：国と言語の間に1マッピングは、.SEのようにも国別コードトップレベルドメイン（ccTLDの）は、他の言語での登録を受け入れなければならないかもしれません。例えば、フィンランド（スウェーデンで二番目に使用される言語）の要求があってもよいです。どのようなルールやコードポイントは、その後、フィンランドのために定義されていますか？それはスウェーデンのために定義されているものと衝突特別なマッピングを持っていますか？そして、もう一つは、一つのスクリプトよりも多くを使用する国で何をするのでしょうか？ （フィンランドとスウェーデンの同じスクリプトを使用しています。）すべての場合において、紛争は最終的に2つの文字列が同じ（または紛らわしい）しているか否かについてになります。これは、順番に、1は「問題になるのに十分似ているものを」「同じ何であるか」と定義する方法の説明を生成します。
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.
別の例は、さらなる問題を示していることが最近起こりました。 1文字、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で何かを登録すると、Bの代わりにAとドメイン名は、（BがAと紛らわしい外観を有する別々のコード・ポイントの文字である）他の人が登録からブロックされます。
2. If you register something with code point A, you also get domain name with B instead of A.
あなたはコードポイントAで何かを登録した場合2.、あなたはまた、代わりに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]にしています。
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.
彼らは一度に理解された少なくとも上記のような問題は、レジストリが持っているべきであること（これは、最初のICANNガイドラインの基礎の一部であった、）セクション1.6.1に含まIESG文の背景を提供しました登録が受理されるためのスクリプト、言語、コードポイントとテキスト方向についての方針。許容政策であるかもしれない「すべてが受け入れる」が、それは考慮に入れ、上記の問題点を取る紛争解決プロセスもある意味します。このプロセスは、潜在的な紛争のすべての種類に対処するために設計されなければなりません。たとえば、問題は、既に登録されているドメイン名を持つと登録者と商標権者（ドメイン名が商標を侵害していること）との間の衝突でレジストリの決定を介して登録者とレジストリの間で発生する可能性があります。どちらの場合も、不同意の当事者は、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.
意見は問題が実際にどのように重要な程度異なるが、IDNAのUnicodeとそのサポートテーブルの使用は、それが一般的なUnicodeアプリケーションであるよりも、微妙な変化にはるかに敏感であるように思われます。他の多くのアプリケーションは、文字のみの外観ではなく、その表現に内部的に敏感であるので、これは、少なくとも部分的にであってもよいです。あるいは、これらのアプリケーションは、スクリプト言語、または文字クラス識別の有効活用することができるかもしれません。 IDNAを開発したワーキンググループは非現実的と賢明だろうDNSラベルに任意の補助的な文字情報をコード化しようとすると結論し、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.
ユニコードコンソーシアムは時々実際に可能変更の安全性の基準として、自然言語で表示される文字の組み合わせの可能性を使用しています。その上略語、意図的に珍しいなるように形成さ、文字列、数字または他の文字によって配列決定シリーズのメンバー、および - しかしながら、上述したように、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.
変化へのこの感度は変更は厳密に添加されないよう作られていた場合、それは非常に困難隣にはUnicodeの1つのバージョンからIDNAを移行できるようになりました。 DNSラベルは以前の形式を使用して定義されており、その前の成分のいずれかが別のテーブル位置または正規化ルールから移動された場合、コードポイントの割り当てまたは定義の変化は非常に破壊的であってもよいです。セキュリティ勧告の補助としてUnicode正規化テーブル、それらに属しているスクリプトや言語や文字のテーブル、紛らわしい文字のも、表には、不審な名前を回避または識別するための登録とアプリケーションの規定上のレジストリ制限を設計する上で非常に有用であろう。皮肉なことに、彼らは、一つのUnicodeのバージョンと次の変化のすべての形態にIDNA、その実装の感度を拡張します。その結果、彼らは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
1つの観点からだけ小さな補正であるように見えるが、別の問題となり得る変化のタイプの例は、[UNICODE-PR29] 2004年正規定義に補正しました。コミュニティの入力は、変更があろうと示唆しました
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.
文字列準備のために問題を引き起こすが、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名またはその登録されたプロパティの一部を無効にする可能性があるか、その名前の文字列や表現があいまいになるかもしれない場合はUnicodeの1つのバージョンから次へと移行することも同様に受け入れられません。 IDNAは、Unicodeの新しいバージョンに対応するために変更される場合は、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コンソーシアムの心配の必要性を明確にすることができ、場合にも有用であることが分かるでしょう。そのような事項は、まだエンコードされていないスクリプトを含めることを遅らせた場合は、ここで検討するほぼすべての観点から、不幸なことでしょう。
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つは、同様の目的を達成するために重ね打ち文字を使用する従来のシステムと同様に、明示的文字セットにするために提供されていない文字を生成するために、コードポイントの配列を使用することが可能であるということです。明確にするために提供されていない配列は、（例えば、正規化テーブルのような）いくつかの機構によって禁止されない限り、しかし、そのような合成配列は、二つの関連する危険性を可能にすることができます。
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を正確に定義されていないか、または結合文字の予想外の組み合わせが使用されていると、それが結合し、特に文字と結合文字の関係ならば、文字の混乱の別のリスクです。その問題は、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 + 0308）で、伝統的な「私」（U + 0069）を組み合わせることで、それを表現することに同意したとします。これまでのところ、問題ありません。しかし、後に、この文字のためのより広範な必要性が発見され、それは、Unicodeへのいずれかの文字を組み合わせた3ドットの上に導入することで、単一の合成済み文字や、既存のルールの下で可能性が高い、として符号化されます。いずれの場合も、ユニコードのバージョンが新しい、承認された、一つに「i」の-Plus-分音記号のシーケンスをマッピングしNFKCでルールを含める必要があります。 1がそうしない場合は、しないこと起こるべきである正規化は間違いなくあります。 1がそうするならば、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のために十分ではないかもしれない、ということを理解してこれらの問題を回避または最小限にするルールを考慮することが有用であろう。一つの部分的な解決策は、基本文字とドメイン名のラベルに使用されているから、仮想的な「予想される組み合わせ」の表に表示されていない結合文字の任意の組み合わせを禁止するかもしれません。次のサブセクションでは、より根本的、実用的でない場合、問題のビューとその解決策について説明します。
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の複雑さおよび正規化の必要性を増加させる一つのことは、結合文字が許可されていることです。それらがなければ、複雑さは、新しいバージョンに簡単に移行を可能にするのに十分な削減される可能性があります。コミュニティは完全のIDNから文字を組み合わせ禁止の影響を考慮すべきです。それはそれが定義され、そうやっているとしてUnicodeにこの変更を導入するために、ほぼ確実に実現不可能ですが、それは可能であったとしても非常に破壊的になり、思考実験は、問題と取られていないパスの意味の両方を理解するのに役立ちます。たとえば、これの1つの結果は、もちろん、それぞれの新しい言語やスクリプト、およびいくつかの既存のものは、その文字のすべてが特定の、合成済み、コード・ポイントへのUnicodeの割り当てを持っていることを必要とするであろうということです。
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コンソーシアム内に完全に管理されています。 IETFは、結合文字を除外してIDNAの複雑さを軽減するために選択した、間違いなくユーザーや文字が要求される合成済みスクリプトの支持者からの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.
多くのユニコードの用途では、好ましい溶液は、正規のスタイルを選択して記憶または送信されるすべてのテキストは、その形式に正規化されることを必要とすることです。 （これは、標準のUnicodeテキスト形式にIETFで進行中の作業に取られたアプローチである[ネットUTF8]）。 IDNAは、この要件を課していません。テキストは、正規化とケース還元登録時に、唯一の正規化バージョンをDNSに配置されています。しかし、アプリケーションは、ネイティブ（及び小文字適切な）URLなど議論または参照に正規化された形式に関連付けられた文字を表示して必要はありません。全ASCIIのDNSラベルに使用される規則は、国際形態に拡張される場合、それが明瞭又は市場識別のための混在ケース参照の使用を禁止するので、そのような要件は、不合理であろう。それも、文化的に不適切かもしれません。しかし、その制限はなく、最終的にDNSに行われる比較は、異なる時間に正規化文字列間とUnicodeの異なるバージョンであろう。ユニコードの一のバージョンで正規化された形式の文字列がまだすべての将来のバージョンで正規化された形態であるという主張は十分ではありません。異なる時間で正規化は、所与のソース文字列は、常に関係なく正規化されたバージョンの下での、同じターゲット文字列に正規化することを必要とします。その基準は満たすことがはるかに困難です。上記の議論は、それが不可能であることを示唆しています。
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で「スタック」私たちを残すことが、完全に文字を組み合わせることで、これらの問題を無視する（IDNは、Unicode 3.2のまま）、または苦痛へ新しいバージョンへ移行します。意思決定を迅速に行われた場合、まだ1回のバージョンがバージョン4.1またはUnicodeのバージョン5にアップグレードすることが可能かもしれません。しかし、我々はその1を超えてのバージョンにアップグレードし、円滑な移行を可能にするのに十分なグローバルな制限を課すことができない限り（例えば、潜在的にDNSあるいは新しいピュニコードプレフィックスですでに変更文字列を必要とする）、あるいは不可能痛みを伴う可能性が高いです。
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は、RFCの3454、3490、3491、および/または3492、および更新の見直しを検討し、交換、またはこの段落（そのうちの1つまたは複数のさらなる研究の後に非現実的な証明することができる）の基準を満たすためにそれらを補完する必要があります。すべての新しいバージョンまたは追加の仕様は、それらが作成されたときに、現在ではUnicodeのバージョンに適合させるべきです。理想的には、彼らは（下のいくつかの提案がこれを容易にすることができる）のUnicodeの将来のバージョンに適合させるためのパスを指定する必要があります。 IETFはまた、他の人に、またはユーザのために明瞭さと理解度が良く、単にそれらの文字を禁止することにより、配信されるかどうか、バリエーションをフォントに割り当てられたコード・ポイントなどの文字のいくつかのグループを、マッピングに大きな利点があるかどうかを検討すべきです。より一般的には、IETFが今NAMEPREPでのstringprepプロファイルによって呼び出されたUnicodeの正規化ルールは、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（すなわち、許可されている文字を識別する）のではなく、文字の小さな数を除外することにより包含ベースのメカニズムを使用することによって指定されなければならないコードポイントのリストは、より広いコミュニティ内のコンセンサスがあると結論付けました文字列準備やNAMEPREPとして設定し、全ユニコードから今日やります。その結論は、必要に応じて撮影した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.
私たちは、コードポイントの見直しを行っている個人が専門の設計チームとして働く必要があることを示唆しています。可能な限り、その作業は、一般的に受け入れられたに達することができるようにするために必要なDNSおよびアプリケーション設計の制約、ユニコードコンソーシアムからの参加者、および他の人々のIETFと深い知識の経験を持つ人々が共同で行うべきです結果。これらの線に沿ってすべての作業は以下のようになりますので標準トラック文書、最終審査および任意の提案の承認の変更や更新は、必ずしも通常の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に十分に極端な変化は、新しいピュニコードプレフィックスが必要になることは注目に値します。ほぼ確実に非現実的な代替は、「フラグの日」のいくつかの並べ替え、すなわち、古いルールが同時にみんなに捨て、新しいものが採用された日になります。しかし、予備的な分析があれば、いくつかの、この文書の他の場所での検討のため推奨される変更のバージョン変更のこのタイプを必要とすることを示しています。たとえば、上記の暗黙のような追加の制限は、登録することができるものに課せられていると仮定します。これらの制限は、ラベルは、彼らが以前のルールに適合している場合ではなく、新しいものに配置されることになっている方法についての政策決定が必要な場合があります。しかし、彼らは本質的に、プロトコルまたはプレフィックスの変更を必要としないであろう。
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.
IETFは、再び、DNS経由で国際化の問題を解決し、いわゆる「キーワードシステム」や他のインターネットのナビゲーション技術の多くの品種が持つかもしれないどのような場所試すことが適切である程度を調べる必要があります。これらの技術は、IDNAとDNSよりも、制約が少ない、または少なくとも異なる制約を課すように設計することができます。このドキュメントの別の場所で説明したように、IDNAは、ルックアップのスクリプト、言語、またはUnicodeのバージョンについての情報をサポートすることはできません。 DNS検索、文字とラベルのいずれかが一致の性質の結果として、または一致していません。近いマッチは単にDNSで可能な概念ではありません。これとは対照的に、近いマッチングの観察は、人間のコミュニケーションで、彼らは心の中で特定のスクリプトや言語コンテキストを持っている場合は特に、人の動作を一致では一般的です。国際命名のいくつかのアプリケーションは、より多くの柔軟性を必要とするかもしれないDNSは、さらに、（CNAMEとDNAMEリソースレコードを介して）かなり剛性内エイリアシングシステムによって制約されます。それはroot--と名前が一意であることの必要性最も近いレベルでフラットになるのを最後に、DNSの剛性階層が実際に傾向を - そして、他のものよりいくつかの目的のために、より適していると良い試合ではないかもしれませんいくつかの目的のためにいる人は、IDNのを使用したいです。これらの制約のそれぞれを緩和またはユーザーがDNSを直接使用に代わるものを提供する1つ以上のシステムによって変更することができます。関連する問題のいくつかは、5.3節でさらに議論されており、様々なアイデアがIETFかIRTFで詳細に説明されています。これらのアイデアの多くは、さらにはインターネットドラフトや他の文書に記載されています。 IDNのと、それらへの期待と経験が蓄積するとIETFかIRTFは根本的な質問と可能性を再検討するために、それはおそらく適切になります。
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".
これとのIDNに関連する他の問題では、用語の正確な使用がさらに混乱結果LEST重要です。通常の辞書や言語のテキストで表示される用語「同形異義語」の定義は、同形異義語は、（例えば、短いという意味の形容詞「簡単」、名詞文書を意味する「簡単」、および動詞同じように綴られた異なる単語があると述べています「簡単な」）通知することを意味します。定義では、二つの異なるアルファベットの文字に関係なく、外観の類似性の、同じではありません。これは、コンピュータディスプレイ上で同じになるように表示される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年の最前線に持ち込まれた場合には、用語の同形異義語は、個々の文字を比較した場合でも、グラフィック、類似の任意のインスタンスを指定するために使用されました。この使い方だけでなく、間違っている、しかしそれゆえに一層の混乱を導入し、リスクは避けるべきです。現在の優先用語は「混同しやすい文字」あるいは「confusables」として、これらに類似した文字を記述することです。
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ブラウザは、潜在的に紛らわしいラベルの登録のための安全な慣行を持っているとみなされるトップレベルドメインのサブドメインにネイティブな文字の表示を制限する「ホワイトリスト」または類似の技術に基づいて規則を、採用しています。他のドメイン内のIDNはピュニコードとして表示されます。これらの技術は、彼らは明らかに有用であるが、彼らが適切ではないかもしれないので、トップレベルドメインとそのサブドメインとの間の政策の違いに十分に敏感ではないかもしれません。紛らわしい文字可能性に対処するための他の方法はありますか？混乱の登録が可能と役に立つことを回避についての方針を確認し、リストの他の方法は、でしょうか？
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.
作業は、電子メールアドレスのローカル部分に関連するIETFで起こっています。電子メールアドレスのローカル部分がそう直接ローカル部分ができない上IDNAを適用するには、ドメイン名のラベルよりもはるかに異なる構文と制約を持っていることに留意すべきです。
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で使用するために特に重要です。今後IETFプロトコルのベースとしてUnicodeを使用するという決定は、[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.
IDNのは、新たな商標とドメイン名の間の衝突の種類だけでなく、ドメイン名の衝突を作成します。これらは、レジストリとそれ以外で使用される紛争解決プロセスに影響を与えます。 IDNのの展開は、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.
主張や明白な混乱や名前の競合に対処するための最も確立されたポリシーは、紛争解決に基づいています。一つ以上の名前がケース・バイ・ケースで登録時または後に解決され、特定の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.
ユニコードで利用可能と紛らわしい文字をより多くすることによって生成することができる競合の数のので、私たちは、登録制限及び紛争解決ポリシーは、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の）が、少なくとも3つの非常に別のもののトップレベルでのIDNと1つの問題がないことを締結しています：
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.
IDNがルートゾーンに入力する場合、O、意思決定は、まずこれらの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ルートレベルの名前空間の政策の一つであり、我々は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.
IDNラベルがルートゾーンに配置される場合は、O最後に、彼らは符号化して展開される方法に関連した問題があります。このエリアには行われている、または実行する必要があり、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文字にオリジナルの「ホスト名」の規則から一般化します。これにより、元のIDNA / NAMEPREPテーブルを開発するために使用されるアプローチと対照的な、IDNラベルに使用できる文字について制限モデルを伴うだろう。このアプローチは除外する明確な理由がなかったことを、すべてのUnicode文字を含めることでした。
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.
世界の言語のいずれかの単語や数字を書くために必要されていないUnicode文字は、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名の簡単なレガシープロパティとして扱い、他のスクリプトにそれを一般化しようとしないことが適切であるかどうかを検討すべきです。私たちは、例えば、IDNの中で使用される他のスクリプトからハイフンを主張同等物を許可しない場合があります。私たちも、それほど限定、非ラテン文字を含む文字列を非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の適切な使用に境界線があることを、コミュニティを思い出させることを望みます。これは、いくつかの特定の目的を果たすために設計および実装されました。それがうまくないこと、追加のもの、それはひどくない他のもの、そしてそれがすべてで行うことはできません、まだ他のものがあります。 IDNの上のプロトコルの作業のない量がように適切な名前を探して、別のつづり、近いマッチの問題を解決していない、となります。登録の制限、慎重に設計されたユーザインタフェースは、特定のポイント、使用を超えて、リスクや間違っただけでなく、意図的な悪い行動の様々な種類のリスクを軽減なくなってこれらの事のいくつかを行うための試みの痛みを軽減するために使用することができますが、 DNSのそれが利用可能であるという理由だけで、悪いトレードオフになります。 IDNの使用は、実際に提案した問題が解決しないときにはトレードオフが特に不幸かもしれません。例えば、DNS名の国際化は、ASCIIプロトコル識別子とのURI [RFC3986]及び偶数のIRI [RFC3987]の構造を排除するものではありません。したがって、DNSの国際化自体は、DNSツリーのいずれかまたは全てのレベルで、完全に自分の言語とその言語に関連した文字にインターネットを使用するための集団の欲望に十分な応答ではありません。
These issues are discussed at more length, and alternatives presented, in [RFC2825], [RFC3467], [INDNS], and [DNS-Choices].
これらの問題は、より詳細に論じており、選択肢は[INDNS]、および[DNS-選択肢]、[RFC2825]で、[RFC3467]を発表しました。
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におけるそれらの存在に加えて、IDNのドメイン名が使用されている他の文脈で問題を紹介します。具体的には、登録者の情報への登録名をバインドするデータベースの設計と内容は、（一般に「WHOIS」データベースと記載する）のレビューと更新が必要になります。例えば、WHOISプロトコル自体[RFC3912]は、非ASCIIテキストを処理するための標準的な機能を持っていない：1は、DNS名またはASCII文字ではありません連絡先情報のいずれか、のために一貫して検索、またはレポートすることはできません。これは、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.
この文書では、単にのIDNおよび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アドホック委員会のメンバーからこのレポートへの貢献は深く感謝しています。もちろん、そのグループのすべてのメンバーは、このレポートのすべてのコメントや提案を推奨するものではありませ。具体的には、この報告書は、全体またはそのコンソーシアムの仕事で特定の参加者のものとはUnicodeコンソーシアムの見解を反映するために主張しません。
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.
アドホック委員会のメンバーは次の通りであった：ロブAusteinと、レスリーDaigle氏、ティナ・ダム、マーク・デイビス、パトリックFaltstrom、スコットホレンベック、キャリー・カープ、ジョン・クレンシン、ガーバス・マークハム、デヴィッド・メイヤー、トーマスNarten氏、マイケル・Suignard、サム・ワイラー、バートWijnen 、クルトZeilenga、およびLixiaチャン。
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.
おかげで、両方の、ティナダムと多くの貢献とコメントのためにかなりの特定のテキストの貢献のため、慎重な後期の読み取りと豊富なコメントマルコスサンスとポール・ホフマンに、そしてピート・レズニックにICANN IDNワーキンググループに関連付けられている他の人のためであります彼の元IABのサービスと連携し、その後。パトリックFaltstromとピートResnick氏は2006年3月に辞任した後、オラフM. Kolkmanは、このドキュメントのためにIABリーダーシップを引き継ぎました。
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のメンバーは次の通りであった：バーナードAboba、ロア・アンダーソン、ブライアン・カーペンター、レスリーDaigle氏、パトリックFaltstrom、ボブHindenとカーティスLindqvist、デビッド・マイヤー、ペッカNikander、エリックレスコラ、ピート・レズニック、ジョナサン・ローゼンバーグとLixiaチャン。
[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]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、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.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（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]ホフマン、P.とM.ブランシェ、 "NAMEPREP：国際化ドメイン名のためのstringprepプロフィール（IDN）"、RFC 3491、2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]コステロ、A.、 "ピュニコード：アプリケーションにおける国際化ドメイン名のUnicodeのブートストリングのエンコード（IDNA）"、RFC 3492、2003年3月。
[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規格、バージョン3.0"、2000年（リーディング、MA、アディソン・ウェズリー、2000 ISBN 0-201-61633-5）。ユニコード3.2（のhttp：＃28附属書のUnicode 3.1（http://www.unicode.org/reports/tr27/）とUnicode標準で附属書Unicode標準＃27で修正されたバージョン3.2は、その本の中で定義で構成されてい：//www.unicode.org/reports/tr28/）。
[DNS-Choices] Faltstrom, P., "Design Choices When Expanding DNS", Work in Progress, June 2005.
[DNS-選択肢] 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/ IDN-ガイドライン - 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-ガイドライン - 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]インターネット技術は、 "IDNのIESG声明" グループ（IESG）ステアリング、IESG文IDN声明、2003年2月、<http://www.ietf.org/IESG/書/ 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]国立研究評議会、 "サイバースペースの道標：ドメインネームシステムとインターネットナビゲーション"、米国アカデミープレスISBN 0309- 09640から5（書籍）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ビットの符号化文字集合：コード拡張技術」、2022 ISO規格、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規格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：ラテンアルファベット1号（1998） - 第2部：ラテンアルファベット2号（1999） - パート3：ラテンアルファベット3号（1999） - 第4部：ラテンアルファベット4号（1998） - 第5部：ラテン/キリルアルファベット（1999） - パート6：ラテン/アラビア文字（1999） - パート7：ラテン/ギリシャ語のアルファベット（2003年） - パート8：ラテン/ヘブライ語のアルファベット（1999） - パート9：ラテンアルファベット5号（1999年） - 第10部：ラテンアルファベットの第6号（1998年） - パート11：ラテン語/タイ語のアルファベット（2001 ） - パート13：ラテンアルファベット7号（1998） - 第14部：ラテンアルファベット8号（ケルト）（1998） - 第15部：ラテンアルファベット第9号（1999） - パート16：パート16：ラテンアルファベットなし。10（2001）」、ISO規格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氏、 "もつれたウェブ：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] Klensin、J.、RFC 3467、2003年2月 "ドメインネームシステム（DNS）の役割"。
[RFC3536] Hoffman, P., "Terminology Used in Internationalization in the IETF", RFC 3536, May 2003.
[RFC3536]ホフマン、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]小西、K.、黄、K.、銭、H.、およびY.コ、 "国際化ドメイン名のための共同エンジニアリングチーム（JET）ガイドライン中国語、日本語、韓国語用（IDN）登録と管理"、 RFC 3743、2004年4月。
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004.
[RFC3912] Daigle氏、L.、 "WHOISプロトコル仕様"、RFC 3912、2004年9月。
[RFC3981] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005.
[RFC3981]ニュートン、A.とM.サンス、 "IRIS：インターネットレジストリ情報サービス（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]ニュートン、A.とM.サンス、 "IRIS：ドメインレジストリ（DREG）インターネットレジストリ情報サービス（IRIS）のために入力し、"、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]バーナーズ - リー、T.、フィールディング、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、 "国際化リソース識別Fiers（IRI）"、RFC 3987、2005年1月。
[RFC4185] Klensin, J., "National and Local Characters for DNS Top Level Domain (TLD) Names", RFC 4185, October 2005.
[RFC4185]、RFC 4185、2005年10月Klensin、J.、 "DNSトップレベルドメイン（TLD）名の国と地方の文字"。
[RFC4290] Klensin, J., "Suggested Practices for Registration of Internationalized Domain Names (IDN)", RFC 4290, December 2005.
[RFC4290] Klensin、J.、 "国際化ドメイン名（IDN）の登録のための推奨プラクティス"、RFC 4290、2005年12月。
[RFC4645] Ewell, D., "Initial Language Subtag Registry", RFC 4645, September 2006.
[RFC4645]イーウェル、D.、 "初期言語サブタグレジストリ"、RFC 4645、2006年9月。
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.
[RFC4646]フィリップス、A.とM.デイヴィス、 "言語を識別するためのタグ"、BCP 47、RFC 4646、2006年9月。
[UTR] Unicode Consortium, "Unicode Technical Reports", <http://www.unicode.org/reports/>.
[UTR]はUnicodeコンソーシアム、 "Unicodeの技術レポート"、<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]デイビス、M.とM. Suignard、 "Unicodeのテクニカルレポート＃36：Unicodeのセキュリティの考慮事項"、2005年11月、<http://www.unicode.org/draft/レポート/ 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]デイビス、M.とM. Suignard、 "Unicodeの技術標準＃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.
[ユニコード-PR29]はUnicodeコンソーシアム、 "パブリックレビューの問題＃29：正規化の問題"、UnicodeのPR 29、2004年2月。
[Unicode10] The Unicode Consortium, "The Unicode Standard,
【Unicode10]ユニコードコンソーシアム、「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-ローカライズ]石田、R.とS. Miller氏、 "国際対ローカライズ"、W3C国際/質問/ QA-i18n.txt、2005年12月。
[net-utf8] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", Work in Progress, April 2006.
[ネット-UTF8] Klensin、J.とM. Padlipsky、 "ネットワークインターチェンジのUnicodeフォーマット"、進歩、2006年4月に作業。
Authors' Addresses
著者のアドレス
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョン・C Klensin 1770マサチューセッツアベニュー、＃322ケンブリッジ、MA 02140 USA
Phone: +1 617 491 5735 EMail: john-ietf@jck.com
電話：+1 617 491 5735 Eメール：john-ietf@jck.com
Patrik Faltstrom Cisco Systems
パトリックFaltstromシスコシステムズ
EMail: paf@cisco.com
メールアドレス：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
電話：+46 8 5195 4055 Eメール：ck@nrm.museum
IAB
栄光
EMail: iab@iab.org
メールアドレス：iab@iab.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。