[要約] RFC 5895は、IDNA 2008における国際化ドメイン名の文字マッピングに関する規格です。その目的は、異なる文字セットを使用するドメイン名を正しく変換し、一貫性のある国際化ドメイン名の処理を実現することです。
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
アプリケーションの国際化ドメイン名のマッピング文字（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）プロトコルの国際化ドメイン名の元のバージョンでは、ユーザー入力から取得したユニコードコードポイントは、「意味がある」ユニコードコードポイントのセットにマッピングされ、エンコードされてドメイン名システムに渡されました（DNS）。IDNA2008プロトコル（RFCS 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エディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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）の文字の低いものです。トルコ語の首都「私」は、ラテン語の小さな文字i（u 0069）ではなく、ラテン語の小文字のドットレスi（u 0131）に適切に低くなっています。この低いケーシングは、システムのロケールおよび/またはユーザーのロケールに明らかに依存しています。ユーザーインターフェイスのプロパティを考慮せずに単一のコンテキストフリーマッピングを使用すると、ユーザーにとって正確に間違ったことを行う可能性があります。
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.
現実の世界での優れたマッピングは、「賢明でフレンドリーで、ほとんど明白な」デザイン目標を使用するかもしれませんが、別のアルゴリズムを考え出すことができます。多くのアルゴリズムには、ここで説明されているものに近い結果がありますが、ユーザーの考え方やタイピングに関する仮定が異なります。そうは言っても、一部のマッピングは大幅に異なる可能性があります。たとえば、マッピングは、入力されたものではなく、音声ユーザーインターフェイスに適用される場合があります。もう1つの例は、さまざまなアプリケーションからコピーしてパスティングしているユーザーよりも、入力しているユーザーのマッピングが異なる場合があることです。さらに別の例は、ラテン文字から音訳される入力された入力を許可するユーザーインターフェイスが、他の文字セットでの入力に適用されるマッピングとは非常に異なるマッピングを持つ可能性があることです。これは、漢字のピンイン入力方法で典型的です。
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プロトコルで有効なユニコードコードポイントを生成するために、アプリケーションが実装すべき一般的なアルゴリズムを定義します。アプリケーションは、以下に説明するように完全なマッピングを実装するか、別のマッピングを選択できます。このマッピングは非常に一般的であり、最も広いユーザーコミュニティに受け入れられるように設計されていますが、上記のように、特定のコンテキスト、文化、またはロケールを考慮していません。
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.
2. 完全幅と半幅の文字（分解タイプ<wide>および<laster>で定義されている文字）は、Unicode文字データベースに示すように、分解マッピングにマッピングされます。このステップは、特にアジアでの多くの入力メカニズムにより、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）を使用してマッピングされます。このステップは、文字を標準的な構成フォームに組み合わせる組み合わせをマップするため、選択されました。FullWidth/HalfWidthマッピングと同様に、ユーザーは一般に入力している特定の形式の文字を認識しておらず、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]は、プロトコルがドメイン名の個々のラベルに作用するように指定されています。このマッピングの実装では、フルストップ文字（U 002E）を使用してドメイン名の部分をラベルに分離するステップも実行されている場合、表現撮影フルストップ文字（U 3002）を前にフルストップにマッピングできます。ラベル分離が発生します。ラベルセパレーターとしてマッピングを検討できる「フルストップ」として使用される他のキャラクターがありますが、その使用は徹底的に調査されていません。一部の入力メカニズムでは、ユーザーが適切なラベルセパレーターを簡単に入力できないため、このステップが選択されました。著者は、ドメイン名ラベルセパレーターと見なされるべきではない場合と考えられるべきではない環境の適用性を著者が完全に調査していないため、このマッピングには、表意図フルストップキャラクター（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は、[Unicode-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 大文字の等価物に大文字をマップするため（[Unicode52]のセクション3.13で定義）、最初の文字を「Lowercase_Mapping」プロパティ（2番目の列の「<lower>」エントリ）にマップするために<http：// www.unicode.org/public/unidata/specialcasing.txt>、もしあれば。次に、文字を<http://www.unicode.org/public/unidata/unicodedata.txt>の「simple_lowercase_mapping」プロパティにマッピングします。
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 フル幅と半幅の文字を分解マッピングにマッピングするために、<http://www.unicode.org/public/unidata/unicodedata.txta.txtの「decomposition_type」（6列の最初の部分に含まれる）をマッピングします。>その文字（6列目の2番目の部分に含まれる）の「Decomposition_Mapping」に「<Wide>」または「<laster>」のいずれかです。.txt>。
o The Unicode Character Database [TR44] has useful descriptions of the contents of these files.
o Unicode文字データベース[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.
セクション2のセクション1を読んでも資料を読んだ場合は、戻ってセクション1のすべてを注意深くお読みください。多くの点で、セクション1はセクション2よりも重要です。さらに、セクション1にリストしなかったユーザーインターフェイスの考慮事項を考えることができます。セクション1を読んだが、セクション2のアルゴリズムが完全に正しいと判断した場合アプリケーションまたはオペレーティングシステムの意図したユーザーの場合、おそらく意図したユーザーについて十分に考えていないでしょう。
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）：Protocol」、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 CONSORTIUM、「Unicode Technical Report＃44：Unicode Character Database」、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>.
[Unicode-uax15] Unicode Consortium、「Unicode Standard Annex＃15：Unicode Normalization Forms、Revision 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コンソーシアム。Unicode標準バージョン5.2.0、「Unicode Standard、バージョン5.2.0」、（Mountain View、CA：Unicode Consortium、2009。ISBN 978-1-936213-00-9）で定義されています。<http://www.unicode.org/versions/unicode5.2.0/>。
Authors' Addresses
著者のアドレス
Peter W. Resnick Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 US
Peter W. Resnick Qualcomm Incorporated 5775 Morehouse Drive San Diego、CA 92121-1714 US
Phone: +1 858 651 4478
EMail: presnick@qualcomm.com
URI: http://www.qualcomm.com/~presnick/
Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 US
ポールホフマンVPNコンソーシアム127セグレプレイスサンタクルス、カリフォルニア州95060米国
Phone: 1-831-426-9827 EMail: paul.hoffman@vpnc.org
電話：1-831-426-9827メール：paul.hoffman@vpnc.org