Independent Submission P. Resnick Request for Comments: 5895 Qualcomm Incorporated 分類: 情報提供(Informational) P. Hoffman ISSN: 2070-1721 VPN Consortium 2010年9月 IDNA2008における文字のマッピング処理 要旨 オリジナルバージョンのIDNA(Internationalized Domain Names in Applications) プロトコルでは、ユーザが入力した任意のユニコードコードポイントを 「理に適った(make sense)」ユニコードコードポイントの集合にマッピングし、 その後エンコードしてDNSに渡していた。それに対し、IDNA2008プロトコル (RFC 5890, 5891, 5892, 5893に記載がある)は、プロトコルへの入力は 「許容(permitted)」コードポイントであると仮定し、ユーザ入力の結果 得られたものに対して行うべき処理を規定していない。本文書は、ユーザの 入力受信後から、許容コードポイントを新しい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. 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. Resnick & Hoffman Informational [Page 1] RFC 5895 IDNA Mapping September 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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. 1. はじめに 本文書は、ユーザの入力をIDNA(Internationalized Domain Names in Applications)プロトコル[IDNA2008protocol]が受理可能な形式に するために適用可能な操作を記述する。その中にはマッピング処理の 一般的な実装手続きも含まれる。 本文書は、プロトコルがネットワーク上でデータを送受信する際に使用する パケットのフォーマット等を規定しないことに注意すべきである。 本文書は、ネットワーク上で動作するプロトコルがユーザの入力を処理できる ようにするために、ユーザの入力に対して行う前処理を記述する。 インターネットプロトコル文書ではお決まりのことだが、オリジナル IDNAプロトコル(以後IDNA2003と表記する)はユーザ入力処理をプロトコルに 取り込んでいたため、IDNA2003に関わる実装を設計した実装者に向けて この前処理を記述することは、相互接続性を維持するために必須である。 ユーザの入力に対して、潜在的に有効なマッピングが多数あることに注意する ことは極めて重要である。本文書に記述するマッピングは他のマッピングの 基礎となるもので、何らかの修正をせずに使用してもあまり有用ではないだろう。 有用なマッピングとは、それによってユーザが驚くような機会を減らすよう 設計された特性を持ち、おそらくはユーザのロケールや入力手段(タイピングか コピー＆ペーストか、音声変換か等)、使用アプリケーション等によって若干 (場合によっては大きく)異なるものである。普及しているマッピングの 大部分は同じ入力に対しておそらく似た出力を生成するだろうが、 アプリケーションが変わると処理結果に微妙な差異が生じることもあるだろう。 1.1. ユーザインターフェースとプロトコルの境界 アプリケーションに入力を行うユーザインターフェースは、ほとんどの ネットワークプロトコル実装者が考えるよりも遙かに複雑である。 「ユーザが国際化ドメイン名をアプリケーションに入力する」と言う場合、 広い範囲を網羅する非常に複雑な処理を指している。具体的には以下の通り となる。まずユーザがドメイン名を思い浮かべ、使用する用字・文字から 導出される記号の並びによってドメイン名を表現すると決定する。 (訳注: 次ページ先頭に続く） Resnick & Hoffman Informational [Page 2] RFC 5895 IDNA Mapping September 2010 ユーザは、コンピュータに何らかの入力メソッド(キーボードやスタイラス、 音声認識プログラムの場合さえあるかもしれない)で記号を入力する。一方で コンピュータは入力信号を解釈し(キーボードのスキャンコードや入力された 図形記号、デジタル化した音声信号を解析し)、記号の並びによる表現へと 変換する。最後に、記号の並びを正規化し、IDNA処理とDNSが理解可能な エンコーディングの特定の文字レパートリーとする。 国際化ドメイン名用のユーザインターフェースの検討するためには、任意の ユーザに関する文化やコンテキスト、ロケールの情報が必要である。 単純だがよく知られた例として、英字 LATIN CAPITAL LETTER I (U+0049) を 小文字に変換した結果がトルコ語と他の言語では異なることが挙げられる。 トルコ語の大文字「I」を小文字に変換する場合、LATIN SMALL LETTER DOTLESS I (U+0131) にするのが適切であり、LATIN SMALL LETTER I (U+0069) とは ならない。この小文字変換は明らかにユーザやシステムのロケールに依存する ものである。ユーザインターフェースの特性を考慮せず、コンテキスト非依存な 単一のマッピングを使用すると、ユーザにとって誤ったマッピングになる 可能性がある。 オリジナルバージョンのIDNAは、ユーザインターフェース処理とプロトコルを 一つにまとめている。これらの全処理をプロトコル内に含めるために、 ユーザが使用するアプリケーションのエンコーディングが何であっても、 ユーザが生成した文字がどのようなものであっても受理し、ユニコード コードポイントへの何らかの変換を前提とし、コンテキストやロケール、 ユーザが意図するもの全てについて考慮することなく、それらを他の 文字の集合にマッピングし、さらにPunycodeに再エンコードする。 IDNAプロトコルでコンテキストやロケール、ユーザの嗜好を無視した結果、 アプリケーション開発者にとってユーザの振る舞いは非常に簡易なものに なった。しかしドメイン名の登録者および利用者が「ユーザを極力驚かせない」 という原則には反している。 IDNA2008では、「ユーザインターフェース」と「プロトコル」の境界は 明確である。IDNA2008仕様はIDNAのプロトコル部を定義しているが、明示的に ユーザインターフェースを扱っていない。本文書が記述するようなマッピングは 明示的にユーザインターフェースを扱うが、プロトコルは扱わない。 つまり、マッピングは文字列が(「ユーザインターフェース処理」で)ドメイン名 として扱われる前にだけ適用される。(「プロトコル」における)ドメイン名処理の 際には適用されない。 1.2. 本文書のマッピングの設計理念 本文書に記述するユーザインターフェースにおけるマッピングは、実用的で 扱いやすいように意図して作られたIDNA2008の拡張処理の集合であり、 そのほとんどはドメイン名を手入力する典型的なアプリケーションを使用する 世界中の人々にとって自明のものである。また、アプリケーションがIDNA2003と ほぼ後方互換になるように設計されている。当然だが、全ての人々に対して 全ての設計ゴールが達成できるわけではない。非常に多くの人口の人々に対して ゴールの幾つかが達成できていないことが明らかになっている。 Resnick & Hoffman Informational [Page 3] RFC 5895 IDNA Mapping September 2010 実世界における良いマッピングは「実用的で扱いやすくほぼ自明な」 設計ゴールを持つが、幾つもの異なるアルゴリズムが考案されてきている。 多くのアルゴリズムはユーザの考え方や入力方式に異なる前提を置いているが、 本文書に記載するものに近い結果になる。それでもやはり、幾つかの マッピングについては本文書記載のものと大きく異なる結果となる可能性がある。 例えば、タイプ入力の代わりに音声入力のユーザインターフェースにマッピングが 適用されるかもしれない。(その場合はマッピング結果が大きく異なるかも しれない)。他の例として、タイプ入力するユーザと別のアプリケーションから コピー＆ペーストするユーザではマッピングの結果が異なるかもしれない。 さらにもう1つの例として、Latin文字から別の言語系に書き直す(transliterated) 形式のタイプ入力を許容するユーザインターフェースに適用されるマッピングは、 他の文字セットに適用されるマッピングと大きく異なるかもしれない。 典型的な例は中国語文字(chinese characters)用のPinyin Inputメソッドである。 2. 一般的な手続き 本セクションは、IDNAプロトコルで有効なユニコードコードポイントを アプリケーションが生成するために実装すべき一般的アルゴリズムを定義する。 アプリケーションは以下に記述する完全なマッピング処理を実装するかも しれないし、あるいは異なるマッピング処理を選択することもできる。 以下に示すマッピングは非常に一般的で、非常に広範なユーザコミュニティで 容認されるように設計されている。しかし、先に記述したIDNA2003と同様に、 特定のコンテキストや文化、ロケールは一切考慮していない。 アプリケーション(またはオペレーティングシステムが提供する入力メソッド) が使用すべき一般的アルゴリズムは比較的単純である。 1. ユニコード文字の文字種マッピング用アルゴリズムを使用して、 大文字の文字を等価な小文字にマッピングする。 この処理が選択された理由は、処理結果の動作がASCIIホスト名の動作に より近くなるためである。 2. 全角文字と半角文字(それぞれ分解タイプ(Decomposition Type) とで定義される)をユニコード文字データベースの 分解マッピング(decomposition mapping)にマップする。 この処理が選択された理由は、多くの入力の仕組み、特にアジア地域の 入力の仕組みはIDNA2008が使用する形式の文字入力を容易に行えないため である。仮に適切な形式の文字入力が可能であったとしても、ユーザは 自分が入力している文字の形式がどちらであるかは意識しない。 Resnick & Hoffman Informational [Page 4] RFC 5895 IDNA Mapping September 2010 3. 全ての文字をユニコードNFC形式(Normalization Form C)にマッピングする。 この処理が選択された理由は、これにより、結合文字の組合せが 正規化合成形式(canonical composed form)にマッピングされるためである。 全角文字と半角文字を対象にしたマッピング(2の処理)と同様に、ユーザは 一般に自分が入力している文字の形式を意識しない。またIDNA2008はNFCの 正規化合成形式だけを使用するように要求している。 4. [IDNA2008protocol] は、プロトコルがドメイン名の個々のラベル上で 動作するよう規定した。本マッピング処理の実装がFULL STOP文字(U+002E)を 使用してドメイン名を個々のラベルへと分割するのであれば、ラベル分割を 行う前に、IDEOGRAPHIC FULL STOP文字(U+3002)をFULL STOPにマップする ことができる。「full stop」として使用可能な他の文字も存在する。 これらの文字はラベルのセパレータとして使用できるのかもしれないが、 そのような使用法については充分な調査がなされていない。 この処理が選択された理由は、ある種の入力の仕組みでは、ユーザが 適切なラベルセパレータを容易に入力できないためである。 本マッピングでは、IDEOGRAPHIC FULL STOP文字(U+3002)だけを追加した。 他の文字の適用可能性や、それらの文字をドメイン名ラベルのセパレータと みなすべき環境、みなすべきでない環境などについて充分な調査を著者らが 行っていないためである。 上に記した処理は順序付けがされていることに注意してもらいたい。 このアルゴリズムのルールに関連する様々な定義は[Unicode52]で得られる。 具体的に、 ・ ユニコードNKC形式(Normalization Form C)は[Unicode-UAX15]のAnnex #15で 得られる。 ・ 大文字の文字を等価な小文字の文字にマッピングするには次のようにする ([Unicode52]のセクション3.13で定義される)。 最初に文字がに 該当するかを調べ、該当する場合には「Lowercase_Mapping」特性(第2カラムの 「」エントリ」)にマッピングする。 該当しない場合は の「Simple_Lowercase_Mapping」特性(14番目のカラム)を調べ、該当するものが あればそれにマッピングする。 ・ 全角文字や半角文字を各文字の分解マッピングにマッピングするには次のように する。文字の「Decomposition_Type」 (の第6カラムの 前半部)が「」か「」の場合、その文字の 「Decomposition_Mapping」(第6カラムの後半部)にマッピングする。 Resnick & Hoffman Informational [Page 5] RFC 5895 IDNA Mapping September 2010 ・ ユニコード文字データベース[TR44]には、これらのファイルの内容に関する 有用な記述がある。 本文書のマッピング処理をユニコード5.2よりも新しいバージョンに適用する場合、 その新しいバージョンのユニコード標準を調査すべきである。 上記の一連のアルゴリズムは、アプリケーションが実行することを強く推奨 される最小限の集合を構成する。もちろん、他にも実行される処理は沢山 あるだろう。 3. 本マッピングの実装に関する注意 もし、読者がアプリケーションまたはオペレーティングシステム向けに、 セクション2に記述した4つの処理手順に忠実にマッピングを実装しようと しているのであれば、本文書の著者として次のようにリクエストしたい。 「それは止めて欲しい」。セクション2は普遍的なマッピングアルゴリズムを 記述していない。既に述べたように、普遍的に適用可能なマッピング アルゴリズムは存在しないのである。 もし、読者がセクション1を読むことなくセクション2の内容を読んだのであれば、 セクション1に立ち戻り、セクション1全てを慎重に読み直してほしい。 色々な意味で、セクション1はセクション2よりも重要である。さらに、 セクション1を読むことで、セクション1には列挙されていないユーザ インターフェースに関する考慮点についても検討できるようになる。 読者がセクション1を読んだうえで、それでもなお開発中のアプリケーションの 想定ユーザに対して、セクション2に記載したアルゴリズムが完璧に正しいと 判断したのであれば、おそらく想定ユーザに関してきちんとした検討が なされていないと思われる。 4. セキュリティに関する考慮点 本文書はユーザの混乱を軽減させるマッピングの生成を提案しているが、 一方でそれは一部のユーザに混乱を生じさせる可能性があるかもしれない。 そのような混乱については、本文書(他のIDNAに関連する文書も含めて)では 一切カバーしていない。 5. Acknowledgements This document is the product of many contributions from numerous people in the IETF. Resnick & Hoffman Informational [Page 6] RFC 5895 IDNA Mapping September 2010 6. Normative References [IDNA2008protocol] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010. [TR44] The Unicode Consortium, "Unicode Technical Report #44: Unicode Character Database", September 2009, . [Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms, Revision 31", September 2009, . [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). . Authors' Addresses 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 Phone: 1-831-426-9827 EMail: paul.hoffman@vpnc.org Resnick & Hoffman Informational [Page 7]