RFC4690 日本語訳
4690 Review and Recommendations for Internationalized Domain Names(IDNs). J. Klensin, P. Faltstrom, C. Karp, IAB. September 2006. (Format: TXT=100929 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Klensinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4690年のP.Faltstromカテゴリ: 情報のシスコシステムズC.カープスウェーデン自然史博物館IAB2006年9月
Review and Recommendations for Internationalized Domain Names (IDNs)
国際化ドメイン名のためのレビューと推薦(IDNs)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
この注意はInternationalized Domain Namesの展開と使用で提起された問題について説明します。 それは登録時点とDNSにおけるそれらの名前の使用のために問題について説明します。 それは、IETFがIETFの外で必要であるいくらかの仕事をまとめて、特定することと同様にそうする際に続かれるようにIDNsと枠組みに関連するRFCsをアップデートするはずであることを勧めます。 特に、いくつかの変化がApplications(IDNA)規格におけるInternationalizing Domain Namesのために調査されて、テーブルを支えることであることは提案します、それらの規格が完成して以来の行われた経験に基づいて。
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. 序論…3 1.1. IDNsの役割とこのドキュメント…3 1.2. このドキュメントとその推薦の状態…4 1.3. IDNA規格…4 1.4. ユニコードドキュメント…5 1.5. 定義…5 1.5.1. 言語…6 1.5.2. スクリプト…6 1.5.3. 多言語…6 1.5.4. ローカライズ…7 1.5.5. 国際化…7
Klensin, et al. Informational [Page 1] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[1ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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
1.6. 声明とガイドライン…7 1.6.1. IESG声明…8 1.6.2. ICANN声明…8 2. 一般的問題と問題…11 2.1. ユーザConceptions、Local文字コード、およびInput問題。11 2.2. 問題に関する例…13 2.2.1. 言語特有のキャラクターマッチング…13 2.2.2. 複数のスクリプト…13 2.2.3. 正常化とキャラクターマッピング…14 2.2.4. 印刷されるところのURLは形成されます…16 2.2.5. 双方向のテキスト…17 2.2.6. Confusableキャラクター問題…17 2.2.7. IESG StatementとIDNA問題…19 3. ユニコードの新しいバージョンにわたります…20 3.1. ユニコードのバージョン…20 3.2. バージョン変化と正常化問題…21 3.2.1. 系列を結合しながら、Unnormalizedしました…21 3.2.2. キャラクターとキャラクターコンポーネントを結合します…22 3.2.3. 正常化はいつ起こりますか? .....................23 4. IDN開発における次のステップへの枠組み…24 4.1. IETFの範囲の中の問題…24 4.1.1. IDNAのレビュー…24 4.1.2. 非DNSと上のDNS国際化にアプローチします…25 4.1.3. 安全保障問題、証明書など ................25 4.1.4. 変化と政策的含意について議定書の中で述べてください…27 4.1.5. Eメールアドレスの地方の部分の非米国のASCII…27 4.1.6. IETFにおけるユニコード文字コードの使用…27 4.2. ICANNの範囲の中に下がる問題…28 4.2.1. 解決について議論してください…28 4.2.2. 登録の方針…28 4.2.3. DNSのトップレベルにおけるIDNs…29 5. 次のステップのための特定の推薦…29 5.1. 受入れられたキャラクターリストの減少…29 5.1.1. すべての非言語キャラクターの除去…30 5.1.2. 分離を言い表している句読の除去…30 5.2. ユニコードの新しいバージョンに、アップデートします。30 5.3. DNSの役割と用途…31 5.4. 登録名に関するデータベース…31 6. セキュリティ問題…31 7. 承認…32 8. 参照…32 8.1. 標準の参照…32 8.2. 有益な参照…33
Klensin, et al. Informational [Page 2] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[2ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
1. Introduction
1. 序論
1.1. The Role of IDNs and This Document
1.1. IDNsの役割とこのドキュメント
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.
IDNsはさまざまな問題の解決として提唱されましたが、このドキュメントは見解からそれらがDNS名ほど、より多くでなくてまた少なくないと書かれます、伝統的であるとしての使用、安定性、および精度のための「ホスト名」という同じ要件を反映しますが、受入れられたキャラクタのはるかに大きい収集を使用して。 特に、IDNsがすべての言語とスクリプトから等しくアクセスしやすいインターネットに向かってステップを表している間、それらはその非常に広い目的の小さい部分だけをせいぜい記述します。 彼らが、実際にどれくらい重要であると判明するかに関してIDNsが最初に示されたので、論争がありました。 その論争はたぶん続くでしょう。 すべての言語からのアクセシビリティが重要な目的である、したがって、それらがユニコード文字の組に追加されるのでIDNsのための私たちの規格と定義がスムーズに追加スクリプトに適合できるのは、重要です。
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.
ユーザとプロトコルにおける彼らのアプリケーションでIDNsに関するユーティリティを評価しなければなりません: 単にDNSに名前を入れて、それを検索する能力はそういうものとして重要ではありません。 この観点から考えると、彼らが安定して予測できる参照を提供するなら、IDNsは役に立って有効になるでしょう--彼らのASCII対応者よりそれほど安定していなくて、予測できて、安全なノーである参照。
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規格を開発して、その実現と展開の初期の年間の経験は、それらを皆、完全に満たすのが不可能であるかもしれなく、設計上の妥協が実行可能な結果をもたらすのに必要であることを示します、完全に満足できるというわけではなくても。 提起されたその経験と問題に基づいてIDNsの含意、それらを定義する際にされた決定、およびそれらが休息する基礎のいくつかを見直して、変化が必要であるかどうか決定するのが現在、適切であり、そうだとすれば、どれですか?
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がそこにグローバルに共同利用できたままで残るつもりである、 より一般に、缶が変えるIDNs、またはDNSの実現。 例えば、DNSがただ一つの名前しかどんな与えられたノードにもないグローバルな聖職者階級制の管理名前空間であるので、それぞれのドメイン名の唯一無二の1人の所有者がいます。 また、ストリングがDNSで調べられるときだけ、積極的な応答は完全な一致を反映できます: 完全な一致が全くなければ、1つは近いマッチか他の補足的情報のリストではなく、エラー応答を得ます。 検索と大体の突き合わせは可能ではありません。
Klensin, et al. Informational [Page 3] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[3ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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がどんなサーバも応答をキャッシュして、後でグローバルなルックアップが完了している前に質問を満たすのを試みるのにそれらのキャッシュされた応答を使用するかもしれないところの分散システムであるので、あらゆるサーバが同じ合っている評価基準を使用しなければなりません。
1.2. Status of This Document and Its Recommendations
1.2. このドキュメントとその推薦の状態
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.
このドキュメントは、前方にIDN問題と経路を批評することで告発された専門委員会から、IETF見解からIDN風景を見直して、入力に部分的に基づくIABの推薦と結論を提示します(セクション7を見てください)。 推薦はIETFへのアドバイスであるか調査されるべき話題と行動を取るために、他のボディーへのいくつかの場合では、彼らの試験の後のそれらのボディーであるなら、それらの動きが適切であると考えてください。
1.3. The IDNA Standard
1.3. IDNA規格
During 2002, the IETF completed the following RFCs that, together, define IDNs:
2002の間、IETFはIDNsを一緒に定義する以下のRFCsを完成しました:
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]のRFC3454準備。 Stringprepは、ユニコードストリングを取って、正準な形式にそれを変換するための一般的なメカニズムです。 Stringprep自身はただ規則、テーブル、および操作の収集です。 それを使用するどんなプロトコルやアルゴリズムも、「Stringprepプロフィール」、それらの規則のどれが適用されているかを指定するもの、その方法を定義して、どの特性でそうしなければならないか。
RFC 3490 Internationalizing Domain Names in Applications (IDNA)
[RFC3490].
IDNA is the base specification in this group. It specifies that
Nameprep is used as the Stringprep profile for domain names, and
that Punycode is the relevant encoding mechanism for use in
generating an ASCII-compatible ("ACE") form of the name. It also
applies some additional conversions and character filtering that
are not part of Nameprep.
アプリケーション(IDNA)[RFC3490]におけるドメイン名を国際的にするRFC3490。 IDNAはこのグループの基礎仕様です。 Nameprepがドメイン名にStringprepプロフィールとして使用されて、Punycodeが(「ACE」)という名前のASCIIコンパチブルフォームを作ることにおける使用のための関連コード化メカニズムであることは指定します。 また、それは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.
RFC3491Nameprep: 国際化ドメイン名(IDN)[RFC3491]のためのStringprepプロフィール。 NameprepはIDNsの特定の需要を満たすように設計されていて、特に上側として伝統的に知られていることを支持するスクリプトと小文字の形式の同じ手紙における、ケースの折りたたみのサポートにそうします。 Nameprepアルゴリズムの結果がユニコードキャラクターセットの正常にされてケースによって折り重ねられた部分集合を含むストリングであるので、その大文字と小文字を区別しない比較をすることができます。
Klensin, et al. Informational [Page 4] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[4ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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".
RFC3492Punycode: Applications(IDNA)[RFC3492]のInternationalized Domain Namesのためにユニコードをコード化するBootstring。 Punycodeは、ASCII文字でユニコードストリングをコード化するためのメカニズムです。 使用されるキャラクタは"LDH"として時々知られている同じDNSのホスト名定義で許容されているキャラクタの部分集合と、すなわち、「手紙、ケタ、およびハイフン」キャラクタです。
1.4. Unicode Documents
1.4. ユニコードドキュメント
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).
ユニコードはIDNsにベース、および定義、文字の組として使用されます。 ユニコードは、ISO/IEC10646[ISO10646]を創設するためにユニコードConsortiumによって標準化されて、ISOと同期します。 より早く言及されたRFCsが作成されたとき、バージョン3.2にはユニコードがありました。 IDNAが採用されたとき、後で説明された理由に、ユニコードの特定の、そして、次に、現在のバージョンを選ぶのが必要でした。 その結果、RFCsは明らかにユニコードバージョン3.2[Unicode32]に依存しています。 現在のところ、より新しいユニコードバージョンを使用するようにIDNA RFCsを変更するためのどんな確立したメカニズムもありません(セクション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.
ユニコードは非常に大きくて複雑な文字の組です。 (用語の「文字の組」か"charset"がIETFに独特の、そして、他のボディーで用法と同じでないかもしれない道と関係で使用されます。) ユニコードStandardと関連するドキュメントは、ユニコードTechnical Committee(UTC)(ユニコードConsortiumの委員会のひとり)によって作成されて、維持されます。
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.
Consortiumは、1991年に最初にユニコードStandard[Unicode10]を発行して、そのオリジナルの仕事に基づく規格を開発し続けています。 ユニコードは国際標準化機構に関連して開発されます、そして、それはISO/IEC10646とキャラクタレパートリーを共有します。 ユニコードとISO/IEC10646はキャラクタencodingsとして同等に機能しますが、ユニコードStandardはimplementersにおける多くの詳しい情報を含んでいます、コード化、照合、および表現をbitwiseするような話題を徹底的にカバーしていて。 ユニコードStandardは双方向のテキストを支持するのに必要であるものを含むキャラクタの特性の多数を数え上げます。 ユニコードConsortiumとISO規格はわずかに異なった用語を使用します。
1.5. Definitions
1.5. 定義
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.
より一般に、次の用語とそれらの意味はこのドキュメントの残りを理解していることと、そして、IDNsの議論に重要です。 [RFC3536]からこれらの用語を得ます。(それは、いくつかのそれらの追加議論を含みます)。
Klensin, et al. Informational [Page 5] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[5ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
1.5.1. Language
1.5.1. 言語
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].
いくつかの言語には、書かれて話されたフォームの間の密接な関係がありますが、他のものは、よりゆるい関係を持っています。 RFC3066[RFC3066]はインターネットプロトコルにおける使用にさらに詳細に言語について議論して、言語のための識別子を提供します。 コンピュータ言語はこの定義から明らかに除かれます。 この領域と、スクリプト識別に対する最新のIETF仕事(以下を見る)は[RFC4645]と[RFC4646]に記録されます。
1.5.2. Script
1.5.2. スクリプト
A script is a set of graphic characters used for the written form of one or more languages. This definition is the one used in [ISO10646].
スクリプトは1つ以上の言語の書かれたフォームに使用される1セットの図形文字です。 この定義は[ISO10646]で使用されるものです。
Examples of scripts are Arabic, Cyrillic, Greek, Han (the so-called ideographs used in writing Chinese, Japanese, and Korean), and "Latin". Arabic, Greek, and Latin are, of course, also names of languages.
スクリプトに関する例は、アラビア語と、キリル文字の、そして、ギリシア人のハン(中国語、日本語、および韓国語を書く際に使用されるいわゆる表意文字)と、「ラテン」です。 また、アラビア語、ギリシア語、およびラテン語はもちろん言語の名前です。
Historically, the script that is known as "Latin" in Unicode and most contexts associated with information technology standards is known in the linguistic community as "Roman" or "Roman-derived". The latter terminology distinguishes between the Latin language and the characters used to write it, especially in Republican times, from the much richer and more decorated script derived and adapted from those characters. Since IDNA is defined using Unicode and that standard used the term "LATIN" in its character names and descriptions, that terminology will be used in this document as well except when "Roman-derived" is needed for clarity. However, readers approaching this document from a cultural or linguistic standpoint should be aware that the use of, or references to, "Latin script" in this document refers to the entire collection of Roman-derived characters, not just the characters used to write the Latin language. Some other issues with script identification and relationships with other standards are discussed in [RFC4646].
ユニコードとほとんどの文脈の「ラテン語」が情報技術規格と交際したので、歴史的に、知られているスクリプトは「ローマ」か「ローマに派生する」として言語学の共同体で知られています。 後者の用語はラテン語とそれを書くのに使用されるキャラクタを見分けます、特に共和党の時代に、それらのキャラクタから引き出されて、翻案されたはるかに豊かでさらに飾り付けををされたスクリプトから。 IDNAがユニコードを使用することで定義されて、その規格がそのキャラクタ名と記述に「ラテン語」という用語を使用したので、本書ではまた、いつを除いて、「ローマに派生していた」状態で用語を使用するかが明快に必要です。 しかしながら、文化的であるか言語学の見地からこのドキュメントにアプローチする読者が意識しているべきである、それ、使用、参照、「ラテン語のスクリプト」は本書ではローマに派生しているキャラクタ(まさしくラテン語を書くのに使用されないいずれのキャラクタも)の全体の収集を示します。 [RFC4646]でスクリプト識別のある他の問題と他の規格との関係について議論します。
1.5.3. Multilingual
1.5.3. 多数の言語で表現にされる
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.
「多言語」という用語は、多くの広く異なった定義を持って、その結果、規格における使用のために推薦されません。 定義のいくつかが国際的な人物を扱う能力に関連します。 他の定義は複数のcharsetsを扱う能力に関連します。 そして、それでも、他のものは複数の言語を扱う能力に関連します。
Klensin, et al. Informational [Page 6] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[6ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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関連の用途のために非難されて、そうでなければ、本書では現れませんでしたが、用語がIDNsのいくつかの議論にまだ広く使用されているので、ここでの議論は適切に見えました。
1.5.4. Localization
1.5.4. ローカライズ
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-ローカライズ]。
1.5.5. Internationalization
1.5.5. 国際化
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テキストの取り扱いを加えるか、または改良すると説明するのに使用されます。 他のボディーはしばしば意味におけるわずかな変更で他の方法で用語を使用します。 「国際化」という用語はしばしば簡略化された"i18n"(そして、"l10n"としてのローカライズ)です。
Many protocols that handle text only handle the characters associated with one script (often, a subset of the characters used in writing English text), or leave the question of what character set is used up to local guesswork (which leads to interoperability problems). Adding non-ASCII text to such a protocol allows the protocol to handle more scripts, with the intention of being able to include all of the scripts that are useful in the world. It is naive (sic) to believe that all English words can be written in ASCII, various mythologies notwithstanding.
テキストを扱う多くのプロトコルが、1つのスクリプト(しばしば、キャラクタの部分集合は文章で英文を使用した)に関連しているキャラクタを扱うか、またはどんな文字の組がローカルの当て推量(相互運用性問題を引き起こす)まで使用されるかに関する質問を残すだけです。 プロトコルはそのようなプロトコルへの非ASCIIテキストの付加で、より多くのスクリプトを扱うことができます、できるのが世界で役に立つスクリプトのすべてを含むという意志で。 様々な神話にもかかわらず、すべての英単語をASCIIに書くことができると信じるのは、(原文のまま)ですナイーブな。
1.6. Statements and Guidelines
1.6. 声明とガイドライン
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
IDNA RFCsが発行されたとき、IESGとICANNは展開と今後の活動を誘導することを意図した声明を出しました。 最近の数カ月、ICANNは声明をアップデートしています、そして、また、他のものは貢献をしました。 DNSへの適用されるとしての国際化問題の理解の品質が発展したことに注意する価値があります。
Klensin, et al. Informational [Page 7] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[7ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
considerably over the last few years. Organizations that took specific positions a year or more ago might not make exactly the same statements today.
かなり、ここ数年間にわたって。 1年以上前に特定の立場を取った組織は今日、まさに同じ声明を出さないかもしれません。
1.6.1. IESG Statement
1.6.1. IESG声明
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.
声明はこれより長いのですが、これらのパラグラフは重要なものです。 声明の残りは説明と例から成ります。
1.6.2. ICANN Statements
1.6.2. ICANN声明
1.6.2.1. Initial ICANN Guidelines
1.6.2.1. 初期のICANNガイドライン
Soon after the IDNA standards were adopted, ICANN produced an initial version of its "IDN Guidelines" [ICANNv1]. This document was intended to serve two purposes. The first was to provide a basis for releasing the Generic Top Level Domain (gTLD) registries that had been established by ICANN from a contractual restriction on the registration of labels containing hyphens in the third and fourth positions. The second was to provide a general framework for the development of registry policies for the implementation of IDNs.
IDNA規格が採用されたすぐ後に、ICANNは「IDNガイドライン」[ICANNv1]の初期のバージョンを生産しました。 このドキュメントが2つの目的に役立つことを意図しました。 1番目は3番目にハイフンを含むラベルと4番目の位置の登録のときにICANNによって契約上の制限から確立されたGeneric Top Level Domain(gTLD)登録をリリースする基礎を提供することでした。 2番目はIDNsの実現のための登録方針の開発に一般的な枠組みを提供することでした。
One of the key components of this framework prescribed strict compliance with RFCs 3490, 3491, and 3492. With the framework, ICANN specified that IDNA was to be the sole mechanism to be used in the DNS to represent IDNs.
この枠組みの主要な成分の1つはRFCs3490、3491、および3492への徹底順守を定めました。 枠組みで、ICANNは、IDNsを表すのにDNSで使用されるためにIDNAによる唯一のメカニズムであると指定しました。
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
IDNsでの包含に手があいているキャラクタにおける制限は2つのメカニズムによって強制されました。1番目が、「特定のための許されている包含ベースのアプローチ(登録によって明らかに受入れられないコード・ポイントが禁止されていることを意味する)」を必要とすることによって、ありました。
Klensin, et al. Informational [Page 8] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[8ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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:
「コードは完全なユニコードレパートリーから指します。」 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."
「(b) IDN規格、(a) それぞれの登録された国際化ドメイン名を1つの言語に関連づけるか、または設定されて、登録がそうする言語の最上位のドメインを実行する際に、言語特有の登録と記録されて、公的に利用可能な管理規則を使ってください」; そして、(c) 適切なテーブルであるときにだけ、登録がそれに登録を見つけて、与えられた言語のための規則がキャラクタ異形テーブルからためになって、登録証明書を許容する管理にその言語を見つけるところで言語の同等なキャラクタ異形があるすべてのドメイン名の予約が登録されたドメイン名と交際したので、そのようなものは利用可能です。 ... 「IDN規格を実行する際に、最上位のドメイン登録は少なくとも初めは、どんな与えられたドメインラベル(セカンドレベルドメイン名などの)も1言語かセットの言語だけに関連しているキャラクタに制限するべきです。」
It was left to each TLD registry to define the character repertoire it would associate with any given language. This led to significant variation from registry to registry, with further heterogeneity in the underlying language-based IDN policies. If the guidelines had made provision for IDN policies also being based on script, a substantial amount of the resulting ambiguity could have been avoided. However, they did not, and the sequence of events leading to the present review of IDNA was thus triggered.
それが言語を与えるいずれにも関連づけるキャラクタレパートリーを定義するのがそれぞれのTLD登録に残されました。 これはさらなる異種性で基本的な言語ベースのIDN方針で重要な登録から登録までの変化に通じました。 ガイドラインがまた、スクリプトに基づいているIDN方針に備えたなら、結果として起こるあいまいさのかなりの量を避けることができたでしょうに。 しかしながら、引き起こしませんでした、そして、IDNAの現在のレビューに通じる出来事の系列はこのようにして引き起こされました。
1.6.2.2. ICANN Version 2 Guidelines
1.6.2.2. ICANNバージョン2ガイドライン
One of the responses of the TLD registries to what was widely perceived as a crisis situation was to invoke the mechanism described in the initial guidelines: "As the deployment of IDNs proceeds, ICANN and the IDN registries will review these Guidelines at regular intervals, and revise them as necessary based on experience."
危機的状況として広く知覚されたことへのTLD登録の応答の1つは初期のガイドラインで説明されたメカニズムを呼び出すことでした: 「IDNsの展開が続くとき、ICANNとIDN登録は、一定の間隔を置いてこれらのGuidelinesを見直して、経験に基づいて必要に応じて彼らを改訂するでしょう。」
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.
重要な要件はIDNsのためにスクリプトベースの方針を可能にするガイドラインの変更でした。 さらなる関心はTLD登録方針の伝播のために現実的に実行可能なメカニズムの必要性に関してそれらの名前木の下のレベルに述べられました。 プロトコルレベルにおける規制の予期された増加に加えて、1つの明白な追加アプローチはIETFの標準の枠組みにおける明確な状態を持っていた器具自体にガイドラインを置き換えるだろうことです。 したがって、BCPは、より長い期間の努力のための適切な焦点が見られました。 ガイドラインへの増加の変更で最も多くの差し迫った問題がその間対処されたでしょうが、その増加の変更がいったん完全になると、必要性は全くそれらのガイドラインのさらなる詳細な開発に関して認められませんでした。
Klensin, et al. Informational [Page 9] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[9ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
The outcome of this action was a version 2.0 of the guidelines [ICANNv2], which was endorsed by the ICANN Board on November 8, 2005 for a period of nine months. The Board stated further that it "tasks the IDN working group to continue its important work and return to the board with specific IDN improvement recommendations before the ICANN Meeting in Morocco" and "supports the working group's continued action to reframe the guidelines completely in a manner appropriate for further development as a Best Current Practices (BCP) document, to ensure that the Guideline directions will be used deeper into the DNS hierarchy and within TLD's where ICANN has a lesser policy relationship."
この動作の結果はガイドライン[ICANNv2]のバージョン2.0でした。(ガイドラインはしばらく、2005年11月8日に9カ月についてICANN Boardによって是認されました)。 そしてBoardが、それが「モロッコで重要な仕事を続けて、特定のIDN改良推薦はICANN Meetingの前にある状態で板に戻るためにIDNワーキンググループに仕事を課す」とさらに述べた; 「Best Current Practices(BCP)ドキュメント、それを確実にするのに、Guideline指示がDNS階層構造により深く使用されて、TLDがICANNが、より少ない方針関係を持っているところに中にあるので、完全にさらなる開発に、適切な方法によるガイドラインを再構成するためにワーキンググループの継続的な動作を支持します。」
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."
「単一のラベルのすべてのコード・ポイントがユニコードStandard Annex#24で決定するのと同じスクリプトから抜粋されるでしょう」 http://www.unicode.org/reports/tr24 のスクリプト名。 言語において、これへの例外は複数のスクリプトの混ぜ合わせられた使用を必要とする確立した綴り字法とコンベンションと共に許されています。 「そのような場合、対応する方針と指標表が明確に定義されないと、異なったスクリプトからの目視により「混乱させ-可能」なキャラクタは許されているcodepointsの1セットで共存できないでしょう。」
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) または、「シンボル図面キャラクタ(ユニコードBox Drawingブロックのそれらとしての)、(b)シンボル、およびどちらもでないアイコンを裏打ちしてください、英数字、表意文字の言語キャラクタ、(d) 装飾活字、安定している機能がある要素について議定書の中で述べるのと同じくらい印刷の、そして、同じくらいpictographicな(c)キャラクタ、句読点が唯一以前はよく文の構造を示していた、」
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,
2005年11月の意志は、お勧めの主要な改正がモロッコ(6月の2006下旬の)で会う前にもかかわらず、増加して照合されるべき変化のためにICANN Boardにつけられて、ガイドラインの当座のバージョン2.nリリースに載ることでした。 IABの理解はそれですが、これがあるいくらかの進歩がありました。
Klensin, et al. Informational [Page 10] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[10ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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.
次にIDNsに関連する他の問題がガイドラインの、より大規模な処理にささげられることを意図したエネルギーの多くを紛らしました。
2. General Problems and Issues
2. 一般的問題と問題
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.
このセクションはいくつかのタイプの問題と問題を織り合わせます。 各小区分はしたがって、修正を必要として、「IDNs」の問題か問題であると知覚される何かについて概説します。 IDNAプロトコルかテーブルの要素への変更を行うことによって、これらの問題のいくつかを部分的に少なくとも解決できます。 人々に基本的なDNS構造に矛盾したIDNsへの期待がある限り、他のものは存在するでしょう。 ユーザ、記入者、および政策立案者がしばしばプロトコルと他の専門的な問題ではなく、起こるべきであるか、または起こるべきであるそれらが信じていることと実際に起こることの違いだけを理解しているので、この全体の範囲の問題を特定するのは重要です。 それらの違いが存在している限り、機能性の要求かIDNsのための政策変更があるでしょう。 もちろん、これらの要求のいくつかが他のものほど現実的にならないでしょうが、現実的な他のものと同じ文脈で理解されるべきです。
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がユニコード3.2に結ばれたままで残っているか、または新しいユニコードバージョンへの移動が熟考されることにかかわらず提起されて、本書では議論する問題の大部分は存在しています。 移行パスが、新たにコード化されたスクリプトに対応して、言語とスクリプトの最大数がドメイン名で表されることを許可するのに必要です。 しかしながら、移動問題が特にただ一つのユニコードバージョンかバージョン3.2にかかわるものから主に別々であるので、このセクションとセクション3にそれらを切り離してあります。
2.1. User Conceptions, Local Character Sets, and Input issues
2.1. ユーザConceptions、Local文字コード、およびInput問題
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のラベルはただ本来特定の言語につながれないキャラクタのストリングです。 本当に、Introductionで簡潔に言及されるように、どんな言語で辞書的に単語であることができないだろうDNSラベルも、可能であって、一般的です。 オールASCIIホスト名ラベルが制限されたより彼らを制限するIDNsにプロトコル制限を課す理由は全くあるように見えません。 その理由で、それらの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
通常、人々は「単語」それらが、いつものを考えて、他のものに、「木、レストラン」と彼らも、例えば、「オレンジ」を考えて欲しいか、そして、「頂上Inc」を使用します。 ワーズは、通常、英語などの特定の言語にはあるか、またはスウェーデンです。 文字列ラベル
Klensin, et al. Informational [Page 11] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[11ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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.
ラベル(または、単語)を書くか、またはタイプするとき、スクリプトを選択しなければなりません、そして、そのスクリプトで使用にcharsetを選ばなければなりません。 charsetのこの選択は単語かドキュメントあたり1個のベースにおけるユーザのコントロールの下における通常、であるハードウェアの現場の声装置かキーボードか端末のドライバーかオペレーティングシステムでされた他の決定かデザイナーと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:
そのcharset、または関連オペレーティングシステムかアプリケーション・ソフトによって使用される地方のcharsetがユニコードでないなら、ユニコードを生産するためにさらなる変換を実行しなければなりません。 どれくらいの頻度でこれが問題であるかはハードウェア、オペレーティングシステム、およびアプリケーションのためにユニコードが固有の文字の組としてどれくらい広く配備されるかに関する見積りによります。 それらの見積りがはなはだしく異なりますが、それが注意されるべきである、他の困難の中のそれ、:
o ISO 8859 versions [ISO.8859.2003] and even national variations of
ISO 646 [ISO.646.1991], are still widely used in parts of Europe;
o ISO8859バージョン、[ISO、.8859、.2003、]、ISO646の国家の変化、さえ[ISO、.646、.1991、]、ヨーロッパの地域で広く使用されたスチール写真はそうです。
o code-table switching methods, typically based on the techniques of
ISO 2022 [ISO.2022.1986] are still in general use in many parts of
the world, especially in Japan with Shift-JIS and its variations;
and
o 通常ISO2022のテクニックに基づいたコードテーブル切り換え方法、[ISO、.2022、.1986、]、一般に、スチール写真は、世界の多くの地域で、そして、特にShift-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」規格のさらに1つ以上を使用する傾向があります。
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.
さらに、すべてではなく、同様に、charsetsは彼らの性格を定義します、そして、記号化体系をすべて先在させないのは変化なしでユニコードに組み入れられました。 時々地方の区別は作られていて、そのユニコードがどんな造もしないか、逆もまた同様ですということでした。 その結果、他のシステムからユニコードまでの変換は潜在的に情報を失うかもしれません。
The Unicode string that results from this processing -- processing that is trivial in a Unicode-native system but that may be significant in others -- is then used as input to IDNA.
そして、この処理から生じるユニコードストリング(固有のユニコードシステムで些細な、しかし、他のもので重要であるかもしれない処理)はIDNAに入力されるように使用されます。
Klensin, et al. Informational [Page 12] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[12ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
2.2. Examples of Issues
2.2. 問題に関する例
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.
以下の議論の多くがユニコードコーディングと関連規則で述べられていますが、IABは、問題のいくつかがそういうものとして用意ができているユニコード文字ではなく、実際に分配された合っているシステムがどのようにほんとうは作動するか、そして、DNSを特徴付ける記憶されたデータの分配された遅れた検索がマッピングアルゴリズムでどんな含意に関して作動したかに関するものであると信じています。
2.2.1. Language-Specific Character Matching
2.2.1. 言語特有のキャラクターマッチング
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+00F8(LATIN SMALL LETTER O WITH STROKE)と共に2番目の音節でつづられます、それがU+00F6(LATIN SMALL LETTER O WITH DIAERESIS)と共にスウェーデン語でつづられますが。 スウェーデン語、デンマーク語、またはノルウェー語を話しているほとんどの人々が、彼らが同等であるとたぶん考えている間、ユニコードStandardとそのAnnexesによると、それらのキャラクタは同等物として扱われません。
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]で紹介された「異形」モデルは登録によって使用されて、両方の名前があるどちらかを確実にすることによって与えられたドメインに同じパーティーに登録されていた状態で可能な混乱の最も悪い結果を防ぐことができるか、またはそれらの1つは完全に禁止されています。
2.2.2. Multiple Scripts
2.2.2. 複数のスクリプト
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
言語が複数のスクリプトを使用することで言い表すことができる世界にあります。 例えば、キリル文字の、または、ラテン語(セクション1.5.2を見る)のキャラクタにいくつかの東欧とセントラルのアジアの言語を表すことができますか、またはアラビアの、または、ラテン語のキャラクタにいくつかのアフリカの、そして、東南アジアの言語を表すことができます。 3つの異なったスクリプトでいくつかの言語を書くことさえできます。 他の場合では、言語はスクリプト(例えば、Kanji、Kana、日本語;ハングルのためのローマ字、および韓国語のためのHanji)の組み合わせで通常書かれています。 これのために、同じ言語で、異なった方法で同じ言葉を表すことができます。 いくつかの言語において、通常、ただ一つのスクリプトだけが一語を書くのに使用されます。 他のものにとって、複雑なスクリプトが必要です。 そして、それでも、他のもののために、「単語」のために通常それをしませんが、特殊事情はラベルで混合スクリプトを決めるかもしれません。 IDN目的のために、これらの変化で「スクリプト」の定義は非常に敏感になります、特にICANNが、現在それが第一の基礎として使用されることを勧めているので
Klensin, et al. Informational [Page 13] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[13ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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".
登録方針。 どんなに不可欠であっても、混ぜられたスクリプトラベルを禁止することになっているかもしれないのを追加方針ニュアンスが「複数のスクリプトの混ぜ合わせられた使用を必要とする確立した綴り字法とコンベンションに伴う言語」に必要です。
2.2.3. Normalization and Character Mappings
2.2.3. 正常化とキャラクターマッピング
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".
ユニコードはキャラクタの代理をするための数個の異なったモデルを含んでいます。 "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を見る)における潜在的困難を制限するのは、キャラクタが同じくいくつかの字体の中を見るかもしれないさらに多くの知識を必要としますが、他のもので必要であるというわけではありません。 これらの変化で、1セットの規則をユニコードのすべてに適用して、そうする際に皆と彼らの知覚された需要を満たすのは難しいか不可能になります。 代わりに、キャラクタごとのベースで定義された多少複雑なマッピングテーブルが同じキャラクタの異なった表現をただ一つのフォームに「正常にすること」に必要であるので、マッチングは可能です。
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
Nameprepの基礎となるものなどの正常化規則が適用されていないと、本質的には同じキャラクタはDNSで合わないでしょう、問題の多くの機会を作成して。これらの問題で最も一般的であるのは、一語が結局言葉がユニコードストリングとして表される前に適用された(そして、上では、議論します)処理のため数個の異なったユニコードとして言い表すことができるということです。
Klensin, et al. Informational [Page 14] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[14ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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.
ストリング。 正常化規則が適用されていても、同じであるとユーザによって考えられるいくつかのストリングは同輩を比較しないでしょう。 さらに詳細に本書では、そして、特にセクション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は、ユニコードConsortiumによって定義された正常化アルゴリズムを使用することによってこれらの問題を補うのを試みます。 このアルゴリズムは1人以上のユニコード文字の系列をもう1セットのキャラクタに変えることができます。 1つの例はU+0308(COMBINING DIAERESIS)があとに続いた基本文字U+0061(LATIN SMALL LETTER A)がユニコード文字単一のU+00 4ユーロ(LATIN SMALL LETTER A WITH DIAERESIS)に変わるということです。
This Unicode normalization process accounts only for simple character equivalences, not equivalences that are language or script dependent. For example, as mentioned above, the characters U+00F8 (LATIN SMALL LETTER O WITH STROKE) and U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS) are considered to match in Swedish (and some other languages), but not for all languages that use either of the characters. Having these characters be treated as equivalent in some contexts and not in others requires decisions and mechanisms that, in turn, depend much more on context than either IDNA or the Unicode character-based normalization tables can provide.
このユニコード正常化の過程は言語かスクリプトに依存する等価性ではなく、簡単なキャラクタの等価性だけを説明します。 例えば、キャラクタのU+00F8(LATIN SMALL LETTER O WITH STROKE)とU+00F6(LATIN SMALL LETTER O WITH DIAERESIS)は以上のように、スウェーデン語(そして、ある他の言語)で合っていると考えられますが、キャラクタのどちらかを使用するすべての言語のために考えられるというわけではありません。 他のもので扱われるのではなく、いくつかの文脈でこれらのキャラクタを同等物として扱わせるのがIDNAかユニコードのキャラクタベースの正常化テーブルのどちらかが提供できるより文脈で順番にはるかによる決定とメカニズムを必要とします。
Additional complications occur if the sequences are more complicated or if an attacker is making a deliberate effort to confuse the normalization process. For example, if the sequence U+0069 U+0307 (LATIN SMALL LETTER I followed by COMBINING DOT ABOVE) appears, the Unicode Normalization Method known as NFKC maps it into U+00EF (LATIN SMALL LETTER I WITH DIAERESIS), which is what one would predict. But consider U+0131 U+0308 (LATIN SMALL LETTER DOTLESS I and COMBINING DIAERESIS): is that the same character? Is U+0131 U+0307 U+0307 (dotless i and two combining dot-above characters) equivalent to U+00EF or U+0069, or neither? NFKC does not appear to tell us, nor does the definition of U+0307 appear to tell us what happens when it is combined with other "symbol above" arrangements (unlike some of the "accent above" combining characters, which more or less specify kerning). Similar issues arise when U+00EF is combined with various dot-above combining characters. Each of these questions provides some opportunities for spoofing if different display implementations interpret the rules in different ways.
系列が、より複雑であるか、または攻撃者が正常化の過程を混乱させるための慎重な努力をしているなら、追加めんどうな問題は起こります。 例えば、系列U+0069U+0307(私がCOMBINING DOT ABOVEを続けたLATIN SMALL LETTER)が現れるなら、NFKCとして知られているユニコードNormalization MethodはU+00EF(LATIN SMALL LETTER I WITH DIAERESIS)にそれを写像します。(00EFはものが予測することです)。 しかし、U+0131がU+0308である(LATIN SMALL LETTER DOTLESS IとCOMBINING DIAERESIS)と考えてください: それは同じキャラクタですか? U+0131U+0307U+0307はU+00EF、U+0069、またはどちらもに同等でない(dotless 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
ラテン語のスクリプトを残して、漢字に基づくものを調べるなら、私たちは、また、TraditionalとSimplified中国人の間には、変化のための特定の、そして、lexigraphicな規則の欠如があるのがわかります。 そのような規則、日本語と韓国語の統一があったなら
Klensin, et al. Informational [Page 15] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[15ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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.
中国のものがあるキャラクタは同じキャラクタを日本の、そして、韓国の使用で問題を起こさないでSimplifiedの中国のものにTraditional中国人を正常にするのを不可能にするでしょう。
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.
より一般に、マッピングは、スウェーデン語が上であることでのケースなどの多くかほとんどの場合では、前構成されたラテン語のスクリプトキャラクタと同等な複数のコード・ポイント落ち着いたキャラクタシーケンスの間のそれらなどのいくつかのマッピングをキャラクタ自体だけに頼っていますが、言語か文化的に依存しています。 異なった言語かスクリプトに異なって適用された異なったcanonicalization規則(正常化かユニコード正常化の代わりに)はあるべきであるか、またはあるかもしれないかに関する議論がありました。 ユニコードにスクリプトを最も含んでいるのが初めは多少完全な状態で既存の規格をコピーすることによって取り入れられたという事実はこれらのアルゴリズムの最適化の上と、そして、下位互換の上に影響力を持っています。 言語を知ってい、言語特有の規則を定義できても、言語に関する依存は見えなくなりません。 それらに、テキストを短い系列だけに依存するか、または利用可能なテキスト自体から明白でない意味のある文脈がないなら、Canonicalization操作は可能ではありません。 DNSルックアップと他の多くの操作には、言語を捕らえて、利用する方法かその文脈を提供するのに必要である他の情報がありません。
These variations in languages and in user perceptions of characters make it difficult or impossible to provide uniform algorithms for matching Unicode strings in a way that no end users are ever surprised by the result. For closely-related scripts or characters, surprises may even be frequent. However, because uniform algorithms are required for mappings that are applied when names are looked up in the DNS, the rules that are chosen will always represent an approximation that will be more or less successful in minimizing those user surprises. The current Nameprep and Stringprep algorithms use mapping tables to "normalize" different representations of the same text to a single form so that matching is possible.
言語とキャラクタのユーザ認知のこれらの変化で、エンドユーザが全く今までに結果で驚いていない方法で合っているユニコードストリングに一定のアルゴリズムを供給するのは難しいか不可能になります。 密接に関連のスクリプトかキャラクタにおいて、驚きは頻繁でさえあるかもしれません。 しかしながら、一定のアルゴリズムが名前がDNSで調べられるとき適用されたマッピングに必要であるので、選ばれている規則はいつも多少それらのユーザ驚きを最小にするのに成功するようになる近似を表すでしょう。 そんなに合っていて、同じテキストの異なった表現をただ一つのフォームに「正常にする」ためにテーブルを写像するNameprepとStringprepアルゴリズムが使用する電流は可能です。
More details on the creation of the normalization algorithms can be found in the Unicode Specification and the associated Technical Reports [UTR] and Annexes. Technical Report #36 [UTR36] and [UTR39] are specifically related to the IDN discussion.
ユニコードSpecification、関連Technical Reports[UTR]、およびAnnexesで正常化アルゴリズムの創造に関するその他の詳細を見つけることができます。 技術的なReport#36[UTR36]と[UTR39]は明確にIDN議論に関連します。
2.2.4. URLs in Printed Form
2.2.4. 印刷された用紙のURL
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
URLと他の識別子はそれらを正確にコピーして、「貼ることができる」(少なくとも原則として)電子申込書に現れるだけではなく、ユーザがコンピュータ・システムにそれらを転写しなければならない印刷された用紙にも現れます。 これがしばしば知られている、「側、-、-、-バスで行いてください、問題、」、それの特に問題の多いバージョン
Klensin, et al. Informational [Page 16] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[16ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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.
ユーザが見て、正確にaですぐに一時的な状態でちらっと見られて、形成してください--運転している間に見られた掲示板、aは一時的な乗り物の側面上にサインします、長い間頻繁に繰り返されなかったか、またはスクリーンの上であるテレビ広告ということである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個の実際に異なったユニコードストリングがまさに同じに見えるかもしれないということです、特にそれらを研究する時間が全くないとき。 これが例えば、キリール文字、ギリシア語、およびラテン語のいくつかのglyphsが同じに見えるからである異なったコード・ポイントはユニコードで割り当てられてください、そうした。 よりひどく、人は、合理的にスクリプトとそれがどのくらいのキャラクタが芸術的な字体と活版印刷の結果として合理的に異なることができるかを理解するのにどう使用されるかによく知られる必要があります。 例えば、タイの文字には十分非常に飾られるラテン語のキャラクタのための観察者がキャラクタと共にキャラクタにいくつか容易に混乱させるかもしれないいくつかの字体があります。 大文字しているITCブラックアダー(国際Typeface社の登録商標)とCurlz MTは2つのかなり明白な例です。 何人かのキャラクタのためにタイ語(いくつかの字体による)との類似を作成して、これらの字体はセリフの終わりで輪を使用します。
2.2.5. Bidirectional Text
2.2.5. 双方向のテキスト
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はそうでなければ右から左へのキャラクタの系列であるラベルでのヨーロッパのケタの包含を可能にしますが、他のほとんどの混ぜられて方向上の、そして、(双方向)のストリングを禁止します。 この禁止はいくつかの言語学的にとそうでなければ、文化的に分別があるストリングの拒絶などの他の問題を引き起こす場合があります。 いわゆる双方向の("BIDI")ストリングが発展する取り扱いのためのユニコードとコンベンションとして、IDNAでの禁止は、見直されて、再評価されるべきです。
2.2.6. Confusable Character Issues
2.2.6. Confusableキャラクター問題
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を見てください。
Klensin, et al. Informational [Page 17] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[17ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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?
IDNsは、潜在的に混乱するように十分同じく見る多くの添字を提供することによって複雑にするだけではなく、新しい政策疑問をまた引き起こすことによって、これらの問題を複雑にします。 例えば、言語がそうであることができるなら、2つの異なったスクリプトで書かれていて、ラベルはもう片方のスクリプトで書かれた同じ単語から組み立てられたラベルに同等な1つのスクリプトで書かれた単語から組み立てられますか? 互いに翻訳される2つの異なった言語の単語に、答えは同じですか?
It is now generally understood that, in addition to the collision problems of possibly equivalent words and hence labels, it is possible to utilize characters that look alike -- "confusable" characters -- to spoof names in order to mislead or defraud users. That issue, driven by particular attacks such as those known as "phishing", has introduced stronger requirements for registry efforts to prevent problems than were previously generally recognized as important.
一般に、現在、同じく見るキャラクタ("「混乱させ-可能」"キャラクタ)をパロディー名に利用するのがユーザをミスリードするか、またはだますためにことによると同等な単語としたがって、ラベルの衝突問題に加えて可能であることが理解されています。 「フィッシング詐欺」として知られているものなどの特定の攻撃で追い立てられたその問題は問題を防ぐための登録の努力のための一般に、以前に重要であるとして認識されたより強い要件を導入しました。
One commonly-proposed approach is to have a registry establish restrictions on the characters, and combinations of characters, it will permit to be included in a string to be registered as a label. Taking the Swedish top-level domain, .SE, as an example, a rule might be adopted that the registry "only accepts registrations in Swedish, using Latin script, and because of this, Unicode characters Latin-a, -b, -c,...". But, because there is not a 1:1 mapping between country and language, even a Country Code Top Level Domain (ccTLD) like .SE might have to accept registrations in other languages. For example, there may be a requirement for Finnish (the second most-used language in Sweden). What rules and code points are then defined for Finnish? Does it have special mappings that collide with those that are defined for Swedish? And what does one do in countries that use more than one script? (Finnish and Swedish use the same script.) In all cases, the dispute will ultimately be about whether two strings are the same (or confusingly similar) or not. That, in turn, will generate a discussion of how one defines "what is the same" and "what is similar enough to be a problem".
1つの一般的に提案されたアプローチが登録にキャラクタにおける制限、およびキャラクタの組み合わせを確立させることであり、それはラベルとして登録されるためにストリングに含まれているのを可能にするでしょう。 例としてスウェーデンの最上位のドメイン、.SEをみなして、登録が「スウェーデン語、使用のラテン語のスクリプト、およびユニコード文字ラテン語-a、-b、これによる-cで登録証明書を受け入れるだけである」という規則は採用されるかもしれません… しかし、国と言語の間には、1:1マッピングがないので、.SEのようなCountry Code Top Level Domain(ccTLD)さえ他の言語における登録証明書を受け入れなければならないかもしれません。 例えば、フィンランド語のための要件があるかもしれません(2番目はスウェーデンの言語を最も使用しました)。 そして、何の規則とコード・ポイントがフィンランド語のために定義されますか? それには、スウェーデン語のために定義されるものと衝突する特別なマッピングがありますか? そして、1つは1つ以上のスクリプトを使用する国で何をしますか? (フィンランド語とスウェーデン人は同じスクリプトを使用します。) すべての場合では、論争は結局、2個のストリングが同じ、そして、(紛らわしく同様)であるのに関するものになるでしょう。 それは人が、「何が同じであるか、そして、何が問題である同様ですか」とどう定義するかに関する議論を順番に発生させるでしょう。
Another example arose recently that further illustrates the problem. If one were to use Cyrillic characters to represent the country code for Russia in a localized equivalent to the ccTLD label, the characters themselves would be indistinguishable from the Latin characters "P" and "Y" (in either lower- or uppercase) in most fonts. We presume this might cause some consternation in Paraguay.
さらに問題を例証する別の例が最近、起こりました。 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
アルゴリズムの手段でこれらの困難を完全に決して排除できるというわけではありません。 登録動作でプロトコルとそれらのテーブル、他の部品の適切な調律で問題のいくつかを記述して、混乱と闘争を抑えることができる、まだ他の部品は記述できます。
Klensin, et al. Informational [Page 18] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[18ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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.
2. また、コード・ポイントAに何かを登録するなら、BがAの代わりにある状態で、あなたはドメイン名を得ます。
These approaches are discussed in more detail for "CJK" characters in RFC 3743 [RFC3743] and more generally in RFC 4290 [RFC4290].
RFC3743[RFC3743]と、より一般に、さらに詳細に"CJK"キャラクタのためにRFC4290[RFC4290]でこれらのアプローチについて議論します。
2.2.7. The IESG Statement and IDNA issues
2.2.7. IESG StatementとIDNA問題
The issues above, at least as they were understood at the time, provided the background for the IESG statement included in Section 1.6.1 (which, in turn, was part of the basis for the initial ICANN Guidelines) that a registry should have a policy about the scripts, languages, code points and text directions for which registrations will be accepted. While "accept all" might be an acceptable policy, it implies there is also a dispute resolution process that takes the problems listed above into account. This process must be designed for dealing with all types of potential disputes. For example, issues might arise between registrant and registry over a decision by the registry on collisions with already registered domain names and between registrant and trademark holder (that a domain name infringes on a trademark). In both cases, the parties disagreeing have different views on whether two strings are "equivalent" or not. They may believe that a string that is not allowed to be registered is actually different from one that is already registered. Or they might believe that two strings are the same, even though the rules adopted by the registry to prevent confusion define them as two different domain names.
それらが少なくとも当時、理解されていたとき、上の問題は登録には登録証明書が受け入れられるスクリプト、言語、コード・ポイント、およびテキスト指示に関する方針があるべきであるというセクション1.6.1(順番に初期のICANN Guidelinesの基礎の一部であった)に含まれていたIESG声明にバックグラウンドを提供しました。 「すべてを受け入れてください」は許容できる方針であるかもしれませんが、それは、また、上に記載された問題を考慮に入れる論争の解決の過程があるのを含意します。 すべてのタイプの潜在的論争に対処するようにこの過程を設計しなければなりません。 例えば、問題は既に登録されたドメイン名と記入者と商標所有者との衝突のときに登録のそばに決定の上に記入者と登録の間に起こるかもしれません(そのaドメイン名は商標を侵害します)。 どちらの場合も、パーティーの意見を異にすることで、2個のストリングが「同等であるかどうか」に関する異なった意見があります。 彼らは、登録できないストリングが実際に既に登録されるものと異なっていると信じるかもしれません。 または、彼らは、2個のストリングが同じであると信じるかもしれません、混乱を防ぐために登録によって採用された規則が2つの異なったドメイン名とそれらを定義しますが。
Klensin, et al. Informational [Page 19] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[19ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
3. Migrating to New Versions of Unicode
3. ユニコードの新しいバージョンにわたります。
3.1. Versions of Unicode
3.1. ユニコードのバージョン
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のためにテーブルを支えるのにおいて問題がおよそどれくらい重要であるかはそれよりはるかに典型的なユニコードアプリケーションで微妙な変化に敏感であるように見えます。 これはそうです、他の多くのアプリケーションが少なくとも一部内部的に彼らの表現ではなく、キャラクタの外観だけに敏感であるので。 または、それらのアプリケーションはスクリプト、言語、または文字クラス識別の有効な利点を活用できるかもしれません。 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.
ユニコードConsortiumは可能な変化の安全に、時々キャラクタの組み合わせが実際に評価基準として自然言語に現れるという見込みを使用しました。 しかしながら、上で議論するように、しばしば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.
変化へのこの感度で移動するのはかなり難しくなりました。どんな変化であるならユニコードの1つのバージョンから次までのIDNAによる作られていて、それが厳密に付加的でないということです。 DNSラベルが以前のフォームを使用することで定義されて、前のコンポーネントのどれかが1つのテーブル位置か正常化規則から別の規則まで動かされたなら、コードポイント課題か定義における変化は非常に破壊的であるかもしれません。 ユニコード正常化テーブル、セキュリティ推薦への付属物が疑わしげな名前を避けるか、または特定するための登録証明書とアプリケーション条項に登録制限を設計する際に非常に役立っているとき彼ら、および「混乱させ-可能」キャラクタのテーブルにさえ属すスクリプトか言語とキャラクタのテーブル。 また、皮肉にも、彼らはユニコードの1つのバージョンと次の間でIDNAの感度とその実現をすべてのフォームの変化に広げます。 その結果、彼らで、ユニコードバージョン移動は、より難しくなります。
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つの見解からのただ小さい修正であるように見えていますが、別のものから問題が多いかもしれない変化のタイプに関する例は2004[ユニコード-PR29]との正常化定義への修正でした。 共同体入力は、変化がそうすると示唆しました。
Klensin, et al. Informational [Page 20] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[20ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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.
Stringprep、しかし、バランスで決められたユニコードTechnical Committeeのための変化価値があったという問題を引き起こしてください。 一貫性における困難のために、いくつかの配備された実現が、変化を採用すると決めて、他のものは決めていませんでした、微妙な両立し難いことに通じて。
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.
この状況はジレンマにつながります。 一方では、最近より定義されたキャラクタを除くユニコードバージョンレベルとそれらを使用する人に重要なスクリプトでIDNAを凍らせるのは完全に容認できません。 他方では、そのような移動で既存の登録されたDNS名かそのいくつかの登録された特性を無効にするか、またはその名前のストリングか表現があいまいになるかもしれないなら、ユニコードの1つのバージョンから次まで移動するのは等しく容認できません。 IDNAがユニコードの新しいバージョンに対応するように変更されるつもりであると、IETFは、この領域における適切なバランスを見つけるためにユニコードConsortiumと他のボディーで働く必要があるでしょうが、すべての関係者が非常に難しくて、まずいかもしれない可能な決定について公正に考えて、議論できる場合にだけ、進歩は可能になるでしょう。
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.
また、その対話のコースの間、ユニコード文字の組の応用における安全保障問題があるユニコードConsortium関心の必要性をはっきりさせることができるなら、それは有用であることが分かるでしょうに。 それはここで考えられたほとんどあらゆる見解から不幸でしょう、そのような件がまだ暗号化されていないスクリプトの包含を遅くしたなら。
3.2. Version Changes and Normalization Issues
3.2. バージョン変化と正常化問題
3.2.1. Unnormalized Combining Sequences
3.2.1. 系列を結合しながら、Unnormalizedしました。
One of the advantages of the Unicode model of combining characters, as with previous systems that use character overstriking to accomplish similar purposes, is that it is possible to use sequences of code points to generate characters that are not explicitly provided for in the character set. However, unless sequences that are not explicitly provided for are prohibited by some mechanism (such as the normalization tables), such combining sequences can permit two related dangers.
結合したキャラクタのユニコードモデルの利点の1つは同様の目的を達成するのにキャラクタ「過剰-打撃」を使用する前のシステムのように文字の組で明らかに備えられないキャラクタを発生させるのにコード・ポイントの系列を使用するのが可能であるということです。 しかしながら、何らかのメカニズム(正常化テーブルなどの)によって明らかに備えられない系列が禁止されない場合、系列をそのような結合であるのは2つの関連する危険を可能にすることができます。
o The first is another risk of character confusion, especially if
the relationship of the combining character with characters it
combines with are not precisely defined or unexpected combinations
of combining characters are used. That issue is discussed in more
detail, with an example, in Section 2.2.3.
o 1番目はキャラクタ混乱の別のリスクです、特に、それが結合するキャラクタを伴う結合したキャラクタの関係が正確に定義されないか、または結合したキャラクタの予期していなかった組み合わせが使用されているなら。 さらに詳細にセクション2.2.3における例とその問題について議論します。
o These same issues also inherently impact the stability of the
normalization tables. Suppose that, somewhere in the world, there
is a character that looks like a Roman-derived lowercase "i", but
o また、これらの同じ問題は本来正常化テーブルの安定性に影響を与えます。 しかしローマに派生している小文字の「i」に似ているキャラクタが世界のどこかにあると仮定してください。
Klensin, et al. Informational [Page 21] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[21ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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.
それの上に3つ(1でない2でない)のドットがある状態で。 そして、そのキャラクタのユーザが、伝統的な「i」(U+0069)を結合分切(U+0308)に結合することによってそれを表すのに同意すると仮定してください。 遠くて、いいえ。問題。 しかし、後でこのキャラクタの、より広い必要性は発見されます、そして、シングルがキャラクタを前構成したとき、それがユニコードにコード化されるか、または以上は存在する下でおそらく統治されます、キャラクタを結合する上の3ドットを紹介することによって。 どちらの場合ではも、ユニコードのそのバージョンは「i」-プラスを写像するNFKCで新しくて、承認されたものに分切系列を統治する状態でaを含むべきです。 1つがそうしないなら、起こるべきである正常化が論証上あります。そうしません。 1つがそうするなら、ユニコードの旧バージョンの下で有効であり、正常にされた(思いがけないのですが)ストリングは新しいバージョンの下で非正常にされるようになります。 事実上、合っている規則に基づく変化を導入するでしょう、したがって、それは順番にIDNA比較に影響を与えるでしょう。
It would be useful to consider rules that would avoid or minimize these problems with the understanding that, for reasons given elsewhere, simply minimizing it may not be good enough for IDNA. One partial solution might be to ban any combination of a base character and a combining character that does not appear in a hypothetical "anticipated combinations" table from being used in a domain name label. The next subsection discusses a more radical, if impractical, view of the problem and its solutions.
IDNAに、単にそれを最小にするのがほかの場所にあげられた理由で役に立たないかもしれないという条件によるこれらの問題を避けるか、または最小にする規則が十分であると考えるのは役に立つでしょう。 1つの部分的解決は仮定している「予期された組み合わせ」テーブルに現れない基本文字と結合したキャラクタのどんな組み合わせもドメイン名ラベルで使用されるのを禁止することであるかもしれません。 次の小区分は問題とその解決策の、より急進的で、非実用的な眺めについて議論します。
3.2.2. Combining Characters and Character Components
3.2.2. キャラクターとキャラクターコンポーネントを結合します。
For several reasons, including those discussed above, one thing that increases IDNA complexity and the need for normalization is that combining characters are permitted. Without them, complexity might be reduced enough to permit easier transitions to new versions. The community should consider the impact of entirely prohibiting combining characters from IDNs. While it is almost certainly unfeasible to introduce this change into Unicode as it is now defined and doing so would be extremely disruptive even if it were feasible, the thought experiment can be helpful in understanding both the issues and the implications of the paths not taken. For example, one consequence of this, of course, is that each new language or script, and several existing ones, would require that all of its characters have Unicode assignments to specific, precomposed, code points.
上で議論したものを含むいくつかの理由で、IDNAの複雑さと正常化の必要性を増加させる1つのものは結合したキャラクタが受入れられるということです。 それらがなければ、複雑さは新しいバージョンへの、より簡単な変遷を可能にすることができるくらい減少するかもしれません。 共同体はIDNsからキャラクタを結合するのを完全に禁じる衝撃を考えるべきです。 それが現在定義されるときこの変化をユニコードに取り入れるのがほぼ確実に実行不可能であり、それが可能であったとしてもそうするのが非常に破壊的である間、思考実験は取られなかった経路の両方の問題と含意を理解する際に役立っている場合があります。 例えば、この1つの結果はもちろんそれぞれの新しい言語かスクリプトと、数人の既存の人が、キャラクタには皆、ユニコード課題が特定の、そして、前構成されたコード・ポイントまであるのを必要とするだろうということです。
Note that this is not currently permitted within Unicode for Latin scripts. For non-Latin scripts, some such code points have been defined. The decisions that govern the assignment of such code points are managed entirely within the Unicode Consortium. Were the IETF to choose to reduce IDNA complexity by excluding combining characters, no doubt there would be additional input to the Unicode Consortium from users and proponents of scripts that precomposed
これが現在ラテン語のスクリプトのためにユニコードの中で受入れられないことに注意してください。 非ラテンスクリプトにおいて、そのようないくつかのコード・ポイントが定義されました。 そのようなコード・ポイントの課題を支配する決定は完全にユニコードConsortiumの中で管理されます。 IETFは、キャラクタを結合する追加入力があるだろうという疑問を全く除かないのによるIDNAの複雑さを前構成されたスクリプトのユーザと提案者からユニコードConsortiumに変えるのを選ぶことになっていましたか?
Klensin, et al. Informational [Page 22] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[22ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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.
キャラクタ、必要であってください。 IABとIETFは、これらの方針を改訂するか、またはそうでなければ、正常化の必要性と関連する複雑さを減少させる動作を推薦するようにユニコードConsortiumに強要するのが適切であるかどうか調べるはずです。 しかしながら、私たちはTechnical Committeeが、ユニコードへのすべての可能な前構成されたキャラクタを加えるのが妥当であるか、または可能であると信じていないと言われました。 既存の言語とスクリプト、まして新しいものをサポートするのに必要な前構成されたキャラクタを含むようにユニコードを変更できないと、IDN制限のためのこのオプションは可能にならないでしょう。
3.2.3. When does normalization occur?
3.2.3. 正常化はいつ起こりますか?
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.
多くのユニコードアプリケーションでは、都合のよい解決策は、正常化のスタイルを選んで、格納されるか、または伝えられるすべてのテキストがそのフォームに正常にされるのが必要であることです。 (これは標準のユニコードテキストフォーム[ネットのutf8]におけるIETFでの進行中の仕事で取られたアプローチです。) IDNAはこの要件を課しません。 テキストは、正常にされて登録時にケースによって変えられます、そして、正常にされたバージョンだけがDNSに置かれます。 しかしながら、アプリケーションがネイティブだけを示しているという要件が全くない、(小文字、適切であるところ)、キャラクタはURLなどの議論か参照で正規形と交際しました。 オールASCII DNSラベルに使用されるコンベンションを国際化しているフォームに表するつもりであるなら、そのような要件は無理でしょう、明快か市場識別の複雑なケース参照の使用を禁止するでしょう、したがって。 それは文化的に不適当でさえあるかもしれません。 しかしながら、その制限がなければ、結局DNSでされる比較がいろいろな時間に正常にされたストリングの間と、そして、ユニコードの異なった見解の下にあるでしょう。 それでも、ユニコードの正規形1未満バージョンのストリングが正規形ですべての将来のバージョンの下にあるという主張は十分ではありません。 また、いろいろな時間の正常化は、与えられたソースストリングがいつも同じ目標ストリングに正常にされるのを必要とします、それが正常にされるバージョンにかかわらず。 その評価基準は実現させるのがはるかに難しいです。 上の議論は、それが不可能でさえあるかもしれないと示唆します。
Ignoring these issues with combining characters entirely, as IDNA effectively does today, may leave us "stuck" at Unicode 3.2, leading either to incompatibility differences in applications that otherwise use a modern version of Unicode (while IDN remains at Unicode 3.2) or to painful transitions to new versions. If decisions are made quickly, it may still be possible to make a one-time version upgrade to Version 4.1 or Version 5 of Unicode. However, unless we can impose sufficient global restrictions to permit smooth transitions, upgrading to versions beyond that one are likely to be painful (e.g., potentially requiring changing strings already in the DNS or even a new Punycode prefix) or impossible.
私たちがユニコード3.2で「張り付けられる」状態で、事実上、IDNAが今日するようにキャラクタを完全に結合するこれらの問題を無視するのは残すかもしれません、そうでなければユニコード(IDNはユニコード3.2に残りますが)の現代版を使用するアプリケーション、または、新しいバージョンへの苦痛な変遷への不一致差に通じて。 すぐに決定をするなら、1回のバージョンアップグレードをユニコードのバージョン4.1かバージョン5にするのはまだ可能であるかもしれません。 しかしながら、私たちが可能にすることができるくらいのグローバルな制限を課すことができないなら、スムーズな移行、それを超えたバージョンへのアップグレードは苦痛であるか(例えば、既にDNSの潜在的に釣り銭がいるストリングか新しいPunycode接頭語さえ)、または不可能である傾向があります。
Klensin, et al. Informational [Page 23] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[23ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
4. Framework for Next Steps in IDN Development
4. IDN開発における次のステップへの枠組み
4.1. Issues within the Scope of the IETF
4.1. IETFの範囲の中の問題
4.1.1. Review of IDNA
4.1.1. IDNAのレビュー
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は、このパラグラフの評価基準を満たすために彼らをRFCs3454、3490、3491、そして/または、3492を見直すと考えて、アップデートするはずであるか、または補うはずです(彼らのより多くのひとりは、さらなる研究の後に非実用的であると判明するかもしれません)取って代わるはずであるか。 どんな新しいバージョンや追加仕様もそれらが作成されるときよく見られるユニコードのバージョンに適合させられるべきです。 理想的に、彼らはユニコードの将来のバージョンに順応するのに経路を指定するべきです(以下でのいくつかの提案がこれを容易にするかもしれません)。 また、IETFは、キャラクタのいくつかのグループを写像する重要な利点があるかどうか考えるはずです、字体変化に割り当てられたコード・ポイントなどのように、他のものかそれとも単にそれらのキャラクタを禁止することによってユーザのための明快と分かり易さが役立たれるほうがよいだろうかどうかに。 より一般に、DNSに、現在NameprepのStringprepプロフィールによって呼び出されているユニコード正常化規則が最適であるか、または、より制限している規則、または受入れられたさらに制限しているキャラクタ組み合わせがDNS国際化の、より良いサポートを提供するだろうことにかかわらずIETFが論評する、価値があるように見えます。
The IAB has concluded that there is a consensus within the broader community that lists of code points should be specified by the use of an inclusion-based mechanism (i.e., identifying the characters that are permitted), rather than by excluding a small number of characters from the total Unicode set as Stringprep and Nameprep do today. That conclusion should be reviewed by the IETF community and action taken as appropriate.
IABは、コード・ポイントのリストがStringprepとNameprepが今日するように総ユニコードセットに少ない数のキャラクタを入れないようにすることによってというよりむしろ包含ベースのメカニズム(すなわち、受入れられるキャラクタを特定する)の使用で指定されるべきであるというより広い共同体の中のコンセンサスがあると結論を下しました。 その結論は適宜取られたIETF共同体と行動で見直されるべきです。
We suggest that the individuals doing the review of the code points should work as a specialized design team. To the extent possible, that work should be done jointly by people with experience from the IETF and deep knowledge of the constraints of the DNS and application design, participants from the Unicode Consortium, and other people necessary to be able to reach a generally-accepted result. Because any work along these lines would be modifications and updates to standards-track documents, final review and approval of any proposals would necessarily follow normal IETF processes.
私たちは、コード・ポイントのレビューをしている個人が専門化しているデザインチームとして働くべきであると示唆します。 可能な範囲内で、人々はIETFからの経験とDNSとアプリケーション設計、関係者の規制に関する深い知識で必要なユニコードConsortium、および他の人々から一般に受け入れられた結果に達することができる状態でその仕事を共同でするべきです。 これらの線に沿ったどんな仕事も、標準化過程文書への変更とアップデートでしょう、したがって、どんな提案の最終審査と承認も必ず正常な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
IDNAへの十分極端な変化が新しいPunycode接頭語を必要とすることに注意する価値があります、たぶん登録アレンジメントとアプリケーションの両方の古い接頭語と新しい方の両方の長期のサポートで。 代替手段(ほぼ確実に非実用的である)はある種の「旗の日」でしょう、すなわち、古い規則が同時に皆と新しさによってやめられる日付
Klensin, et al. Informational [Page 24] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[24ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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.
採用されたもの。 しかしながら、予備的な分析は、もしあれば考慮のためにほかの場所で推薦された変化のわずかしか本書ではこのタイプにバージョン変化を要求しないのを示します。 例えば、上で含意されたものなどの追加制限が登録できることに課されると仮定してください。 それらの制限は、以前の規則に従ったならラベルがどう処分されることになっているかに関する政策決定を必要としますが、新しい方に必要でないかもしれません。 しかし、彼らは本来プロトコルか接頭語で釣り銭がいないでしょう。
4.1.2. Non-DNS and Above-DNS Internationalization Approaches
4.1.2. 非DNSとDNSの上の国際化アプローチ
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はルックアップでスクリプト、言語、またはユニコードバージョンの情報を支持できません。 DNSルックアップの本質の結果として、キャラクタとラベルは、合っているか、または合っていません。 近いマッチは単にDNSの可能な概念ではありません。 対照的に、近いマッチングの観測は人間のコミュニケーションと人々によって実行された合っている操作で一般的です、特に彼らが特定のスクリプトか言語文脈を考えているとき。 かなり堅い内部のエイリアシングシステム(CNAMEとDNAMEリソース記録を通した)によってDNSはさらに抑制されます、国際的な命名のいくつかの応用が、より多くの柔軟性を必要とするかもしれませんが。 最終的に、DNS(根の最も近くでレベルで平坦になる実際には傾向)の厳格な階級制と名前が特有になる必要性は、他のものよりいくつかの目的に適して、人々がIDNsを使用したがっているいくつかの目的のための良いマッチでないかもしれません。 ユーザによるDNSの使用を指示するために代替手段を提供する1台以上のシステムは、それぞれのこれらの規制をリラックスするか、または変えることができます。 セクション5.3で、より詳しくかかわった問題のいくつかについて議論します、そして、IETFかIRTFで詳細に様々な考えについて議論しました。 それらの考えの多くがインターネットDraftsか他のドキュメントで説明さえされます。 それらのためのIDNsと期待の経験が蓄積するのに従って、IETFかIRTFが基本的な質問と可能性を再訪させるのはたぶん適切になるでしょう。
4.1.3. Security Issues, Certificates, etc.
4.1.3. 安全保障問題、証明書など
Some characters look like others, often as the result of common origins. The problem with these "confusable" characters, often incorrectly called homographs, has always existed when characters are presented to humans who interpret what is displayed and then make decisions based on what is seen. This is not a problem that exists only when working with internationalized domain names, but they make
しばしば一般的な起源の結果として他のものに似ているキャラクタもあります。 キャラクタが表示されるものを解釈して、次に何が見られるかに基づく決定をする人間に紹介されるとき、これらの"「混乱させ-可能」"キャラクタに関するしばしば不当に同形異義語と呼ばれた問題はいつも存在しました。 これは国際化ドメイン名で働いているときだけ存在する問題ではありませんが、それらは造です。
Klensin, et al. Informational [Page 25] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[25ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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].
問題、 より悪いです。 問題が何であるかを説明する調査の結果はおもしろいかもしれません。 ユニコードTechnical Report#36[UTR36]でこれらの問題の多くが参照されます。
In this and other issues associated with IDNs, precise use of terminology is important lest even more confusion result. The definition of the term 'homograph' that normally appears in dictionaries and linguistic texts states that homographs are different words that are spelled identically (for example, the adjective 'brief' meaning short, the noun 'brief' meaning a document, and the verb 'brief' meaning to inform). By definition, letters in two different alphabets are not the same, regardless of similarities in appearance. This means that sequences of letters from two different scripts that appear to be identical on a computer display cannot be homographs in the accepted sense, even if they are both words in the dictionary of some language. Assuming that there is a language written with Cyrillic script in which "cap" is a word, regardless of what it might mean, it is not a homograph of the Latin-script English word "cap".
IDNsに関連しているこれと他の問題では、さらに多くの混乱が結果として生じるといけないので、用語の正確な使用は重要です。 '同形異義語'という通常、辞書と言語学のテキストに載っている用語の定義は、同形異義語が同様につづられる異なった単語であると述べます(例えば、短いことを意味する形容詞的'要約'、'要約'というドキュメントを意味する名詞、および動詞は知らせるために意味に'事情を知らせます')。 定義上、2つの異なったアルファベットの手紙は外観における類似性にかかわらず同じではありません。 これは、コンピュータのディスプレイのときに同じであるように見える2つの異なったスクリプトからの手紙の系列が受け入れられた意味で同形異義語であるはずがないことを意味します、それらが何らかの言語の辞書の両方の単語であっても。 キリル文字のスクリプトで書かれた言語がどの「キャップ」であるかと仮定するのは、単語です、それが意味するかもしれないことにかかわらずそれがラテン語のスクリプト英単語の「キャップ」の同形異義語ではありません。
When the security implications of visually confusable characters were brought to the forefront in 2005, the term homograph was used to designate any instance of graphic similarity, even when comparing individual characters. This usage is not only incorrect, but risks introducing even more confusion and hence should be avoided. The current preferred terminology is to describe these similar-looking characters as "confusable characters" or even "confusables".
目視により「混乱させ-可能」なキャラクタのセキュリティ含意が2005年に最先端にもたらされたとき、個性を比較さえするとき、用語同形異義語は、グラフィック類似性のどんな例も指定するのに使用されました。 この用法が不正確であるだけではありませんが、危険は、さらに多くの混乱を導入して、したがって、避けられるべきです。 現在の都合のよい用語は「「混乱させ-可能」キャラクタ」か「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?
多くの人々が、「混乱させ-可能」キャラクタが記述しなければならない問題であると示唆しました、少なくとも一部、直接アプリケーション・ソフトのユーザインタフェースで。 それはほぼ確実に完全解の一部であるべきですが、アプローチが自己でそれを作成するのが困難をセットしました。 例えば、システムの間、または、同じシステムにおけるアプリケーションの間でさえ切り替わるユーザは異なったタイプの振舞いと異なったレベルの保護で驚くかもしれません。 さらに、エンドユーザのための安全なセットアップがどのように設計されるべきであるかは、不明瞭です。 今日、南京錠はウェブブラウザでは、エンドユーザのために何らかのレベルのセキュリティについて説明する伝統的な方法です。 この2進のシグナリングは十分ですか? 何か「混乱させ-可能」キャラクタを含む表示されたストリングのためのリスクと南京錠か同様のシグナリングとのユーザへの関係があるべきですか?
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
多くのウェブブラウザがコンベンションを採用しました、潜在的に「混乱させ-可能」ラベルの登録のために安全な習慣を開くと考えられる最上位のドメインに関するサブドメインへのネイティブのキャラクタの表示を制限する"whitelist"か同様のテクニックに基づいて。 Punycodeとして他のドメインのIDNsを表示します。 これらのテクニックは方針の違いに十分敏感でないかもしれません。
Klensin, et al. Informational [Page 26] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[26ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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?
最上位のドメインであり、したがって、自己のサブドメインでありそれらは明確に役立っている間、適切でないかもしれません。 「混乱させ-可能」キャラクタに対処する他の方法は可能ですか? 登録証明書を混乱させるのを避けることに関する方針を特定して、記載する他の方法は、可能であって、役立っているでしょうか?
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.
ユーザインタフェースのためのガイドラインを確立する際に、より連携している努力を見るのはおもしろいでしょう。 他に何も、現在のwhitelistsがブラウザ特有であるか、そして、両方が異なることができます、そして、してください、そして、実現の間で異なってください。
4.1.4. Protocol Changes and Policy Implications
4.1.4. プロトコル変化と政策的含意
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、およびInで慎重に特定の状態でそれらの衝撃を評価しなければならないということであるなら、議定書を作ってください。さもないと、既存の名前が、より新しい規則の下で登録されることを許可しない政策変更は慎重に考えられるべきです、ユーザによって見られるように一貫性の重要性に対して、より古い名前を無効にする可能な分裂と問題に対してそれらの重要性のバランスをとっていて。
4.1.5. Non-US-ASCII in Local Part of Email Addresses
4.1.5. Eメールアドレスの地方の部分の非米国のASCII
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がEメールアドレスの地方の部分に関係づけた先に入ることです。 直接地方の部分の上のIDNAを適用するのが可能でないことで、Eメールアドレスの地方の部分には多くの異なった構文と規制がドメイン名ラベルよりあることに注意されるべきです。
4.1.6. Use of the Unicode Character Set in the IETF
4.1.6. IETFにおけるユニコード文字コードの使用
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.
ユニコードと密接に関連のISO10646は世界のキャラクタを皆、含んでいるのを切望する唯一のコード化文字集合です。 そういうものとして、特定のキャラクタコーディング標準かテーブルを特定する必要はなくて、彼らは国際的な人物の使用を可能にします。 文字の組識別を置く場所が全くないので、DNSとの使用には、ただ一つの文字の組のための要件は特に重要です。 [RFC2277]で進んでいるIETFプロトコルにベースとしてユニコードを使用するという決定について議論します。 IABはIETFプロトコルにユニコードを使用するという決定を再訪させる理由が全くわかりません。
Klensin, et al. Informational [Page 27] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[27ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
4.2. Issues That Fall within the Purview of ICANN
4.2. ICANNの範囲の中に下がる問題
4.2.1. Dispute Resolution
4.2.1. 論争の解決
IDNs create new types of collisions between trademarks and domain names as well as collisions between domain names. These have impact on dispute resolution processes used by registries and otherwise. It is important that deployment of IDNs evolve in parallel with review and updating of ICANN or registry-specific dispute resolution processes.
IDNsはドメイン名の間の衝突と同様に商標とドメイン名との新しいタイプの衝突を作成します。 これらで、影響力は論争の解決の過程に登録のそばで中古でそうでなくなります。 IDNsの展開がICANNか登録特有の論争の解決の過程のレビューとアップデートと平行して発展するのは、重要です。
4.2.2. Policy at Registries
4.2.2. 登録の方針
The IAB recommends that registries use an inclusion-based model when choosing what characters to allow at the time of registration. This list of characters is in turn to be a subset of what is allowed according to the updated IDNA standard. The IAB further recommends that registries develop their inclusion-based models in parallel with dispute resolution process at the registry itself.
IABは、登録時点でどんなキャラクタを許容したらよいかを選ぶとき、登録が包含ベースのモデルを使用することを勧めます。 キャラクタのこのリストはアップデートされたIDNA規格に従って順番に、何に関する部分集合であるかが許容されているということです。 IABは、登録が登録自体の論争の解決の過程と平行して彼らの包含ベースのモデルを開発することをさらに勧めます。
Most established policies for dealing with claimed or apparent confusion or conflicts of names are based on dispute resolution. Decisions about legitimate use or registration of one or more names are resolved at or after the time of registration on a case-by-case basis and using policies that are specific to the particular DNS zone or jurisdiction involved. These policies have generally not been extended below the level of the DNS that is directly controlled by the top-level registry.
名前の要求されたか見かけの混乱か闘争に対処するためのほとんどの既定方針が論争の解決に基づいています。 1つ以上の名前の正統の使用か登録に関する決定は、時か登録の時の後にケースバイケースで決議されていて、ゾーンか管轄がかかわった特定のDNSに特定の方針を使用しています。 一般に、これらの方針はトップレベル登録によって直接制御されるDNSのレベルより下であるまで広げられていません。
Because of the number of conflicts that can be generated by the larger number of available and confusable characters in Unicode, we recommend that registration-restriction and dispute resolution policies be developed to constrain registration of IDNs and zone administrators at all levels of the DNS tree. Of course, many of these policies will be less formal than others and there is no requirement for complete global consistency, but the arguments for reduction of confusable characters and other issues in TLDs should apply to all zones below that specific TLD.
ユニコードによる多くの利用可能で「混乱させ-可能」なキャラクタで発生できる闘争の数のために、私たちは、登録制限と論争の解決方針がDNS木のすべてのレベルでIDNsとゾーンの管理者の登録を抑制するために開発されることを勧めます。 もちろん、これらの方針の多くが他のものほど正式にならないでしょう、そして、完全なグローバルな一貫性のための要件が全くありませんが、「混乱させ-可能」キャラクタの減少のための議論とTLDsの他の問題はその特定の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を見てください。
Klensin, et al. Informational [Page 28] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[28ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
4.2.3. IDNs at the Top Level of the DNS
4.2.3. DNSのトップレベルにおけるIDNs
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 TLDs)にもかかわらず、少なくとも3つの非常に別々のもののトップレベルにおけるIDNsには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.
o ルートゾーンにIDNsを入れるつもりであるなら、最初に、これらのTLDsがどう命名されて、代表として派遣されることになっているかに関して決定をしなければなりません。 これらの決定は、伝統的な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 いくつかかすべての既存のTLDsが複数のラベルによって参照をつけられることを許可する議論がありました、おそらく、それらのラベルが異なった言語における、TLDの「名前」の何らかの理解を表していて。 根におけるDNAME記録の使用はその需要を満たすのが適切であるか否かに関係なく、このタイプの実際の別名が既存のドメインに望まれるならもしあればどんな規制が必要であるかと考えますIETFが、必要があるかもしれない、[RFC4185]のものなどの交互のアプローチが適切であるか、またはさらなる代替手段が調査されるべきであることにかかわらず。 しかし、私たちは、ICANNがいずれへの技術的で、操作上の慎重な注意、または他のボディーによって起こされるかもしれないセキュリティ推薦を払うと予想するでしょうが、他のメカニズムどれがもしあれば捜すかにIDNラベルがDNAME記録に関連しているべきであり、どれが正常な代表団によって扱われるべきであるかが記録するか、そして、その決定がDNS根レベル名前空間方針としたがって、滝の1つであるので、おそらく決定をICANNに別名が望ましくて、可能であると考えられる範囲まで、しなければなりません。
o Finally, if IDN labels are to be placed in the root zone, there
are issues associated with how they are to be encoded and
deployed. This area may have implications for work that has been
done, or should be done, in the IETF.
o 最終的に、IDNラベルがルートゾーンに置かれるつもりであるなら、それらがどうコード化されて、配備されることになっているかと関連している問題があります。 この領域を行われた仕事のために意味を持つべきであるかもしれないか、またはIETFでするべきです。
5. Specific Recommendations for Next Steps
5. 次のステップのための特定の推薦
Consistent with the framework described above, the IAB offers these recommendations as steps for further consideration in the identified groups.
上で説明される枠組みと一致していて、IABはさらなる考慮のためにステップとして特定されたグループでこれらの推薦を提供します。
5.1. Reduction of Permitted Character List
5.1. 受入れられたキャラクターリストの減少
Generalize from the original "hostname" rules to non-ASCII characters, permitting as few characters as possible to do that job. This would involve a restrictive model for characters permitted in IDN labels, thus contrasting with the approach used to develop the original IDNA/Nameprep tables. That approach was to include all Unicode characters that there was not a clear reason to exclude.
できるだけわずかなキャラクタしかその仕事をしないことを許可して、オリジナルの「ホスト名」規則から非ASCII文字まで総合してください。 これはIDNラベルで受入れられたキャラクタのために制限しているモデルにかかわるでしょう、その結果、オリジナルのIDNA/Nameprepテーブルを開発するのに使用されるアプローチを対照をなします。 そのアプローチは除く明確な理由ではなく、いたすべてのユニコード文字を含むことでした。
Klensin, et al. Informational [Page 29] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[29ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
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の有効な操作は第一の目標であるべきです。 以下は適切な最小の数のキャラクタを達成するための可能なメカニズムであるとみなされるべきです。
5.1.1. Elimination of All Non-Language Characters
5.1.1. すべての非言語キャラクターの除去
Unicode characters that are not needed to write words or numbers in any of the world's languages should be eliminated from the list of characters that are appropriate in DNS labels. In addition to such characters as those used for box-drawing and sentence punctuation, this should exclude punctuation for word structure and other delimiters. While DNS labels may conveniently be used to express words in many circumstances, the goal is not to express words (or sentences or phrases), but to permit the creation of unambiguous labels with good mnemonic value.
単語か数が世界の言語のいずれでも書かれている必要はないユニコード文字はDNSラベルで適切なキャラクタのリストから根絶されるべきです。 ものが箱図面と文の句読に使用したようなキャラクタに加えて、これは単語構造と他のデリミタのために句読を除くべきです。 DNSラベルが多くの事情の言葉を表すのに便利に使用されているかもしれない間、目標は言葉(または、文か句)を表すのではなく、良い簡略記憶値で明白なラベルの創造を可能にすることです。
5.1.2. Elimination of Word-Separation Punctuation
5.1.2. 分離を言い表している句読の除去
The inclusion of the hyphen in the original hostname rules is a historical artifact from an older, flat, namespace. The community should consider whether it is appropriate to treat it as a simple legacy property of ASCII names and not attempt to generalize it to other scripts. We might, for example, not permit claimed equivalents to the hyphen from other scripts to be used in IDNs. We might even consider banning use of the hyphen itself in non-ASCII strings or, less restrictively, strings that contained non-Latin characters.
オリジナルのホスト名規則でのハイフンの包含は、より古くて、平坦な名前空間からの歴史資産です。 共同体は、ASCII名の簡単な遺産の特性としてそれを扱って、他のスクリプトにそれを一般化するのを試みないのが適切であるかどうか考えるべきです。 例えば、私たちは、他のスクリプトからのハイフンと要求された同等物がIDNsで使用されることを許可しないかもしれません。 私たちは、非ASCIIストリングか非ラテンキャラクタを含んだより制限的でなくストリングにおけるハイフン自体の使用を禁止すると考えさえするかもしれません。
5.2. Updating to New Versions of Unicode
5.2. ユニコードの新しいバージョンへのアップデート
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.
新しいスクリプトが、新しい言語をサポートするためにユニコードに追加され続けているので、IDNAがアップデートを追跡するのは、重要です。 3.2か何らかのただ一つの後のバージョンにそうしませんが、「張り付けられた」ままで残っていると、後のバージョンだけに手があいているキャラクタを必要とする言語の単語から得られるDNSにラベルを含んでいるのは可能でないでしょう。 それらのアップグレードをするのは新しいバージョンがキャラクタについて追加するだけではなくて必要とするのと難しく、同じくらい難しくて、ずっと同じくらい長いのですが、canonicalizationコンベンション、正常化テーブル、または合っている手順に変化します(セクション3.1を見てください)。 何か複雑さを下げて、前進の変遷を簡素化するためにできることは真剣に考えられるべきです。
Klensin, et al. Informational [Page 30] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[30ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
5.3. Role and Uses of the DNS
5.3. DNSの役割と用途
We wish to remind the community that there are boundaries to the appropriate uses of the DNS. It was designed and implemented to serve some specific purposes. There are additional things that it does well, other things that it does badly, and still other things it cannot do at all. No amount of protocol work on IDNs will solve problems with alternate spellings, near-matches, searching for appropriate names, and so on. Registration restrictions and carefully-designed user interfaces can be used to reduce the risk and pain of attempts to do some of these things gone wrong, as well as reducing the risks of various sort of deliberate bad behavior, but, beyond a certain point, use of the DNS simply because it is available becomes a bad tradeoff. The tradeoff may be particularly unfortunate when the use of IDNs does not actually solve the proposed problem. For example, internationalization of DNS names does not eliminate the ASCII protocol identifiers and structure of URIs [RFC3986] and even IRIs [RFC3987]. Hence, DNS internationalization itself, at any or all levels of the DNS tree, is not a sufficient response to the desire of populations to use the Internet entirely in their own languages and the characters associated with those languages.
DNSの適切な用途への境界があるのを共同体に思い出させたいと思います。 それは、いくつかの明確な目標に役立つように設計されて、実行されました。 それが上手にする追加こと、それがひどくする他のこと、およびそれが全くできないまだ他のことがあります。 IDNsへのプロトコル作業のどんな量も交互のスペルに関する問題を解決しないでしょう、マッチの近くで、適切な名前などを捜し求めて。 これらの何らかの様々の危険をちょっと減少させることと同様に失敗しているものに慎重な悪い振舞いをする試みの危険と痛みを減少させるのに登録制限と入念に設計されたユーザインタフェースを使用できますが、単にそれが利用可能であるので、一旦ある線を越えると、DNSの使用は悪い見返りになります。 IDNsの使用が実際に提案された問題を解決しないとき、見返りは特に不運であるかもしれません。 例えば、DNS名の国際化はURI[RFC3986]とIRIs[RFC3987]さえのASCIIプロトコル識別子と構造を排除しません。 したがって、DNS国際化自体はDNS木のいずれかすべてのレベルにおいて人口が完全なそれらの言語に関連しているそれら自身の言語とキャラクタでインターネットを使用する願望への十分な応答ではありません。
These issues are discussed at more length, and alternatives presented, in [RFC2825], [RFC3467], [INDNS], and [DNS-Choices].
より多くの長さでこれらの問題について議論しました、そして、代替手段は[RFC2825]に[RFC3467]、[INDNS]、および[DNS-選択]を提示しました。
5.4. Databases of Registered Names
5.4. 登録名に関するデータベース
In addition to their presence in the DNS, IDNs introduce issues in other contexts in which domain names are used. In particular, the design and content of databases that bind registered names to information about the registrant (commonly described as "whois" databases) will require review and updating. For example, the whois protocol itself [RFC3912] has no standard capability for handling non-ASCII text: one cannot search consistently for, or report, either a DNS name or contact information that is not in ASCII characters. This may provide some additional impetus for a switch to IRIS [RFC3981] [RFC3982] but also raises a number of other questions about what information, and in what languages and scripts, should be included or permitted in such databases.
DNSでのそれらの存在に加えて、IDNsはドメイン名が使用されている他の文脈の問題を紹介します。 特に、記入者(一般的に"whois"データベースとして記述されている)の情報に登録名を縛るデータベースのデザインと内容はレビューとアップデートを必要とするでしょう。 例えば、whoisプロトコル[RFC3912]自体は取り扱いのためのどんな標準の能力も非ASCIIテキストであるのに持っていません: 1つが一貫して探すことができない、または、レポート(ASCII文字にないDNS名か問い合わせ先のどちらか)。 これは、IRIS[RFC3981][RFC3982]へのスイッチに何らかの追加起動力を供給するかもしれませんが、どんな情報の周りと、そして、含まれるべきであるか、またはそのようなデータベースで受入れられたすべての言語とスクリプトで他の多くの疑問をまた引き起こすか。
6. Security Considerations
6. セキュリティ問題
This document is simply a discussion of IDNs and IDNA issues; it raises no new security concerns. However, if some of its recommendations to reduce IDNA complexity, the number of available characters, and various approaches to constraining the use of confusable characters, are followed and prove successful, the risks of name spoofing and other problems may be reduced.
このドキュメントは単にIDNsとIDNA問題の議論です。 それはどんな新しい安全上の配慮も上げません。 しかしながら、IDNAの複雑さを減少させるという推薦のいくつか(手があいているキャラクタの数、および「混乱させ-可能」キャラクタの使用を抑制することへの様々なアプローチ)が続かれていて、成功するなら、名前スプーフィングと他の問題の危険は減少するかもしれません。
Klensin, et al. Informational [Page 31] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[31ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
7. Acknowledgements
7. 承認
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専門委員会のメンバーからのこのレポートへの貢献は感謝して承諾されます。 もちろん、そのグループのいずれのメンバー皆、もこのレポートのあらゆるコメントと提案を是認しません。 特に、このレポートは、全体でユニコードConsortiumの視点かそのConsortiumの仕事の特定の関係者のものを反映すると主張しません。
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、ティナDam、マーク・デイビス、パトリクFaltstrom、スコットHollenbeck、ケーリー・カープ、ジョンKlensin、Gervaseマーカム、デヴィッド・マイヤー、トーマス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.
次に、かなりの特定のテキストの貢献、慎重な後期読書と大規模なコメントのためのマルコス・サンスとポール・ホフマン、および多くの貢献とコメントのためのピートレズニックにとって、感謝は、ともに彼の前のIABサービスに関連したティナによるダムとICANN IDN作業部会に関連している他のものです。 パトリクFaltstromとピートレズニックが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のメンバーは以下の通りでした。 ブライアン大工(レスリーDaigle)のバーナードAboba、Loaアンデション、パトリクFaltstrom、ボブHinden、カーティス・リンクヴィスト、デヴィッド・マイヤー、ペッカNikander、エリック・レスコラ、ピートレズニック、ジョナサン・ローゼンバーグ、およびLixiaチャン。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[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/IEC10646-1:2000、10月2000日
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")",
RFC 3454, December 2002.
[RFC3454] ホフマンとP.とM.Blanchet、「国際化しているストリング("stringprep")の準備」、RFC3454、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)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
Klensin, et al. Informational [Page 32] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[32ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A
Stringprep Profile for Internationalized Domain
Names (IDN)", RFC 3491, March 2003.
[RFC3491] ホフマン、P.、およびM.Blanchet、「Nameprep:」 「国際化ドメイン名(IDN)のためのStringprepプロフィール」、RFC3491、2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of
Unicode for Internationalized Domain Names in
Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]コステロ、A.、「Punycode:」 「Applications(IDNA)のInternationalized Domain Namesのためにユニコードをコード化するBootstring」、RFC3492、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] ユニコード共同体、「ユニコード規格、バージョン3インチ、2000。」 (読書、MA、アディソン-ウエスリー、2000ISBN0-201-61633-5。) バージョン3.2はユニコードStandard Annex#27によって修正されるようにその本との定義から成ります: ( http://www.unicode.org/reports/tr27/ )とユニコード規格別館#28によるユニコード3.1: ユニコード3.2( http://www.unicode.org/reports/tr28/ )。
8.2. Informative References
8.2. 有益な参照
[DNS-Choices] Faltstrom, P., "Design Choices When Expanding
DNS", Work in Progress, June 2005.
「DNSを広げるときのデザイン選択」という[DNS-選択]Faltstrom、P.は進歩、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インチ、2003年3月、<idn-ガイドラインhttp://www.icann.org/一般/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インチ、2005年11月、<idn-ガイドラインhttp://www.icann.org/一般/20sep05.htm>の実現のためのガイドライン。」
[IESG-IDN] Internet Engineering Steering Group (IESG), "IESG
Statement on IDN", IESG Statements IDN Statement,
February 2003, <http://www.ietf.org/IESG/
STATEMENTS/IDNstatement.txt>.
[IESG-IDN]インターネット工学運営グループ(IESG)、「IDNに関するIESG声明、」、IESG声明IDN声明、2003年2月、<http://www.ietf.org/IESG/声明/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]調査評議会、「サイバースペースにおける道標:」 「ドメインネームシステムとインターネットNavigation」、National Academy Press ISBN0309- 09640-5(本)0309-54979-5(PDF)、2005、<は://www7.nationalacademies.org/cstb/パブ_dns.html>をhttpします。
[ISO.2022.1986] International Organization for Standardization,
"Information Processing: ISO 7-bit and 8-bit
coded character sets: Code extension techniques",
ISO Standard 2022, 1986.
[ISO.2022.1986] 国際標準化機構、「情報処理:」 ISOの7ビットの、そして、8ビットのコード化文字集合: 「コード拡張のテクニック」、ISO Standard2022、1986。
Klensin, et al. Informational [Page 33] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[33ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
[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 Standard646、1991
[ISO.8859.2003] International Organization for Standardization,
"Information processing - 8-bit single-byte coded
graphic character sets - Part 1: Latin alphabet
No. 1 (1998) - Part 2: Latin alphabet No. 2
(1999) - Part 3: Latin alphabet No. 3 (1999) -
Part 4: Latin alphabet No. 4 (1998) - Part 5:
Latin/Cyrillic alphabet (1999) - Part 6: Latin/
Arabic alphabet (1999) - Part 7: Latin/Greek
alphabet (2003) - Part 8: Latin/Hebrew alphabet
(1999) - Part 9: Latin alphabet No. 5 (1999) -
Part 10: Latin alphabet No. 6 (1998) - Part 11:
Latin/Thai alphabet (2001) - Part 13: Latin
alphabet No. 7 (1998) - Part 14: Latin alphabet
No. 8 (Celtic) (1998) - Part 15: Latin alphabet
No. 9 (1999) - Part 16: Part 16: Latin alphabet
No. 10 (2001)", ISO Standard 8859, 2003.
[ISO、.8859、.2003、]、国際標準化機構、「情報処理--8ビットの単一のバイトコード化された図形文字セット--第1部:、」 ローマ字No.1 (1998)--第2部: ローマ字No.(1999)2--パート3: ローマ字No.(1999)3--パート4: ローマ字No.(1998)4--パート5: ラテン/キリル文字(1999)--パート6: ラテン/アラビア文字(1999)--パート7: ラテン/ギリシャ語アルファベット(2003)--パート8: ラテン語の、または、ヘブライのアルファベット(1999)--パート9: ローマ字No.(1999)5--パート10: ローマ字No.(1998)6--パート11: ラテン語の、または、タイのアルファベット(2001)--パート13: ローマ字No.(1998)7--パート14: ローマ字No.8(ケルト族の)(1998)--パート15: ローマ字No.(1999)9--パート16: パート16: 「ローマ字No.(2001)10」、ISO Standard8859、2003。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets
and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、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、「Aはウェブをもつれました」。 「I18N、Domain Names、およびOtherインターネットプロトコルの問題」、RFC2825、2000年5月。
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H.、「言語の識別のためのタグ」、BCP47、RFC3066、2001年1月。
[RFC3467] Klensin, J., "Role of the Domain Name System
(DNS)", RFC 3467, February 2003.
[RFC3467] Klensin、J.、「ドメインネームシステム(DNS)の役割」、RFC3467、2003年2月。
[RFC3536] Hoffman, P., "Terminology Used in
Internationalization in the IETF", RFC 3536,
May 2003.
[RFC3536]ホフマン(P.、「IETFでの国際化に使用される用語」、RFC3536)は2003がそうするかもしれません。
[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.コー、「共同工学は国際化ドメイン名(IDN)登録のための(ジェット)ガイドラインと中国語、日本語、および韓国語のための政権を組にします」、RFC3743、2004年4月。
[RFC3912] Daigle, L., "WHOIS Protocol Specification",
RFC 3912, September 2004.
[RFC3912] Daigle、L.、「WHOISプロトコル仕様」、RFC3912、2004年9月。
Klensin, et al. Informational [Page 34] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[34ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
[RFC3981] Newton, A. and M. Sanz, "IRIS: The Internet
Registry Information Service (IRIS) Core
Protocol", RFC 3981, January 2005.
[RFC3981] ニュートン、A.、およびM.サンス、「虹彩:」 「インターネット登録情報サービス(虹彩)コアプロトコル」、RFC3981、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.サンス、「虹彩:」 「インターネット登録情報サービス(虹彩)のためのドメイン登録(かす)タイプ」、RFC3982、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、「Uniform Resource Identifier(URI):」 「一般的な構文」、STD66、RFC3986、2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized
Resource Identifiers (IRIs)", RFC 3987,
January 2005.
[RFC3987] DuerstとM.とM.Suignard、「国際化しているリソース識別子(虹彩)」、RFC3987、2005年1月。
[RFC4185] Klensin, J., "National and Local Characters for
DNS Top Level Domain (TLD) Names", RFC 4185,
October 2005.
[RFC4185] Klensin、J.、「DNSトップ・レベル・ドメイン(TLD)名のための国家の、そして、ローカルのキャラクター」、RFC4185、2005年10月。
[RFC4290] Klensin, J., "Suggested Practices for
Registration of Internationalized Domain Names
(IDN)", RFC 4290, December 2005.
[RFC4290] Klensin、J.、「国際化ドメイン名(IDN)の登録のための提案された習慣」、RFC4290、2005年12月。
[RFC4645] Ewell, D., "Initial Language Subtag Registry",
RFC 4645, September 2006.
[RFC4645] イーウェル、D.、「初期の言語Subtag登録」、RFC4645、2006年9月。
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 4646, September 2006.
[RFC4646]フィリップス、A.とM.デイヴィス、「言語を特定するためのタグ」BCP47、2006年9月のRFC4646。
[UTR] Unicode Consortium, "Unicode Technical Reports",
<http://www.unicode.org/reports/>.
[UTR]ユニコード共同体、「ユニコード技術報告書」、<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、「ユニコード技術報告書#36:」 「ユニコードSecurity Considerations」、2005年11月、<http://www.unicode.org/草稿/レポート/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、「ユニコード規格#39(提案されます):」 「ユニコードSecurity Considerations」、2005年7月、<http://www.unicode.org/草稿/レポート/tr39/tr39.html>。
[Unicode-PR29] The Unicode Consortium, "Public Review Issue #29:
Normalization Issue", Unicode PR 29,
February 2004.
[ユニコード-PR29] ユニコード共同体、「公開レビュー問題#29:」 「正常化問題」、ユニコードPR29、2004年2月。
[Unicode10] The Unicode Consortium, "The Unicode Standard,
[Unicode10] ユニコード共同体、「ユニコード規格」
Klensin, et al. Informational [Page 35] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[35ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
Version 1.0", 1991.
バージョン1インチ、1991。
[W3C-Localization] Ishida, R. and S. Miller, "Localization vs.
Internationalization", W3C International/
questions/qa-i18n.txt, December 2005.
[W3C-ローカライズ] 石田とR.とS.ミラー、「ローカライズ対国際化」、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は進歩、2006年4月に働いています。
Authors' Addresses
作者のアドレス
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
Ave、ジョンC Klensin1770マサチューセッツ#322MA02140ケンブリッジ(米国)
Phone: +1 617 491 5735 EMail: john-ietf@jck.com
以下に電話をしてください。 +1 5735年の617 491メール: 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はメールされます: ck@nrm.museum
IAB
IAB
EMail: iab@iab.org
メール: iab@iab.org
Klensin, et al. Informational [Page 36] RFC 4690 IAB -- IDN Next Steps September 2006
Klensin、他 情報[36ページ]のRFC4690IAB--次のIDNは2006年9月に踏みます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Klensin, et al. Informational [Page 37]
Klensin、他 情報[37ページ]
一覧
スポンサーリンク
