Independent Submission P. Resnick
Request for Comments: 5895 Qualcomm Incorporated
Category: Informational P. Hoffman
ISSN: 2070-1721 VPN Consortium
September 2010
Mapping Characters for
Internationalized Domain Names in Applications (IDNA) 2008
Abstract
抽象
In the original version of the Internationalized Domain Names in Applications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "made sense", and then encoded and passed to the domain name system (DNS). The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protocol comes from a set of "permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the result of user input. This document describes the actions that can be taken by an implementation between receiving user input and passing permitted code points to the new IDNA protocol.
アプリケーションにおける国際化ドメイン名の元のバージョンで（IDNA）プロトコル、ユーザ入力から取られた任意のUnicodeコードポイントはUnicodeコードのセットにマッピングした「とは、理にかなって」、その後、符号化され、（ドメインネームシステムに渡されることを指しDNS）。 IDNA2008の（のRFC 5890、5891、5892に記載され、そして5893）プロトコルは、プロトコルへの入力が、それは、次にエンコードし、DNSに渡す「許可」のコードポイントの集合から来ることを前提とし、それに何が指定されていませんユーザー入力の結果で行います。この文書では、ユーザ入力を受信し、新しいIDNAプロトコルに許可コードポイントを通過する間に実装によってとられるアクションを記述する。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5895.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5895で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document describes the operations that can be applied to user input in order to get it into a form that is acceptable by the Internationalized Domain Names in Applications (IDNA) protocol [IDNA2008protocol]. It includes a general implementation procedure for mapping.
この文書では、アプリケーションの国際化ドメイン名によって許容される形態（IDNA）プロトコル[IDNA2008protocol]にそれを取得するために、ユーザ入力に適用することができる動作を説明します。これは、マッピングのための一般的な実施手順が含まれています。
It should be noted that this document does not specify the behavior of a protocol that appears "on the wire". It describes an operation that is to be applied to user input in order to prepare that user input for use in an "on the network" protocol. As unusual as this may be for a document concerning Internet protocols, it is necessary to describe this operation for implementors who may have designed around the original IDNA protocol (herein referred to as IDNA2003), which conflates this user-input operation into the protocol.
この文書は、「ワイヤー上」と表示されたプロトコルの動作を指定していないことに留意すべきです。これは、「ネットワーク上の」プロトコルで使用するための、そのユーザ入力を調製するために、ユーザ入力に適用される動作を説明します。このような異常なインターネット・プロトコルに関するドキュメントためのものであってもよいように、プロトコルには、このユーザ入力操作を融合します元IDNAプロトコル（本明細書IDNA2003と呼ぶ）、周囲に設計してもよい実装のために、この動作を説明する必要があります。
It is very important to note that there are many potential valid mappings of characters from user input. The mapping described in this document is the basis for other mappings, and is not likely to be useful without modification. Any useful mapping will have features designed to reduce the surprise for users and is likely to be slightly (or sometimes radically) different depending on the locale of the user, the type of input being used (such as typing, copy-and-paste, voice, and so on), the type of application used, etc. Although most common mappings will probably produce similar results for the same input, there will be subtle differences between applications.
ユーザの入力から文字の多くの潜在的な有効なマッピングがあることに注意することは非常に重要です。この文書で説明するマッピングは、他のマッピングのための基礎であり、かつ修正なしに有用である可能性が高いではありません。任意の有用なマッピングは、ユーザのロケールに応じて異なるユーザのために驚きを低減するように設計された機能を有し、わずかに（または時にはラジカル）である可能性が高いであろう、入力の種類を（例えば、タイピング、コピー・アンド・ペーストとして使用されていますなどの声など）、使用するアプリケーションの種類、最も一般的なマッピングは、おそらく同じ入力に対して同様の結果を生成しますが、アプリケーション間の微妙な違いがあるでしょう。
The user interface to applications is much more complicated than most network implementers think. When we say "the user enters an internationalized domain name in the application", we are talking about a very complex process that encompasses everything from the user formulating the name and deciding which symbols to use to express that name, to the user entering the symbols into the computer using some input method (be it a keyboard, a stylus, or even a voice recognition program), to the computer interpreting that input (be it keyboard scan codes, a graphical representation, or digitized sounds) into some representation of those symbols, through finally normalizing those symbols into a particular character repertoire in an encoding recognizable to IDNA processes and the domain name system.
アプリケーションへのユーザー・インターフェースは、ほとんどのネットワーク実装が考えるよりはるかに複雑です。私たちが言うとき、我々は記号を入力するユーザーに、名前を策定し、その名前を表現するために使用するシンボルを決定するユーザーからすべてを網羅する非常に複雑なプロセスについて話している、「ユーザーがアプリケーションに国際化ドメイン名を入力します」それらのいくつかの表現にいくつかの入力方法を使用してコンピュータその入力を解釈するコンピュータに、（それはキーボード、スタイラス、あるいは音声認識プログラムである）（それはキーボードスキャンコード、グラフィック表現、またはデジタル化された音である）に最後にIDNAプロセス及びドメインネームシステムに認識エンコーディングにおける特定の文字レパートリーにこれらのシンボルを正規化を介してシンボル、。
Considerations for a user interface for internationalized domain names involves taking into account culture, context, and locale for any given user. A simple and well-known example is the lowercasing of the letter LATIN CAPITAL LETTER I (U+0049) when it is used in the Turkish and other languages. A capital "I" in Turkish is properly lowercased to a LATIN SMALL LETTER DOTLESS I (U+0131), not to a LATIN SMALL LETTER I (U+0069). This lowercasing is clearly dependent on the locale of the system and/or the locale of the user. Using a single context-free mapping without considering the user interface properties has the potential of doing exactly the wrong thing for the user.
国際化ドメイン名のためのユーザインタフェースのための考慮事項は、任意のユーザーのアカウント文化、コンテキスト、およびロケールを考慮して必要とします。それはトルコ語と他の言語で使用される場合、シンプルでよく知られた例は、I（U + 0049）文字ラテン大文字の小文字です。首都 "私は" トルコ語で適切にLATIN SMALL LETTER DOTLESS I（U + 0131）に、ではないLATIN SMALL LETTER I（U + 0069）に小文字に変換されます。この小文字は、システムおよび/またはユーザのロケールのロケールに明確に依存しています。ユーザインタフェースの特性を考慮せずに、単一の文脈自由マッピングを使用すると、ユーザーのために、正確に間違ったことをやっての可能性を秘めています。
The original version of IDNA conflated user interface processing and protocol. It took whatever characters the user produced in whatever encoding the application used, assumed some conversion to Unicode code points, and then without regard to context, locale, or anything about the user's intentions, mapped them into a particular set of other characters, and then re-encoded them in Punycode, in order to have the entire operation be contained within the protocol. Ignoring context, locale, and user preference in the IDNA protocol made life significantly less complicated for the application developer, but at the expense of violating the principle of "least user surprise" for consumers and producers of domain names.
IDNAの元のバージョンは、ユーザインタフェース処理およびプロトコルを融合し。その後、ユーザーはどのようなアプリケーションが使用するエンコーディングで生産どんな文字ましたUnicodeコードポイントにいくつかの変換を仮定して、ユーザーの意図について、コンテキスト、ロケール、または何かに関係なく、他の文字の特定のセットにそれらをマッピングして、全体の動作は、プロトコル内に含まれるようにするために、ピュニコードでそれらを再エンコード。 IDNAプロトコルに関連し、ロケール、およびユーザーの好みを無視すると、大幅に少ない複雑なアプリケーション開発者のための生活をしたが、ドメイン名の消費者と生産者のために、「少なくとも、ユーザ驚き」の原則に違反を犠牲にして。
In IDNA2008, the dividing line between "user interface" and "protocol" is clear. The IDNA2008 specification defines the protocol part of IDNA: it explicitly does not deal with the user interface. Mappings such as the one described in this document explicitly deal with the user interface and not the protocol. That is, a mapping is only to be applied before a string of characters is treated as a domain name (in the "user interface") and is never to be applied during domain name processing (in the "protocol").
IDNA2008では、「ユーザインターフェース」と「プロトコル」間の境界線は明確です。 IDNA2008仕様はIDNAのプロトコル部分を定義：それが明示的ユーザインタフェースを扱っていません。例えば、この文書に記載されたものとのマッピングは、明示的にユーザインタフェースとしないプロトコルを扱います。すなわち、マッピングがあるだけで文字列をドメイン名として扱われる前（「ユーザインターフェース」に）適用され（「プロトコル」に）ドメイン名の処理中に適用することはありませんすること、です。
The user interface mapping in this document is a set of expansions to IDNA2008 that are meant to be sensible and friendly and mostly obvious to people throughout the world when using typical applications with domain names that are entered by hand. It is also designed to let applications be mostly backwards compatible with IDNA2003. By definition, it cannot meet all of those design goals for all people, and in fact is known to fail on some of those goals for quite large populations of people.
この文書に記載されているユーザ・インターフェース・マッピングは、手作業で入力されたドメイン名を持つ代表的なアプリケーションを使用する際に、世界中の人々に賢明かつフレンドリーで、ほとんど明らかであることを意味しているIDNA2008への拡張のセットです。また、アプリケーションがIDNA2003と、ほとんどの下位互換性があるように設計されています。定義によると、それはすべての人々のために、これらの設計目標のすべてを満たすことができない、実際に人々のかなり大きな集団のために、これらの目標の一部に失敗することが知られています。
A good mapping in the real world might use the "sensible and friendly and mostly obvious" design goal but come up with a different algorithm. Many algorithms will have results that are close to what is described here, but will differ in assumptions about the users' way of thinking or typing. Having said that, it is likely that some mappings will be significantly different. For example, a mapping might apply to a spoken user interface instead of a typed one. Another example is that a mapping might be different for users that are typing than for users that are copying-and-pasting from different applications. Yet another example is that a user interface that allows typed input that is transliterated from Latin characters could have very different mappings than one that applies to typing in other character sets; this would be typical in a Pinyin input method for Chinese characters.
現実の世界では良いマッピングは、「賢明かつフレンドリーで、ほとんど明らかに」設計目標を使用しますが、別のアルゴリズムを思いつくかもしれません。多くのアルゴリズムは、ここで説明されているものに近い結果を持っていますが、思考やタイピングのユーザーの仕方についての仮定が異なります。いくつかのマッピングが大幅に異なるものになる可能性がある、と述べました。例えば、マッピングが話されたユーザインターフェースの代わりに、入力されたものに適用される場合があります。別の例は、マッピングがコピー＆ペースト異なるアプリケーションかられているユーザーのためのより入力しているユーザーのために異なる場合がありますということです。さらに別の例は、ラテン文字から音訳された入力を入力できるユーザインタフェースが他の文字セットを入力に適用されるものとは非常に異なるマッピングを持っている可能性があることです。これは中国の文字のピンイン入力法では典型的です。
This section defines a general algorithm that applications ought to implement in order to produce Unicode code points that will be valid under the IDNA protocol. An application might implement the full mapping as described below, or it can choose a different mapping. This mapping is very general and was designed to be acceptable to the widest user community, but as stated above, it does not take into account any particular context, culture, or locale.
このセクションでは、アプリケーションは、IDNAプロトコルの下で有効になりUnicodeコードポイントを生成するために実装するべき一般的なアルゴリズムを定義します。以下で説明するように、アプリケーションは、完全なマッピングを実装するかもしれない、またはそれは異なるマッピングを選択することができます。このマッピングは非常に一般的であり、最も広いユーザーコミュニティに受け入れられるように設計されましたが、前述のように、それは考慮に任意の特定の状況、文化、またはロケールを取ることはありません。
The general algorithm that an application (or the input method provided by an operating system) ought to use is relatively straightforward:
アプリケーション（またはオペレーティングシステムによって提供される入力方式）を使用するべき一般的なアルゴリズムは比較的簡単です。
1. Uppercase characters are mapped to their lowercase equivalents by using the algorithm for mapping case in Unicode characters. This step was chosen because the output will behave more like ASCII host names behave.
1.大文字は、Unicode文字にマッピングする場合のアルゴリズムを使用して、小文字の等価物にマッピングされます。出力は複数のホスト名が振る舞うASCIIのように動作しますので、このステップは、選択されました。
2. Fullwidth and halfwidth characters (those defined with Decomposition Types <wide> and <narrow>) are mapped to their decomposition mappings as shown in the Unicode character database. This step was chosen because many input mechanisms, particularly in Asia, do not allow you to easily enter characters in the form used by IDNA2008. Even if they do allow the correct character form, the user might not know which form they are entering.
Unicode文字データベース2に示すように全角と半角文字が（分解タイプ<ワイド>と<狭い>で定義されたもの）は、その分解のマッピングにマッピングされます。特にアジアの多くの入力機構は、あなたが簡単にIDNA2008で使用されるフォームに文字を入力することはできませんので、このステップは、選択されました。彼らは正しい文字の形を許可しない場合でも、ユーザーは、入力されたフォームを知っていない可能性があります。
3. All characters are mapped using Unicode Normalization Form C (NFC). This step was chosen because it maps combinations of combining characters into canonical composed form. As with the fullwidth/halfwidth mapping, users are not generally aware of the particular form of characters that they are entering, and IDNA2008 requires that only the canonical composed forms from NFC be used.
3.すべての文字は、Unicode正規化形式C（NFC）を使用してマッピングされます。それは標準的な合成フォームに文字を組み合わせるの組み合わせをマップするため、この手順は選択されました。全角/半角マッピングと同様に、ユーザは、一般に、それらが入力する文字の特定の形を認識していない、とIDNA2008は、NFCからのみカノニカル構成形態が使用されることを必要とします。
4. [IDNA2008protocol] is specified such that the protocol acts on the individual labels of the domain name. If an implementation of this mapping is also performing the step of separation of the parts of a domain name into labels by using the FULL STOP character (U+002E), the IDEOGRAPHIC FULL STOP character (U+3002) can be mapped to the FULL STOP before label separation occurs. There are other characters that are used as "full stops" that one could consider mapping as label separators, but their use as such has not been investigated thoroughly. This step was chosen because some input mechanisms do not allow the user to easily enter proper label separators. Only the IDEOGRAPHIC FULL STOP character (U+3002) is added in this mapping because the authors have not fully investigated the applicability of other characters and the environments where they should and should not be considered domain name label separators.
4 IDNA2008protocol]プロトコルは、ドメイン名の個々のラベルに作用するように指定されています。このマッピングの実装もFULL STOP文字（U + 002E）を使用してラベルにドメイン名の部分の分離のステップを実行している場合、IDEOGRAPHIC FULL STOP文字（U + 3002）は、完全にマップすることができラベル分離が起こる前に停止。 1は、ラベルの区切りとしてマッピングを検討することもでき、「ピリオド」として使用されているが、このようなとしての使用を徹底的に調査されていない他の文字があります。いくつかの入力機構は、ユーザーが簡単に適切なラベルの区切りを入力することはできませんので、このステップは、選択されました。著者は、完全に他の文字と、彼らは、ドメイン名のラベルの区切りとみなされるべきではないはずです。環境の適用性を検討していないためだけIDEOGRAPHIC FULL STOP文字（U + 3002）は、このマッピングに追加されます
Note that the steps above are ordered.
上記の手順が順序付けられていることに注意してください。
Definitions for the rules in this algorithm can be found in [Unicode52]. Specifically:
このアルゴリズムでは、ルールの定義は、[Unicode52]で見つけることができます。具体的に：
o Unicode Normalization Form C can be found in Annex #15 of [Unicode-UAX15].
O Unicodeの正規化形式Cは、[ユニコードUAX15]の付録＃15に見出すことができます。
o In order to map uppercase characters to their lowercase equivalents (defined in Section 3.13 of [Unicode52]), first map characters to the "Lowercase_Mapping" property (the "<lower>" entry in the second column) in <http://www.unicode.org/Public/UNIDATA/SpecialCasing.txt>, if any. Then, map characters to the "Simple_Lowercase_Mapping" property (the fourteenth column) in <http://www.unicode.org/Public/UNIDATA/UnicodeData.txt>, if any.
O <HTTPの「Lowercase_Mapping」プロパティ（2列目の「<下位>」エントリ）への小文字当量（[Unicode52]のセクション3.13で定義される）、第1の地図文字に大文字をマッピングするために：// www.unicode.org/Public/UNIDATA/SpecialCasing.txt>、もしあれば。次に、<http://www.unicode.org/Public/UNIDATA/UnicodeData.txt>で「Simple_Lowercase_Mapping」プロパティ（第14列）にマップ文字を、もしあれば。
o In order to map fullwidth and halfwidth characters to their decomposition mappings, map any character whose "Decomposition_Type" (contained in the first part of the sixth column) in <http://www.unicode.org/Public/UNIDATA/UnicodeData.txt> is either "<wide>" or "<narrow>" to the "Decomposition_Mapping" of that character (contained in the second part of the sixth column) in <http://www.unicode.org/Public/UNIDATA/UnicodeData.txt>.
O（6列目の最初の部分に含まれている）「Decomposition_Type」<http://www.unicode.org/Public/UNIDATA/UnicodeData内の任意の文字を、その分解マッピングに全角と半角文字をマップにマッピングするために。 TXT>のいずれかである「<ワイド>」または「<狭い>」の（6列目の第二の部分に含まれている）、その文字の「Decomposition_Mapping」<へhttp://www.unicode.org/Public/UNIDATA/いるUnicodeData.txt>。
o The Unicode Character Database [TR44] has useful descriptions of the contents of these files.
ユニコード文字データベースO [TR44]これらのファイルの内容の有益な記述を持っています。
If the mappings in this document are applied to versions of Unicode later than Unicode 5.2, the later versions of the Unicode Standard should be consulted.
この文書のマッピングがUnicode 5.2より後のUnicodeのバージョンに適用されている場合は、Unicode標準のそれ以降のバージョンを相談する必要があります。
These form a minimal set of mappings that an application should strongly consider doing. Of course, there are many others that might be done.
これらは、アプリケーションが強くやって検討すべきマッピングの最小セットを形成します。もちろん、行われるかもしれない他の多くがあります。
If you are implementing a mapping for an application or operating system by using exactly the four steps in Section 2, the authors of this document have a request: please don't. We mean it. Section 2 does not describe a universal mapping algorithm because, as we said, there is no universally-applicable mapping algorithm.
あなたは第2節では、正確に4つのステップを使用して、アプリケーションやオペレーティングシステムのマッピングを実装している場合は、この文書の著者は、要求がありますしないでください。我々はそれを意味します。我々が言ったように、普遍-該当するマッピングアルゴリズムが存在しない、ので、第2節では、ユニバーサルマッピングアルゴリズムを説明していません。
If you read the material in Section 2 without reading Section 1, go back and carefully read all of Section 1; in many ways, Section 1 is more important than Section 2. Further, you can probably think of user interface considerations that we did not list in Section 1. If you did read Section 1 but somehow decided that the algorithm in Section 2 is completely correct for the intended users of your application or operating system, you are probably not thinking hard enough about your intended users.
あなたはセクション1を読まず2節で材料を読めば、戻って慎重に第1節のすべてを読んで。多くの点で、第1は、さらに、第2節よりも重要であるあなたは、セクション1を読んで何とか第2節では、アルゴリズムが完全に正確であると判断した場合は、おそらく、我々は第1節では表示されませんでしたユーザーインターフェースを考慮すると考えることができますアプリケーションやオペレーティングシステムの意図したユーザーのために、あなたはおそらく、あなたの意図したユーザーについて十分に懸命に考えていません。
This document suggests creating mappings that might cause confusion for some users while alleviating confusion in other users. Such confusion is not covered in any depth in this document (nor in the other IDNA-related documents).
この文書は、他のユーザーの混乱を軽減しながら、一部のユーザーに混乱を引き起こす可能性があるマッピングを作成示唆しています。このような混乱は、この文書に記載されている（また、他のIDNA関連文書に）任意の深さでカバーされていません。
This document is the product of many contributions from numerous people in the IETF.
このドキュメントは、IETFにおける数多くの人々から多くの貢献の産物です。
[IDNA2008protocol] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[IDNA2008protocol] Klensin、J.、 "アプリケーション（IDNA）で国際化ドメイン名：プロトコル"、RFC 5891、2010年8月。
[TR44] The Unicode Consortium, "Unicode Technical Report #44: Unicode Character Database", September 2009, <http://www.unicode.org/reports/tr44/ tr44-4.html>.
[TR44]はUnicodeコンソーシアム、 "Unicodeの技術レポート＃44：Unicode文字データベース"、2009年9月、<http://www.unicode.org/reports/tr44/ tr44-4.html>。
[Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms, Revision 31", September 2009, <http://www.unicode.org/reports/ tr15/tr15-31.html>.
[ユニコードUAX15]ユニコードコンソーシアム、 "Unicode規格付属書＃15：Unicode正規化フォーム、リビジョン31" 2009年9月、<http://www.unicode.org/reports/ TR15 / tr15-31.html>。
[Unicode52] The Unicode Consortium. The Unicode Standard, Version 5.2.0, defined by: "The Unicode Standard, Version 5.2.0", (Mountain View, CA: The Unicode Consortium, 2009. ISBN 978-1-936213-00-9). <http://www.unicode.org/versions/Unicode5.2.0/>.
【Unicode52]ユニコードコンソーシアム。 "Unicode標準、バージョン5.2.0"、（カリフォルニア州マウンテンビュー：ユニコードコンソーシアム、2009年ISBN 978-1-936213-00-9）によって定義されたUnicode標準、バージョン5.2.0、。 <http://www.unicode.org/versions/Unicode5.2.0/>。
Authors' Addresses
著者のアドレス
Peter W. Resnick Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 US
ピーター・W.レズニックQualcomm社5775モアハウスドライブサンディエゴ、CA 92121から1714米
Phone: +1 858 651 4478 EMail: presnick@qualcomm.com URI: http://www.qualcomm.com/~presnick/
電話：+1 858 651 4478 Eメール：presnick@qualcomm.com URI：http://www.qualcomm.com/~presnick/
Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 US
ポール・ホフマンVPNコンソーシアム127セグレ場所サンタクルス、CA 95060米国
Phone: 1-831-426-9827 EMail: paul.hoffman@vpnc.org
電話：1-831-426-9827 Eメール：paul.hoffman@vpnc.org