Internet Engineering Task Force (IETF) J. Klensin Request for Comments: 5894 2010年8月 分類: 情報提供(Informational) ISSN: 2070-1721 アプリケーションにおけるドメイン名の国際化(IDNA) 背景、説明、動機付け 要旨 国際化ドメイン名(IDN)のオリジナルプロトコルが完成、普及して数年が経過 した。この間に、新しいバージョンのユニコードを扱えるようシステムを更新 しなければならないなど、多数の問題が生じた。これらの問題の中には、 既存プロトコルやプロトコルが使用する文字データベース表の調整が必要な ものがある。本文書は、改訂後のシステムの概要を示し、各システム要素 (component)の解説資料を提供するものである。 Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are 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/rfc5894. Klensin Informational [Page 1] RFC 5894 IDNA Rationale August 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. 背景情報および概要 . . . . . . . . . . . . . . . . . . . . 4 1.2. 専門用語 . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.1. DNSの「名前」という用語について . . . . . . . . . . . 5 1.2.2. 新しい専門用語および関連する制約 . . . . . . . . . . . 5 1.3. IDNA改訂の目的 . . . . . . . . . . . . . . . . . . . . . . 6 1.4. IDNAの適用性とその機能 . . . . . . . . . . . . . . . . . . 7 1.5. IDNAの仕組みおよび処理の分かりやすさ . . . . . . . . . . . 8 2. IDNA2008におけるドメイン名登録と検索 . . . . . . . . . . . . . 9 3. 許容される文字および認可リスト . . . . . . . . . . . . . . . . 9 3.1. 許容される文字およびラベルの分類モデル . . . . . . . . . . 10 3.1.1. PROTOCOL-VALID . . . . . . . . . . . . . . . . . . . . 10 3.1.2. CONTEXTUAL RULE REQUIRED . . . . . . . . . . . . . . . 11 3.1.2.1. コンテキストの制約 . . . . . . . . . . . . . . . . 11 3.1.2.2. ルールおよびその適用 . . . . . . . . . . . . . . . 12 3.1.3. DISALLOWED . . . . . . . . . . . . . . . . . . . . . . 12 3.1.4. UNASSIGNED . . . . . . . . . . . . . . . . . . . . . . 13 3.2. 登録ポリシー . . . . . . . . . . . . . . . . . . . . . . . 14 Klensin Informational [Page 2] RFC 5894 IDNA Rationale August 2010 3.3. 制約の階層: 文字データベース表, コンテキスト, 登録, アプリケーション . . . . . . . . . . . . . . . . . . . . . 15 4. アプリケーションに関する問題 . . . . . . . . . . . . . . . . . 15 4.1. ディスプレイオーダとネットワークオーダ . . . . . . . . . . 15 4.2. アプリケーションにおけるドメイン名の入力と表示 . . . . . . 16 4.3. 言語学的な期待への対応：合字、二重音字、代替字の扱い . . . 19 4.4. 大文字小文字のマッピングと関連する問題 . . . . . . . . . . 20 4.5. 右から左に表記するテキスト . . . . . . . . . . . . . . . . 21 5. IDNとロバストネス原則 . . . . . . . . . . . . . . . . . . . . 22 6. 検索用フロントエンドインターフェースおよび ユーザインターフェースの処理 . . . . . . . . . . . . . . . . . 22 7. IDNA2003からの移行およびユニコードバージョンの同期 . . . . . . 25 7.1. 設計基準 . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.1.1. IDNAの有効性基準の概要と議論 . . . . . . . . . . . . . 25 7.1.2. 登録におけるラベルの扱い . . . . . . . . . . . . . . . 26 7.1.3. 検索におけるラベルの扱い . . . . . . . . . . . . . . . 27 7.2. 文字解釈の変更 . . . . . . . . . . . . . . . . . . . . . . 28 7.2.1. 解釈の変更が必要な背景: Eszett と Final Sigma の場合 . 28 7.2.2. 解釈の変更が必要な背景: Zero Width Joiner と Zero Width Non-Joiner の場合 . . . . . . . . . . . . . 29 7.2.3. 文字解釈の変更と移行の必要性 . . . . . . . . . . . . . 29 7.2.4. 移行の戦略 . . . . . . . . . . . . . . . . . . . . . . 30 7.3. 文字マッピングの廃止 . . . . . . . . . . . . . . . . . . . 31 7.4. プレフィクス変更に関する論点 . . . . . . . . . . . . . . . 31 7.4.1. プレフィックス変更が必要な条件 . . . . . . . . . . . . 31 7.4.2. プレフィックス変更が不要な条件 . . . . . . . . . . . . 32 7.4.3. プレフィクス変更が意味すること . . . . . . . . . . . . 32 7.5. Stringprepの変更と互換性 . . . . . . . . . . . . . . . . . 33 7.6. 記号に関する論点 . . . . . . . . . . . . . . . . . . . . . 33 7.7. ユニコードバージョンの移行: 未割り当てコードポイントの問題 35 7.8. その他互換性に関する問題 . . . . . . . . . . . . . . . . . 36 8. ネームサーバに関する考慮点 . . . . . . . . . . . . . . . . . . 37 8.1. 非ASCII文字列の処理 . . . . . . . . . . . . . . . . . . . 37 8.2. ルートサーバおよび他のDNSサーバに関する考慮点 . . . . . . 37 9. 国際化に関する考慮点 . . . . . . . . . . . . . . . . . . . . . 38 10. IANAに関する考慮点 . . . . . . . . . . . . . . . . . . . . . . 38 10.1. IDNA文字レジストリ . . . . . . . . . . . . . . . . . . . . 38 10.2. IDNAコンテキストレジストリ . . . . . . . . . . . . . . . . 39 10.3. TLDによるIDN運用のIANAレポジトリ . . . . . . . . . . . . . 39 11. セキュリティに関する考慮点 . . . . . . . . . . . . . . . . . . 39 11.1. IDNAのセキュリティに関する一般的な問題 . . . . . . . . . . 39 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 40 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 14.1. Normative References . . . . . . . . . . . . . . . . . . . 40 14.2. Informative References . . . . . . . . . . . . . . . . . . 41 Klensin Informational [Page 3] RFC 5894 IDNA Rationale August 2010 1. はじめに 1.1. 背景情報および概要 アプリケーションにおけるドメイン名の国際化(IDNA)はインターネット標準の 集合である。クライアントアプリケーションは、IDNAを使用することにより、 ユニコードで表現された何らかのニーモニック文字列を、LDH文法規則 (Definitions 文書[RFC5890]参照)にしたがうものだけで構成された DNSラベルとして有効なACE(ASCII-compatible encoding)形式に 変換することができる。IDNAが使用する固有の形式のACEラベルを「A-ラベル」 と呼ぶ。クライアントは既存のDNSを使用してA-ラベルをそのまま検索できる ので、A-ラベルはDNSの拡張や、DNSサーバまたは低位のクライアントライブラリの 更新を必要としない。A-ラベルは、Punycodeアルゴリズム [RFC3492]が生成した 文字列の前に付加されるプレフィックス「xn--」で認識される。したがって ユーザアプリケーションはA-ラベルを特定し、表示の際にユニコード(または ローカルな文字集合)に変換することができる。 レジストリ側では、IDNAによって国際化ドメイン名(IDN)をA-ラベルとして 登録するサービスが提供可能となる。レジストリは有効なIDNの任意の サブセットだけを提供してもよいし、そのレジストリ固有の背景、状況に あわせて何らかの制限や括り(bundling: ラベルを登録する際に似たラベルを まとめてグループ化して1登録として扱う)を適用してもよい。ラベルの登録は ラベルの検索とは独立に議論されることがあり、またラベルの登録に固有な 幾つかの要件は検索時には適用されない。 DNSクライアントとレジストリは、IDNを扱う際の要件についても差異が 生じやすい。具体的に、レジストリは正確で有効なA-ラベルだけを登録すること が求められるのに対し、DNSクライアントの場合、そのままでは無効なユーザ 入力を有効なA-ラベルにするために何らかのマッピングを行う場合がある。 現在のバージョンは(2008年からIETFの作業を開始したため)IDNA2008として 知られている。これと対比させるため、IDNAの初めのバージョンは2003年に 出版されたことから、ここではIDNA2003と呼ぶことにする。IDNA2003は、 IDNA基本仕様 [RFC3490]、Nameprep [RFC3491]、Punycode [RFC3492]、 Stringprep [RFC3454]の4つの文書から構成される。IDNA2008に関する 一連の文書群は、Punycodeエンコーディングを除けばIDNA2003仕様に 全く依存しない。「IDNA2008」「一連の仕様」「一連の文書群」などの語が 参照するものは、Definitions 文書[RFC5890] に列挙された IDNA2008 に関する 文書の集合全体を指す。A-ラベルとして有効な文字は Tables文書 [RFC5892]で 列挙されたルールで特定されるが、非常に少ない例外を除けば、それらの文字の ユニコード特性から有効性を導き出すこともできる。 伝統的に、DNSラベルは大文字小文字を区別せずに一致照合(match)を行う [RFC1034][RFC1035]。IDNA2003では、大文字を小文字にマッピングする 大文字小文字の文字種統一処理により、この慣例を維持している。しかし、 この文字種統一ルールをある言語に由来して強制すると、別の言語で2つの文字を 別々に扱うことが出来なくなる場合がある。このため、IDNA2008における 大文字小文字を区別しない処理は、IDNA2003とはやや異なる。 Klensin Informational [Page 4] RFC 5894 IDNA Rationale August 2010 IDNA2003はユニコードバージョン3.2のみを使用していた。ユニコードの新しい バージョンで追加された新しい文字に対応するため、IDNA2008は使用するルールを ユニコードのバージョンと切り離す。その代わり、一部例外はあるが、追加された 文字の属性によって、その文字をIDNAで使用できるか、またどのように使用するか が決定される。 本文書は専門用語、背景、ポリシーに関する議論など、IDNA2008に関する 背景情報を提供する。本文書は規定に関する資料を含まない。IDNA2008 プロトコルに準拠する仕様は全て一連の文書群の他の文書に記載されている。 1.2. 専門用語 IDNA2008に関する専門用語は Definitions 文書[RFC5890]に記載がある。 同文書は他にIDNA2008文書群のロードマップ情報も含んでいる。 これらの文書群に記載される定義や概念を把握することなく、本文書を 理解しようとすべきではない。 1.2.1. DNSの「名前」という用語について IDNにおいて、DNSの用語「名前」は若干の混乱を引き起こした。多くの人々が、 DNSラベルのことを様々な言語の単語または成句(phrase)という意味で使用して きたためである。歴史的に、DNSの「名前」の多くは特定の概念、物、組織を 特定するニーモニックのことである。多くの人々は言語に基づいて考えるので、 名前も何らかの言語に根ざしている。しかし、名前はニーモニックであるから、 どの言語の表記の慣習にも従う必要はない。つまり名前が「単語」であることは 要件ではない。 この区別は重要である。IDN活動の妥当なゴールは、DNSのラベル内で クリンゴン語(や誰かが選択した言語)の小説を書けるようにすることではなく、 非常に広範な用字で、できるだけ自然な方法でニーモニックの有効範囲を より便利になるように拡大することだからである。 Klensin Informational [Page 5] RFC 5894 IDNA Rationale August 2010 1.2.2. 新しい専門用語および関連する制約 IDNA2008は新しい専門用語を導入する。「U-ラベル」,「A-ラベル」, LDHラベル(IDNA以前の有効なホスト名は全てこれに準拠している), R-LDHラベル(Reserved LDH), XN-ラベル, 疑似A-ラベル, NR-LDHラベル (Non-Reserved LDH)といった用語の正確な定義は Definitions 文書にある。 加えて、特定の定義上の制約を満たしているように見えるが、その有効性を まだ十分に検証していないラベルを参照するものとして「仮適合(putative) ラベル」という用語を導入する。 この後に記述する定義は、Definitions 文書の図1に例示されているもの である。R-LDHラベルは、ラベルの先頭から数えて3文字目および4文字目 の位置に「--」を含むものである。IDNA対応アプリケーションでは、R-LDHラベルの サブセット、具体的にA-ラベルのサブセットしか使用できない。A-ラベルは、 大文字小文字を区別しない文字列「xn--」で始まるR-LDHラベルのサブセット である。このプレフィックスを持つが、有効でないラベルは「疑似A-ラベル (Fake A-label)」に分類される。NR-LDHラベルはIDNAが規定するラベルとの 類似点がないので、暗黙的に有効である。 R-LDH カテゴリの作成が必要だった理由は以下の3つである。 ・ IDNA以前のコード形式との混同を避けるため ・ そうなる可能性はほとんど無いが(セクション7.4参照)、プレフィックス 変更を必要とする将来の拡張を許容するため ・ Punycodeエンコーディングアルゴリズムそのものを利用した攻撃の機会を 減らすため IDNA2008に関する一連の文書群の他の文書と同様に、本文書もDNSの 任意のゾーンを表現する際に「レジストリ」という用語を使用する。 レジストリと「ゾーン」や「ゾーン管理」という用語は置き換え可能である。 1.3. IDNA改訂の目的 IDNAを改訂する主な目的は以下に示すとおりである。 ・ より新しいバージョンのユニコードを使用すること。IDNAをユニコードの バージョン非依存にし、実装が新しいユニコードバージョンのコード ポイントを導入するためにIDNA2008を更新する必要をなくすこと。 Klensin Informational [Page 6] RFC 5894 IDNA Rationale August 2010 ・ コードポイントを使用するコミュニティで問題があると判明した 非常に少数のコードポイントのカテゴリを修正すること。 ・有効なA-ラベルとするために、マッピングへの依存性を減らすこと。 これにより、様々なコンテキストにマッピングされる前の形式 (無効なIDNAラベル)が現れることが少なくなる。 ・ 双方向表記するコードポイントを扱うアルゴリズムの詳細部分を幾つか 修正すること。 1.4. IDNAの適用性とその機能 IDNA仕様は、ドメイン名で使用可能な文字レパートリーを拡張する問題を、 ユニコードレパートリーの広範なサブセットを仕様に含めることで解決する。 IDNAはDNSを拡張しない。したがって、アプリケーション(暗にユーザも含む)は 完全一致するかどうかを比較照合する検索サービスを今後も使い続ける。 その場合、検索結果は(DNSの基本的要件である大文字小文字を区別しない ASCII一致照合で)完全一致する名前が1つ存在するか、1つも存在しないかの どちらかとなる。このモデルは既存のアプリケーションでうまく機能してきたが、 国際化ドメイン名かどうかに関わらず、ユーザがドメイン名の正確な綴りを 知っており、それをWebブラウザやMUA(mail user agent)等のアプリケーションに タイプ入力する必要がある。より広範な文字レパートリーを導入すると、 特に見た目が同じ文字の場合に綴りを誤る可能性が高まる。例えば名刺に書かれた 文字は、複数のユニコードコードポイントやコードポイントの並びと見た目が 一致する可能性がある。 IDNA標準はアプリケーションに準拠することを求めないし、過去に遡って アプリケーションを変更することも求めない。アプリケーションは既存の インフラストラクチャとの相互運用性を保ちながら、IDNをサポートするために IDNAの使用を選択することができる。アプリケーションが一般に公開される DNSドメイン名で非ASCII文字を使用したいのであれば、本仕様公開時点において IDNAは唯一の選択肢である。既存のアプリケーションにIDNAサポートを 追加するために生じる変更はそのアプリケーションに対するものだけであり、 フロントエンド処理、具体的にはユーザインターフェースには自由度が 残される(セクション6参照)。 IDNに関連する議論の多くは、移行に関する問題と、システム要素全てが IDN対応に更新されていない状態でIDNをどのように機能させるかに焦点を 当ててきた。オリジナルIDNワーキンググループで選択されなかった提案は、 何らかの手法で許容可能な形式またはコーディングでユーザが国際化 ドメイン名を使用できるようにするために、ユーザアプリケーション、 DNSリゾルバ、DNSサーバがIDN対応の更新を要求していた。 それに対し、IDNAはDNSへのアクセス前後に処理が必要だが、DNSプロトコル、 DNSサーバ、ユーザが使用するコンピュータのリゾルバのどれにも変更を 求めない。 Klensin Informational [Page 7] RFC 5894 IDNA Rationale August 2010 IDNAによりIDNの円滑な導入が可能となる。(DNSサーバやMTAなどの)既存 インフラストラクチャの更新せずに済むばかりでなく、非ASCII文字を含む ラベルをASCIIエンコードで表現することにより、アプリケーションで 限定的にIDNを使用できるようになるからである。ASCIIエンコードされた 非ASCIIの名前は、読むのもタイプするのも容易ではないのでユーザ入力には 向かないが、原始的なIDN利用を可能にする最後の手段として使用できる。 例えば、ユーザのコンピュータにおいて対応フォントが存在しないことが わかっている場合、IDNを表示するにはこれが最善の選択だろう。 ユーザに対して使いやすいIDNの入出力機能を提供したり、ある文字を プロトコルが処理するものと等価なものとして受理できるようにするためには、 アプリケーションを本仕様に準拠させるための修正が必要となる。 このバージョンのIDNAは、オリジナルバージョンのIDNAとの継続性を 維持するため、ユニコード文字レパートリーを使用する。 1.5. IDNAの仕組みおよび処理の分かりやすさ IDNA2008の目標の1つに、IDNAがどのように動作し、どの文字が許容され、 それがどのように処理されるのかといった点に関する一般的理解を改善 することが挙げられる。IDNA2008の主目的でもあるマッピングへの依存を 減らすこともこの目標を後押しする。ユーザや登録者が感じる分かりやすさ、 予想しやすさを提供することは、この作業における重要な設計上の目標である。 エンドユーザアプリケーションはこの分かりやすさの向上に重要な 役割を持つ。 国際的な文字を扱うシステムは全て共通の問題に直面する。例えば、ある文字に 対応するフォントが利用できなければ、ユーザインターフェース(UI)はその文字を 表示できない。場合によっては、国際化によりグローバルな画一性(uniformity)を 維持した効果的地域化(localization)が可能だが、それでも普遍性(universality) は失われる。 文字やフォントが利用できない場合、エンドユーザアプリケーション側で どのように対処すべきか提案することは難しい。IDNAを使用するような アプリケーションが表示機能を制御することは稀であるから、そのような 提案が効果を発揮することはほぼ無いだろう。 ローカルな文字集合(local character set)からユニコード正規化形式への 変換が必要な場合、その変換はユーザインターフェース側における一連の 問題の1つである。この変換処理は、内部文字コードシステムとして、 主にユニコードを(またはユニコードだけを)使用するシステムでないものに 複雑さを持ち込む。あるラベルをローカルな文字集合に変換する場合、 ローカルな文字集合側に対応する文字が無かったり、ローカルな文字集合が 異なる文字コード原理(character-coding principle)を持つ場合、情報の損失を 避けるまたは減らすために、ユーザインターフェースに特別な処理(logic)を 追加しなければならないかもしれない。 Klensin Informational [Page 8] RFC 5894 IDNA Rationale August 2010 主に難しい点は、入力される文字セットを正確に判定し、正しい変換処理を 適用することにある。更に難しいのが、ローカルな文字コード体系が使用する 前提とユニコードが使用する前提が異なる場合である。(例えばインド系用字を 出版する際のフォントエンコーディングの選択方法)。ローカル言語や用字の コード体系が、内部的に一貫性があり適切なものであったとしても、これらの 違いにより、曖昧でない変換や解釈を行うことは簡単ではないだろう。 IDNA2008は、文字のマッピングや他の調整に関する責任の所在を、プロトコル (IDNA2003はここに責任があった)からIDNA自身を呼び出す前の前処理に 移している。その目的は、この変更によって完全に有効なA-ラベルまたは U-ラベルが表示、データ通信、データ保存などでより多く使用されるようになり、 分かりやすさと予想しやすさを支援することである。前処理を注意深く検討 すると、前処理で何を行うべきか、前処理を行うと弊害が生じる点は何か、 普遍的な一貫性を持つ前処理アルゴリズムとはどのようなものか、IDNA2003 コンテキストで生成されたラベルとどのように互換性を維持するか、等の問題が 提起される。これらの問題については、セクション6および Mapping 文書 [IDNA2008-Mapping] で議論する。 2. IDNA2008におけるドメイン名登録と検索 IDNA2008は、プロトコル仕様でドメイン名登録と検索(Lookup)を分離して いる(RFC 5891[RFC5891]セクション4および5)。2つの処理の各処理段階は ほとんど同じなのだが、この分離は現在の運用状況、すなわちレジストリ (DNSゾーン)毎に制約や特別な処理を登録時に適用するが、それらは検索時には 適用しないことを反映したものである。もう1つ、この分離の重要な利点として、 特定のユニコードバージョンで処理がフリーズしてしまうのを避けるため、 許容される文字グループを段階的に追加することを容易にできることが 挙げられる。 IDNA2008に対応した実際の登録、検索プロトコルは Protocol 文書 で規定される。 3. 許容される文字および認可リスト IDNA2008は認可制モデル(inclusion model)を採用している。コードポイントは、 ユニコードの特性値に基づくルールの一部としてリストに含まれるか、または 稀な場合に例外として個別にリストに含まれるかのどちらかでない限り、 IDNでの使用は無効である。実装がユニコードの新しいバージョンに移行する 場合、新しいバージョンのルールが新たに有効となったコードポイントを 示すかもしれない。 Klensin Informational [Page 9] RFC 5894 IDNA Rationale August 2010 本セクションは、Tables 文書[RFC5892]のアルゴリズムと文字リストを確立する 際に使用したモデルの概要を提供し、そこで使用されたカテゴリの名前と適用性を 記述する。PROTOCOL-VALIDなカテゴリグループ(セクション3.1.1)に文字が 含まれるからといって、それが直ちにその文字を見境無く使用できることを 意味しないことに注意してもらいたい。ある種の文字は関連するコンテキスト ルールも適用しなければならない。 本セクションの情報は、ルール、文字データベース表、プロトコルの理解を 容易にするために提供される。この非公式な議論に対応する、規定に属する 生成ルールは Tables 文書に記載があり、登録や検索が可能なラベルを 実際に判定するルールは Protocol 文書で得られる。 3.1. 許容される文字およびラベルの分類モデル 認可性モデルに移行するためには、IDNが許容する文字リストに関する新しい 仕様が必要である。IDNA2003では、文字の有効性はコンテキスト非依存で、 永続的に(または標準が変更されるまで)不変だった。しかし、グローバルに コンテキスト非依存なルールは非現実的であることが証明されている。ある文字、 具体的にユニコードの「結合制御文字(Join_Controls)」は、幾つかの用字で 正しく使用されなければならないが、他の用字では何も視覚的な効果を もたらさない。IDNA2003では、このような文字を全て切り捨てることで、 このような文字の使用を禁止していた。現在我々は、特定の条件下において、 ある言語または用字を使用した有用なニーモニックを生成できるようにするため、 これらの「接合子(joiner character)」が正式に必要だとの合意を得ている。 一般に、コンテキスト依存のルールは、異なる用字の間で、異なる使われ方を されるか、または異なる理解をされる文字を処理する際の支援をしたり (この支援が無い場合、一般にこれらの文字全ての使用が禁止される)、文字列が 普遍的に同じ方法で扱われない状況で標準化された処理を適切に適用できる ようにする。 IDNA2008は、全てのユニコードコードポイントを以下の4つに分類する。 すなわち、PROTOCOL-VALID, CONTEXTUAL RULE REQUIRED, DISALLOWED, UNASSIGNED である。 PROTOCOL-VALID(PVALIDと略されることもある）と特定される文字は IDNで許容される。これらの文字の使用について、文字が現れるコンテキストの ルールや文字が含まれるラベル全体に適用される別のルールなどによって 制約を受ける場合がある。例えば「右から左に表記する」特性を持つカテゴリに 属する文字を含むラベルは「Bidi」ルール[RFC5893]のコンテキストで 使用されなければならない。PROTOCOL-VALIDという用語は、このカテゴリに 文字が存在するからといって、例えばこのカテゴリに属する文字だけで名前を 構成したからといって、あらゆるレジストリがその登録を受理しなければ ならないことを意味しないという事実を強調するために使用している。 レジストリは、依然としてラベルを受理するかを審議すること、またその審議に 沿った規則を維持することが期待される(Protocol 文書[RFC5891]および 本文書セクション3.3参照)。 Klensin Informational [Page 10] RFC 5894 IDNA Rationale August 2010 PROTOCOL-VALIDカテゴリに属する文字は、決してそのカテゴリから外されたり、 再分類されたりしないことが期待される。理論的にはユニコードから特定の 文字が削除されることはあり得るが、そのような削除はユニコードの安定性の 原則(UTR 39: ユニコードのセキュリティの仕組み[Unicode52]付録F参照)に 反するので、行われるべきではない。 3.1.2. CONTEXTUAL RULE REQUIRED ある種の文字は、IDNで一般的に使用するには適さないが、特定の用字を適切に サポートするためには必要である。最もよく引用される2つの例として、 ZWJ(ZERO WIDTH JOINER, U+200D)とZWNJ(ZERO WIDTH NON-JOINER, U+200C)が あるが、それ以外の文字でも特別な処理が必要な場合がある。なぜなら、一部の 限定されたコンテキストでは使用できる必要があるが、特別な処理無しでは DISALLOWED になる文字が存在するためである。(典型的な理由はユニコードが それらの文字を句読点または特殊記号と見なすためである)。これらの文字を 使用して誤解を招くラベルを生成したり、ラベルの比較や解釈時に容認できない 曖昧さを引き起こすなどの極度の危険があるため、これらの文字に対しては 特別な処理が行われる。 3.1.2.1. コンテキストの制約 コンテキストの制約を持つ文字は CONTEXTUAL RULE REQUIRED に分類され、 そのルールに関連づけられる。このルールは特定の文字列に含まれる文字は 有効かどうか、またそのルールを登録時だけでなく検索時にも適用 するかを定義する。 結合を指示または禁止する文字およびそれらに類似した文字(CONTEXT-JOINER または CONTEXTJ として知られる)と、コンテキスト処理を必要とするその他の 文字(CONTEXT-OTHER または CONTEXTO)は区別される。前者のみ検索時に 完全なテストを必要とする。 これらのコンテキストルールによって、混乱や問題を引き起こす可能性のある 文字の使用を完全に防げるわけではないことに注意することは重要である。 コンテキストルールに期待されているものは、ゾーン管理者がそれらの文字の 使用に関して十分な知識を持ち、それらの文字を適切に処理するための前処理が 行われている状況において、それらの文字の使用範囲を用字(または、より狭い コンテキスト)内に限定することである。 Klensin Informational [Page 11] RFC 5894 IDNA Rationale August 2010 例えば、文字体系の一部としてZWJやZWNJを必要とするインド系用字を扱う レジストリは、ZWJ(ZWNJ)が視覚的効果を発揮する場所とそうでない場所に関して 理解し、それに基づいて登録ルールを作成することが期待される。 対照的に、ラテン用字やキリル用字を主に扱うレジストリは、おそらくは ZWJ(ZWNJ)のような文字の存在を積極的に意識しないだろう。また、そのような 文字をラテン用字(キリル用字)で構成されたラベルに埋めこんだ場合、 どのような結果になるかという知識をレジストリはほとんど持たないので、 少なくともラテン用字またはキリル用字の文字を使用したラベルに関しては、 ZWJ(ZWNJ)のような文字を含むものを登録することは避けるべきだろう。 3.1.2.2. ルールおよびその適用 ルールは「(この文字は)用字XYZの文字に続けられなければならない」「(この 文字が現れるのは)ラベル全体が用字ABCである場合だけでなければならない」 「(この文字が現れるのは)前後の文字がDFG特性を持つ場合だけでなければ ならない」等の説明(訳注：このルールが検証すべき項目）を持つ。実際の ルールは DEFINED(定義済み)またはNULL(該当なし) となる場合がある。 また、ルールに戻り値が存在する場合、その値は「True」(ラベル内の任意の 場所でその文字を使用可)、「False」(ラベル内でその文字は使用不可)、または その文字が許容されるコンテキストを規定する手続き的ルールの集合などになる。 任意のバージョンの文字データベース表において、ある文字に対するルールが 存在しない場合がある。その理由は、その文字がIDNで本当に必要なのかを判断 したり、そのような文字に対して1つずつ正しいルールを確立する手法を考える よりは、ルールが存在しない文字を特定するだけのほうが容易だからである。 対応するルールを持たない文字は、登録時においても、検索時においても、 仮適合ラベルで使用することは許容されない。もちろん、後に発行される バージョンで何らかのルールが設定されることはあり得る。 実際のルールおよびそのルール内容の説明は、Tables 文書[RFC5892]の セクション2とセクション3に記載がある。また同文書は将来設定される ルール用レジストリの生成に関しても規定している。 3.1.3. DISALLOWED 幾つかの文字はIDNでの使用に適さないので、登録、検索から除外される。 (検索を行うIDNA準拠のアプリケーションは、不適合な文字が存在しないかを 検証すべきである。不適合な文字が含まれてる場合は、ラベル文字列をA-ラベルに 変換して検索を行うのではなく、拒否すべきである)。 不適合な文字は、IDNで使用すると問題を引き起こすもの(例えば FRACTION SLASH 文字, U+2044)もあれば、(基本的に英字、数字の)典型的な識別子の慣習に あわないだけのもの(U+2665, U+2661, U+2765等の様々な HEART 記号。 セクション7.6参照)もある。 Klensin Informational [Page 12] RFC 5894 IDNA Rationale August 2010 もちろん、本カテゴリ(DISALLOWED)は、ユニコードでこれまでに何らかの 文字除外作業が行われていたならば完全に除外されていたであろう コードポイントも含まれる。 DISALLOWED カテゴリに属する文字は、この分類から削除されたり再分類されたり しないことが期待される。ある文字が誤りで DISALLOWED に分類され、その 誤りが対応を要するに充分な問題を生じさせた場合、その問題を解消する方法は、 ユニコードに新しいコードポイントを導入し、それを PROTOCOL-VALID と分類 するか、IETFが互換性のない変更を行う膨大なコストを容認し、関連するRFCを 適切な例外を含むものに置き換えるか、どちらかしかないだろう。 例外的事例に対応する規定は別途存在するが、一般に、ある文字が以下の 1つまたは複数のグループに該当する場合、その文字は DISALLOWED に 属する。 ・ その文字と他の文字が互換等価(compatibility equivalent)になっている。 ユニコード用語でもう少し正確に表現すると、その文字に対してNFKC正規化 処理を行うと別の文字が生成される。 ・ その文字は、ユニコードの大文字小文字変換により別の文字にマッピング される大文字形式または他の形式である。 ・ その文字は、記号、句読点である。より一般的に言えば、英字や数字では なく、英字や数字を構成するために使用する記号でもない何かである。 3.1.4. UNASSIGNED 処理および文字データベース表作成の便宜を図るために、ユニコードの特定 バージョンで値を持たないコードポイントは特別な「UNASSIGNED」カテゴリに 属するものとして扱われる。そのようなコードポイントを登録したり 検索したりするラベルで使用することは禁止される。DISALLOWEDカテゴリとの 違いは、このカテゴリに属するコードポイントは、ユニコードの将来の バージョンで値を割り当てられるという単純な方法によって別のカテゴリに 移動することである。(つまり、その時点で適切な別のカテゴリに区分される)。 UNASSIGNEDなコードポイントを制限する理由は、それらのコードポイントに 実際の文字が割り当てられるまでは、その特性が完全にはわからないことにある。 例えば、UNASSIGNEDなコードポイントが検索されるラベルに含まれていると 仮定する。後にそのコードポイントに対して、何らかのコンテキストルールを 必要とする文字が割り当てられたとする。以上2つの条件が重なるとき、 更新されていないIDNA対応ソフトウェア実装は、以前 UNASSIGNED であった コードポイントを含むラベルの検索を許容するが、同じソフトを更新したものは、 同じラベルの検索をコンテキストルールに応じて制限するかもしれない。 したがって、いかなる場合においても、登録するドメイン名ラベルでの UNASSIGNEDなコードポイント使用を許容すべきではない。 Klensin Informational [Page 13] RFC 5894 IDNA Rationale August 2010 3.2. 登録ポリシー これまでに述べた推奨を使用してレジストリポリシーを定義することは できないし、またすべきでもないが、レジストリは混乱やその他の問題を抑制 するために必要に応じて追加の制限を設定したり適用したりすべきである。 例えば、原則に幾つか重要な例外はあるにせよ、一般に複数の用字の文字を 含むラベルは良くないものだと思われている。レジストリによっては、ごく わずかな数の用字から選ばれた文字だけに登録を制限するかもしれない。 多くの用字に対して、CJK用字に対するJET(Joint Engineering Team)仕様 [RFC3743]やそれを一般化した手法[RFC4290]や、CDNC(Chinese Domain Name Consortium)が提供する中国語用登録表[RFC4713]を使用することで、ユーザが 体感する問題の軽減に役立つだろう。 一般に、レジストリまたはその助言者がよく理解している用字の文字だけを レジストリが許容することがユーザに利益になる。レジストリがポリシーを構築し、 歴史的文字体系や極めて専門的な特別な文脈だけで使用される文字を禁止する ことにより、混乱が生じる機会を減らそうとするのであれば、 [Unicode-UAX31](ユニコード識別子とパターン構文: Unicode Identifier and Pattern Syntax)のセクション2.4(特殊な文字の調整:Specific Character Adjustments)の表4(識別子から除外する文字コード: Candidate Characters for Exclusion from Identifiers)と、[Unicode-UTS39](ユニコードのセキュリティの 仕組み: Unicode Security Mechanisms)のセクション3.1(識別子に関する一般的な セキュリティ概略情報: General Security Profile for Identifiers)などで 関連する情報を得られる。 登録処理でU-ラベル、A-ラベルしか使用できないという要件(Protocol 文書 [RFC5891]のセクション4.1)の意図は、何を登録しようとしているのかについて 登録者が充分理解することを保証することと、正規化形式の使用を奨励すること にある。この要件を「登録者は文字を特定のコードの並びで提供せよと要求して いる」と解釈すべきではない。登録者が行う入力に関する協定とその管理は、 登録者とレジストラ間のやりとりや、レジストリとレジストラ間の関係の一部 であり、本標準の範囲外である。 ポリシーを開発し適用するという原則は、DNSの全てのレベルに適用するもの であり、例えばトップレベルドメイン(TLD)や第2レベルドメイン(SLD)登録時に 限定されるものではないことは強調しておく価値があるだろう。 たとえ「プロトコルで有効なものは全て許容する」という些末なポリシーで あっても、ユーザとアプリケーション開発者が何を求められているかがわかる という点で有用である。 Klensin Informational [Page 14] RFC 5894 IDNA Rationale August 2010 3.3. 制約の階層: 文字データベース表, コンテキスト, 登録, アプリケーション IDNA2008の文字ルールは、IDNに関連する全てのセキュリティの問題、混同 しやすさの問題、その他の問題を一度に解決する魔法のような解決法(magic bullet)は無いという認識に基づいている。その代わり、IDNA2008仕様は様々な アプローチを定義している。第1の仕組みは文字データベース表であり、第2の 仕組みは特定コンテキストにおける文字の適用または制約に関するプロトコル ルールである。そしてこれら2つを組み合わせることで、プロトコルの範囲で できる限界を制定する。先のセクション(セクション3.2)で述べたように、 レジストリは登録する文字を制限することが期待される。具体的に、 ニーモニックに関して、混乱とリスク、表現の最大化のバランスを最適化する ように設計されたルールを考案し、活用することが求められる。 これに加えて、インターフェースプログラムは、ローカルなコンテキストや 慣習に関する知見を踏まえて問題を引き起こしそうなラベル形式に対して 警告を発するという重要な役割がある。もちろん、名前と識別子だけに基づく アプローチで全ての脅威を防御できるわけではない。 4. アプリケーションに関する問題 4.1. ディスプレイオーダとネットワークオーダ ドメイン名は常にネットワークオーダ(通信プロトコルでコードポイントが送信 される順序)で転送される。しかし、異なるディスプレイオーダ(画面や紙媒体に 表示されるコードポイントの順序)になる場合がある。ドメイン名が通常右から 左に表記する文字を含む場合、ネットワークオーダに影響は無いが、ディスプレイ オーダは影響を受ける。1つのドメイン名の中で、左から右に表記する文字と 右から左に表記する文字が隣り合って存在するような場合はより複雑になる。 ディスプレイオーダに関する判断は、最終的にユーザエージェント、つまり Webブラウザ、メールクライアント、ホスト上で動作するWebアプリケーション、 その他多くの高度に地域化(localize)されたプログラムの管理下にある。 判断とは例えば、ドメイン名 abc.def のどちらのラベルも右から左に表記する 用字で記述されている場合、fed.cba と表示すべきか、cba.fed と表示すべきか といったものを指す。現時点で普及しているアプリケーションは、既にこの判断が 分かれているので、どちらの判断についてもそれを採用したアプリケーション例を 見つけることができる。 IDNがIRI(Internationalized Resource Identifier: 国際化URI)[RFC3987]の中に 現れる場合には、また状況が変わる。IRIや国際化E-Mailアドレスは、ドメイン名 以外の要素を含む。例えば、IRIは「http://」や「mailto:」のようにプロトコル 識別子とデリミタを含むし、E-Mailアドレスはドメイン名とlocal-partを区切る ために「@」を含んでいる。ネットワークオーダのIRIは「http://」で始まり、 ネットワークオーダのドメイン名ラベルが続く。したがって「http://abc.def」 となる。 Klensin Informational [Page 15] RFC 5894 IDNA Rationale August 2010 ユーザインターフェースはIRIを表示したり、IRIを直接入力できることを 求められてはいないが、大抵そのようにしている。実装者は、IRIまたは E-Mailアドレスとして入力されるこれらの文字列の全体的な方向を常に左から右 (または右から左)に設定するかどうかを選択しなければならない。右から左に 表記する文字体系において、ドメイン名「a b c . d e f」の順に入力した ユーザにとって、自然に見える表示順序は「fed.cba」である。そうだとすれば、 右から左に表記する文字体系(RTL)に対応したユーザインターフェースは、 その文字体系のドメイン名が入力される毎にそれを入力とは逆の順序で 表示すべきだろうか？また、もしユーザがドメイン名を入力する直前に 「http://」と入力した場合、ユーザがネットワークオーダのIRIで 入力を開始したと見なして処理を変更すべきだろうか？1980年代、1990年代は、 ドメイン名ラベルがネットワークオーダ(左から右)で読まれるものと、右から左に 読まれるものが混在していた。その経験から、上記のようにした場合、多大な 混乱を招くことが予想される。 各アプリケーションの様々な実装で個別にこの問題の判断を行う場合、ユーザは 経験則を培い、それに基づいてアプリケーションを切り替えるようになるだろうが、 それが常に上手くいくとは限らないだろう。各アプリケーションが自由意志で ディスプレイオーダの慣習を採用することは、混乱の抑制には望ましい。しかし、 そのような提言を行うことはIDNA2008の一連の仕様の範囲外である。 4.2. アプリケーションにおけるドメイン名の入力と表示 アプリケーションはどのような文字セット、文字コード体系でも入力を受理し、 表示することができる。IDNAはユーザ～アプリケーション間のインターフェースに 必ずしも影響するわけではない。IDNA対応アプリケーションは2つの形式の国際化 ドメイン名の入力を受理し表示することができる。1つめはアプリケーションが サポートする国際化文字セット(適切にローカル化されたU-ラベル)で、 もう1つはA-ラベルである。アプリケーションはA-ラベルの表示ができてもよいが、 特殊用途向けインターフェース、例えばデバッグや表示の制約に対応する インターフェースなどを除いて、A-ラベルを表示しないことが推奨される。 一般に、ユーザからのA-ラベルの入力は許容すべきだが推奨されない。A-ラベルは 不明瞭で見難く、悪意を持った派生物をユーザが見分けることは容易でない。 したがって、可能であれば、A-ラベルを露出させるのはそれがどうしても 必要な場合に限るべきである。IDNラベルはA-ラベルでもU-ラベルでも表示できる ので、アプリケーションにユーザが望む表示方法を選択できるオプションが あってもよい。通常の場合、U-ラベルの表示をデフォルトにすべきである。 ドメイン名は多くの場所で保存され、転送される。例えば、ドメイン名は メールのメッセージやWebページなどの文書の一部である。ドメイン名は多くの プロトコルの、多くの場所で転送される。例えばSMTPでは制御コメントと関連する メッセージボディ部分の両方で、またHTTPではヘッダとボディの両方でそれぞれ 転送される。ドメイン名は、ドメイン名スロットの中と、プロトコルで転送 されるコンテンツ内の両方に現れることを思い出すことは重要であり、 プロトコルが明示的にプロトコルのドメイン名スロットは何かを定義する場合に 役に立つだろう。 Klensin Informational [Page 16] RFC 5894 IDNA Rationale August 2010 IDNA2008仕様をどう処理するか、または文字セットのネゴシエーション方式が 定義済みのプロトコルや文書形式では、ラベルはプロトコルまたは文書形式が 許容する任意の文字セットにエンコードすることができる。プロトコルまたは 文書形式が許容する文字セットが1つだけの場合、ラベルはその文字セットで 与えられなければならない。もちろん、全ての文字セットで任意のラベルを 適切に表現できるわけではない。U-ラベルをそのまま表示できない場合、 (情報の損失がない)唯一の選択肢はA-ラベルを表示することだろう。 プロトコルまたは文書形式がIDNを許容する場合、ローカルな環境で使用されて いる文字エンコーディングや、プロトコルや文書フォーマットで使用される エスケープの仕組みがどのようなものであれ、ラベルはそれにあわせる べきである。この規定の意図は、例えばUTF-8のドメイン名が他の文字コードの テキスト文書に埋め込まれてしまうような状況を抑制することにある。 ドメイン名スロット(Definitions 文書[RFC5890]のセクション2.3.1.6参照)を 使用する全てのプロトコルは、既にドメイン名をASCII文字セットで処理する 機能を持っている。したがって、それらのプロトコルは本質的にA-ラベルを 処理することができる。 IDNA2008は、ある文字またはコードポイントから別のものへの必須のマッピングを 規定していない。マッピングに関する問題の詳細な議論はセクション6に記載が あり、Mapping 文書 [IDNA2008-Mapping]には固有の推奨事項も示されている。 基本的に、IDNA2008は正規化またはその他のルールによって別の文字にマッピング されるような文字を禁止している。例えば、ラテン文字の数学記号はIDNA2003では 許容されたが、IDNA2008では禁止される。同様に、大文字の文字、倍幅文字と その他の派生文字は、必要に応じてユーザインターフェースでマッピングを 行うことが強く推奨されているものの、IDNAへの入力としては禁止される。 Tables 文書[RFC5892]のルールには、NFKCによって変換されない文字列だけが 有効になる効果があるので、アプリケーションが検索前にNFKC正規化の 実行を選択しても、その処理によって有効な文字列を検索できなくなることは ないので安全である。しかし、先に論じたように、NFKC正規化を行う アプリケーションも他のアプリケーションが同様の正規化(マッピング)を 行うことを保証できないので、NFKC正規化は知識のあるユーザに対して、 あらかじめ正規化処理を行う旨警告を発した後にだけ使用すべきである。 Klensin Informational [Page 17] RFC 5894 IDNA Rationale August 2010 多くの場合、これらの禁止事項はユーザが検索処理に対して何を入力 できるかに何も影響を及ぼさないはずだ。ローカルな環境に適合するような 文字のマッピングを実行するユーザーインターフェースをシステムがサポート することは極めて理に適っているからである。通常の場合、IDNAを実際に 呼び出す前にマッピングが実行される。少なくとも、概念的には、 マッピングは Protocol 文書[RFC5891]や先の議論で述べたユニコード変換の 一部である。しかし、これらの変更はローカルなマッピングである。つまり、 ユーザがマッピング前後の文字の見た目が等価な物であると明確に理解できる 環境に閉じた変換である。システム間のやりとりの中でマッピングを使用する 場合、U-ラベルとA-ラベルが情報を失うことなく相互にマッピングできると いうことが極めて重要な意味を持つようになるだろう。 この戦略の具体的な、また極めて重要な例として大文字小文字の文字種統一 (case folding)が挙げられる。ASCII文字のみを対象としていたDNSでは、名前は 大文字小文字を区別せずに検索や一致照合が行われ、具体的な大文字小文字の 文字種統一処理は行われない。名前は大文字でも小文字でも(それらが 混在した形式でも)DNS空間内に登録することができ、その文字種情報は維持 される。その文字種のままで問い合わせに応答が返されたりするということ である。IDNA2003では、登録時に大文字小文字の文字種統一を行い(この結果、 小文字のIDNだけがDNSに登録される)、また検索時にも文字種統一を行う ことによって、非ASCII文字のDNSの振る舞いを従来のものに近づけた。 本セクション前半で示唆したように、ユニコードが正しく機能する限り、 マッピングを行う文字を可能な限り減らすことは、A-ラベルとU-ラベルの マッピングを冪等(訳注: 何度行っても同じ結果になる)にするために望ましいと 思われる。(同じ文字に対する異なるコーディングを解決するNFCマッピング は、IDNA2008仕様でプロトコル呼び出し前に実行することが要求されているが、 依然として必要である)。大文字小文字のマッピングもこの原則の例外ではない。 小文字の文字しかDNSに登録できない場合(言い換えると、小文字の文字しか U-ラベルに存在できない場合)、アプリケーションのユーザーインターフェースで 大文字は小文字にマッピングされるだろうが、IDNA2008は大文字の入力を禁止 すべきである。他にもこの結論を支持する考慮点がある。例えば、個々の文字に 対するASCIIの大文字小文字マッピングの場合、uppercase(character) は uppercase(lowercase(character)) と常に等しくなる。しかし、IDNでは これが真ではない場合がある。大文字と小文字が異なる用字の中には、大文字 または小文字に対応する文字のない文字が2,3存在する場合がある。大文字と 小文字の関係は言語に依存するものであり、言語が異なれば(同じ言語であっても 地域が異なれば)異なるマッピングが期待されるものである。 ユーザエージェントは、IDNA処理前に大文字小文字の文字種統一を行うことで、 大文字小文字を区別しないDNS環境に慣れたユーザの期待に沿うことができる。 しかし、文字種統一がローカルな環境で自然でない場合、IDNA処理はそのような マッピングを要求したり期待したりすべきではない。 Klensin Informational [Page 18] RFC 5894 IDNA Rationale August 2010 4.3. 言語学的な期待への対応：合字、二重音字、代替字の扱い ユーザは、文字が彼らの自国語とその正字法に照らして同一または等価である ことを期待する。グローバルに動作する仕組みではこのような期待が常に 満たされるわけではない。特に同じ用字を使用する複数の言語で、それぞれ 異なる用字の慣習を持つ場合には期待が満たされることはない。以下にその例を 示す。 ・ ノルウェーのユーザはaeの合字(ae-ligature)を含むラベルが a分音記号 (a-diaeresis)を持つスウェーデン式つづり法を使用したラベルと同じものと して処理されることを期待するかもしれない。しかし、英語にマッピング すると、ユーザにとって驚くような結果になってしまう。 ・ ドイツのユーザはoウムラウトを含むラベルと、その部分が「oe」に置き換え られた以外は同じラベルを等価なものだと期待するかもしれない。しかし その置き換えはスウェーデン語で明らかな誤りとなってしまう。 ・ 中国のユーザは、中国語の簡体字と繁体字が自動的に一致することを 期待するかもしれない。しかし、韓国語や日本語のテキストでその一致を 行うと、深刻な混乱を引き起こしてしまうだろう。 ・ 英国のユーザは「theater」と「theatre」が一致することを期待するかも しれない。 多くの言語はアルファベット式の用字を使用する。そこでは単一の音素が 「二重音字」と称する2文字で表記される場合がある。例えば「pharmacy」 「telephone」の「ph」がそれにあたる。(これらの文字は「tophat」のように、 二重音字を形成せずに連続して現れることもある)。特定の二重音字の場合、 印刷時に、異なる音素を連続して表現する場合の文字間に比べて、二重音字の 場合は2文字の文字間を近づけることで二重音字であることを示す場合がある。 幾つかの二重音字は結合して合字になっている。例えば、「encyclopaedia」と いう単語に U+00E6 LATIN SMALL LIGATURE AE が使われることがある。 合字や二重音字形式が任意の用字を使用する全ての言語で同じ解釈をされる のであれば、ユニコード正規化を適用することにより、一般に用字の習慣の差異は 解消され、それらを一致させられる。しかし、異なる解釈がなされる場合には、 一致照合は別の手法を使用しなければならない(おそらくそれはレジストリレベルで 選択される)。あるいは、そのような一致照合は行われないことをユーザが 理解するよう啓発に努めなければならない。 この問題の本質を、ノルウェー語の多くの単語を用いて例示することができる。 ノルウェー語はラテン文字アルファベットを拡張して29の英字が存在し、 「ae」の合字はその27番目の英字である。この文字はスウェーデン語 アルファベット(やはり29の英字を持つ)の28番目の英字、U+00E4 LATIN SMALL LETTER A WITH DIAERESISと等価である。しかし、現行の正字法標準によると、 この文字を「ae」で代用することはできない。この文字(U+00E4)はドイツ語 アルファベットの一部でもある。ドイツ語はノルウェー語やスウェーデン語 といった北欧系言語とは異なり、「ae」という2文字の並びは、通常の場合、 完全に受け入れられている代替正字法の「aウムラウト」として処理される。 しかし、この逆は真ではなく、また必ずこの2文字を組み合わせて「aウムラウト」 にしなければならないわけでもない。(訳注: 次ページ先頭に続く） Klensin Informational [Page 19] RFC 5894 IDNA Rationale August 2010 このことは他のドイツ語文字にも当てはまる。(訳注: 通常 oe の2文字は oウムラウトの代替文字として使用されるが)、文学者「Goethe」の名前を 記述する場合に「oウムラウト」 (U+00F6 LATIN SMALL LETTER O WITH DIAERESIS) は使えない。同様の事例はスウェーデン語アルファベットにもある。 「分音記号付きa」は、ノルウェー語アルファベットの「oe」では正確に表現 できない。ノルウェー語アルファベットでは「分音記号付きo」ではなく 「スラッシュ付きo」(U+00F8)として表現される。 ユニコードで明示的なコードポイントを持つ合字の幾つかは、IDNA2003で特別な 処理がなされていたが、これがIDNA2008への移行でさらなる問題を引き起こして いる。セクション7.2参照のこと。 右から左に表記するアルファベットに関する付加的な事例については セクション4.5に記述がある。 比較照合アルゴリズムの選択に際し、使用されている言語やコンテキスト、 あるいはその両方の情報が必要となることがあるが、IDNAやDNSはこれらの情報を 利用できない。このため、IDNA2008は組み合わせ文字に対する特別な処理は 行っていない。登録されるラベルで使用される言語コンテキストを知る レジストリは、その言語において2文字の並びが時として(または常に)それを 組み合わせた文字と等価になることを理解しているはずである。したがって、 異なる登録者がそれぞれ類似した文字列を登録することに起因するユーザの混乱や 不正の機会を減らすために、「異体字」モデル[RFC3743][RFC4290]を適用 するのか、特定の文字形式全ての登録を禁止するのかなどについて真剣な考察を すべきである。 4.4. 大文字小文字のマッピングと関連する問題 DNSではASCII英字は大文字小文字の情報付きで保存される。問い合わせ処理に おける一致照合は大文字小文字を区別せず行うが、どちらの文字種を選択したと しても情報が失われることはない。このモデルは偶然にも役立ってきた。単語 (または単語の一部)をつなぎ合わせてDNSラベルを生成する場合、違う文字種を 使用して構成要素の境界を際立たせたり、ラベルを覚えやすくするなどされて きたからである。 DNSサーバはIDNの構文解析に関与しないので、IDNに対して大文字小文字を 区別しない一致照合を行うことができない。したがって、IDNAや類似の アプローチを使用する場合、検索時や登録時には大文字小文字を 別のものとして扱い、サーバ上でそれを前提にした一致照合を行うことは 実現不可能である。もしそれを望むのであれば、ASCII文字のみを対象とする DNSクライアントがそれを行ってこなかったとしても、IDNA検索を実行する プログラムは、大文字小文字の文字種が異なるだけの場合でも別のものとして 扱うような文字の一致照合を実行しなければならない。この状況はIDNA2003の 段階で認識されており、IDNA2008でも基本的には何も変わっておらず、 また変えられなかった部分である。IDNA2003では、全ての文字は大文字小文字の 文字種統一が行われ、標準化された処理手順でクライアントによるマッピングが 行われていた。 Klensin Informational [Page 20] RFC 5894 IDNA Rationale August 2010 用字が大文字小文字の区別を一般的にサポートする場合においてさえ、 幾つかの文字は大文字形式を持たない。例えば、ユニコードの大文字小文字統一 処理は、Greek Final Form Sigma (U+03C2)を中間形式(U+03C3)にマッピングし、 Eszett (German Sharp S, U+00DF) を「ss」にマッピングする。 これらは逆方向のマッピングはできない。U+03C3に対応する大文字は Upper Case Sigma (U+03A3) であり、「ss」はASCII文字列だからである。IDNA2008は、 互換性が若干損なわれることと引き替えに、大文字小文字の文字種統一を行わずに 文字をそのままの形で扱うことにより、この辺りの処理をやや柔軟に行うことが できるようになっている。一方向マッピングを扱うアプローチについては セクション7.2で論じる。 IDNA2003は Final Sigma や Eszett を他の文字にマッピングするが、逆方向の マッピングはできないので、Final Sigma も Eszett もIDNA2003 IDNのACE形式や ACE形式から導出される通常の文字(U-ラベル)では表現できない。 IDNA2008では、どちらの文字もIDNで使用可能であり、それらの文字を含む U-ラベルを検索するためにA-ラベルが使用できるという点でIDNA2003とは 異なる。IDNAプレフィックスを変更するにはどのような変更が要求されるかに ついての議論はセクション7.1参照のこと。詳細な議論の後、IDNABISワーキング グループは、従来扱えなかったが新たに扱えるようになる文字が存在する というだけではプレフィックスの変更を正当化できないという合意に達した。 4.5. 右から左に表記するテキスト 右から左に表記するテキストの方向性が明確なことを保証するため、IDNA2003は 右から左に表記する文字を含むラベルは、その初めと終わりにその文字がなければ ならず、また左から右に表記する強い特性を持つ文字を含まないことを要求 している。(これによりヨーロッパ数字は許容されるが他のアルファベット文字は 排除された)。右から左に表記する文字を含むが、この要件を満たさない文字列は 全て拒否される。これはIDNAアルゴリズム(IDNA2003とIDNA2008の両方)が個々の 文字ではなく、ラベル全体をテストする数少ない場合の1つである。IDNA2003が 使用するアルゴリズムでは、右から左に表記する文字列の末尾の文字を正確に 表現するために結合記号が必要な場合、その文字列は拒否される。 この禁止事項は、発音で母音を区別する、単子音文字で表記する言語用の 文字体系や、結合記号が異なる機能を持つ場合がある正字法を持つ言語用の 文字体系では受け入れられない。どちらの場合も、結合記号は正字法の 本質的要素になり得る。この例として、拡張ヘブライ文字で表記される イディッシュ語、(アラビア文字に由来する)ターナ文字で表記するディベヒ語 (モルジブの公用語)などが挙げられる。IDNA2008は、右から左に表記する用字 および文字用ルールを新たに導入することにより、末尾の結合記号に関する 制約を取り除いている。この新しいルールは Bidi 文書[RFC5893]で規定される。 Klensin Informational [Page 21] RFC 5894 IDNA Rationale August 2010 5. IDNとロバストネス原則 「ロバストネス原則(Robustness Principle)」は、よく「送信には保守的で あれ、受信には寛容であれ」と説明される。(例えばインターネットホストの アプリケーションとサポートに関する要求仕様[RFC1123]のセクション1.2.2参照)。 この原則をIDNAにも適用する。登録、使用されているIDN全てのレジストリを 送信元(発信者)と見なしてこの原則を適用すると、レジストリは何を登録し、 インターネットに何を公開するかについて保守的でいる責任がある。 IDNがうまく機能するために、ゾーン管理者(レジストリ)は何を登録するかに 関する賢明なポリシー、つまり保守的なポリシーを必要とし、持たなければ ならない。その上でそのポリシーを実装し、施行しなければならない。 逆に、検索アプリケーションに期待されることは、グローバル(に動作する プロトコルの)ルール(プロトコルが定めた書式など)を明らかに侵害するラベルを 拒否することである。(受信に対して寛容であるためには愚鈍であることが 求められることについて、これまで誰も真剣に論じていない)。 しかし、受信したラベルがプロトコルの定めた書式の要件を満たしているならば、 そのラベルが保持する用字やロケールにセンシティブな事項を処理するためには、 DNS空間内にゴミ情報がないと仮定する必要がある。つまり、DNSで検索する名前に ついて寛容でなければならない(検索対象の名前を登録することが適切であったか について推量してはならない)。 ここで述べた検索処理を行った後に、DNS内で検索対象の文字列を発見 できない場合、その名前が単に登録されていないだけなのか、レジストリが 制定した何らかのルールで禁止されているのか区別がつけられない。 アプリケーション実装者は、DNSワイルドカードが使用されている場合、 名前解決に成功することがその名前が実際に登録されていることを保証しない ことに留意すべきである。 6. 検索用フロントエンドインターフェースおよびユーザインターフェース の処理 ドメイン名は様々な文脈で特定、処理される。ドメイン名はユーザによって 直接タイプ入力されるか、E-MailアドレスやURI, IRI等の識別子に埋め込まれた ものから入力される。また文中に現れることもあるし、あるシステムが提供する ドメイン名を別のシステムが処理するような場合もある。システムは、参照が 有効かどうか、または2つの参照先が同一のオブジェクトを指していないかどうか について、具体的な検索無しで判定(推測)するために、URLの正規化を試みる かもしれない。(名前解決されることを想定していないURIタイプは検索せずに 比較しなければならない)。これらの目標の幾つかは他のものよりも容易かつ 確実に達成できるかもしれない。「ネットワークを流れる(on the wire)」、 つまりシステム間で転送されるドメイン名は全て曖昧さが全くないA-ラベル形式 にすべきであるという強硬な意見が出ているが、ドメイン名を処理する プログラムがU-ラベルやその派生形式に遭遇することは避けられない。 Klensin Informational [Page 22] RFC 5894 IDNA Rationale August 2010 IDNAプロトコル[RFC5891]を実装するアプリケーションは、常にユーザの あらゆる入力を受け付け、それをユニコードコードポイントに変換する。 ユーザの入力は様々な異なる入力方式を経て得られるが、それぞれ適した 変換処理を行うことを考慮すべきである(入力方式としては、キーボードからの 入力、デジタイザなどへの手書き入力、マイクに話した内容を翻訳エンジンで 解釈して入力を得るなどが挙げられる)。任意のユーザ入力を得て、それを ユニコードコードポイントにマッピングする処理は簡単なものである。 ユーザがUS英語キーボードで「Shift」などの修飾キー操作なしで「A」キーを 押下した場合、ラテン小文字のA(「a」)を表示するために、多くの(おそらく ほぼ全ての)現代的OSの入力方式では、呼び出し元のアプリケーションに対して、 1オクテットでエンコードされたコードポイント U+0061 を発行するだろう。 この処理が若干複雑になることもある。ユーザがラテン小文字A上に長音符を 持つ文字を表示するために、「A」キーを押下した後に COMBINING MACRON を 表現しようとして複数キーを同時に押下するような場合である。 その結果はOS、ユーザが選択した入力方式、アプリケーションが入力方式と やりとりするパラメータなどに依存する。得られる結果はコードポイント U+0101 (2オクテットのUTF-8またはUTF-16, 4オクテットのUTF-32等でエンコードされる)、 コードポイント U+0061にコードポイント U+0304 が続くもの(使用するエンコード 方式に応じて3オクテット以上でエンコードされる)、コードポイント U+FF41 に コードポイント U+0304 (何らかの形式でエンコードされる)などになるだろう。 この例では、文字セットとしてユニコードコードポイントを使用しないOSや 入力方式の問題は一旦無視している。 いずれの場合も、アプリケーションは(OSは入力方式の補助を得ながら)ユーザの 入力からユニコードコードポイントへのマッピングを実行する必要がある。 IDNA2003で使用されていたモデルは、ユーザからの入力を受け取り、 (その何らかの使用入力方式によって)ユニコードコードポイントに マッピングし、その後さらにNameprepのプロファイル(profile: 具体的な 適用法の定義)[RFC3491]を使用してユニコードコードポイントにマッピングする というものである。この処理では、独立した2段階のマッピングを行う。 第1段階は入力方式が行うマッピングで(これはOS、アプリケーションまたは それらの組合せによって制御される)、第2段階はIDNAプロトコルの Nameprep処理部分が行うマッピングである。Nameprepが行うマッピングでは、 マッピング表を使用した特定の文字から別の文字への再マッピング、 特定の正規化処理、禁止文字セットの適用などを行う。 Klensin Informational [Page 23] RFC 5894 IDNA Rationale August 2010 2段階でマッピング処理を行う結果、OSまたはアプリケーションが選択する 第1段階のマッピング結果と、Nameprepプロファイルによって提供される 第2段階のマッピング結果が大きく異なる可能性があることに注意して もらいたい。これには良い点もあれば悪い点もある。 第2段階のマッピングはDNSで検索される名前を正規化するので、 Nameprepマッピングを使用する実装間の相互運用性を向上させることは 言うまでもない。しかし、アプリケーションやOSは自分の入力方式で マッピングを選択する場合があり、それが第2段階(Nameprep)のマッピングに 渡されると、エンドユーザが「思いもかけない」文字になってしまう。 他にも、IDNA2003の重要な特性として、ごく少数の例外はあるが、 Nameprepマッピングに入力されるユニコードコードポイントは 全て「意味のある(sensible)」ユニコードコードポイントの文字列にマッピング できると仮定していることが挙げられる。たとえ、あるコードポイントを無に マッピングするとしても、それは文字列から特定のコードポイントを削除する ことを意味する。これにより、入力文字列に最大限の柔軟性が与えられた。 現行バージョンのIDNA(IDNA2008)は、オリジナルバージョンのIDNAと そのアプローチに大きな違いがある。何よりもまず、現行バージョンは 明示的なマッピングの指示をしていない。その代わり、アプリケーションが (おそらくはOSの入力方式を経由して)入力をユニコードコードポイントに 変換するために必要な何らかのマッピングを行うと想定している。 この方式には、アプリケーションがユーザ固有の要件にあわせて柔軟に マッピングを選択でき、オリジナルプロトコルの2段階のマッピングを 回避できるという利点がある。IDNA2008は、マッピングの代わりに、 ドメイン名での使用が許容される有効なコードポイントを規定するために 使用可能なカテゴリ群を提供する。 原則として、アプリケーションはユーザからのドメイン名入力を受け付け、 ユーザが意図したドメイン名を表現するユニコードコードポイントに変換すべき である。もちろん、実際問題としてユーザの意図を判定するのは面倒な作業 であるから、アプリケーションはユーザの入力から妥当なマッピングを 選択する必要がある。選択されるべきマッピングは、ユーザの置かれている 特定の状況に基づいて、ロケールや言語、入力方式の種別などに依存して 変わるだろう。妥当な選択をできるかはアプリケーション次第である。 Klensin Informational [Page 24] RFC 5894 IDNA Rationale August 2010 7. IDNA2003からの移行およびユニコードバージョンの同期 7.1. 設計基準 上記および「IDNに関するIABの審査と推奨」[RFC4690]でも述べられているが、 IDNA2008の設計における重要な2つの目標は以下のとおりである。 ・ アプリケーションが、自分が動作している環境がユニコード3.2以降の バージョンに対応しているか知らなくてもよいようにすること。 ・ 新しい文字、文字グループ、用字、その他の文字集合がユニコードに 組み込まれたとき、混乱することなく徐々にそれをIDNAに追加できるように すること。長期的にはIETFの合意形成過程を経ることなくそれが実現できる ようにすること。(IDNA2008仕様ではIETFの合意形成過程を経ることを要求 している。IDNAの運用とユニコードの新バージョンに関して充分な経験が 蓄積されるまではこの状況は変わらないだろう)。 7.1.1. IDNAの有効性基準の概要と議論 IDNAにおいてラベルが有効であると判断される一般的な基準は以下のとおり である。(実際のルールは Protocol 文書[RFC5891]と Tables 文書[RFC5892]で 厳密に定義されている)。 ・ ラベルを構成する文字が、何らかの言語で単語を表記するために使用する 英字、英字に必要な記号(mark)、数字、その他コードポイントで構成されて いること。また、記号、罫線文字(drawing character)、様々な表記記号 は常に意図的に除外されていること。 除外された各種記号が一般的な原則である「英字,数字,ハイフン」で構成 されたドメイン名の拡張を正当化するほどにインターネットの運用や ドメイン名の国際化にとって重要であるという根拠は無い。 (この記号に関する判断の追加の議論と理由づけがセクション7.6で 得られる。) ・ 句読点が除外されていること。ただし、ある言語において、ほぼ全ての 単語を表記するために必要となるような特別な事例は除く。句読点が 必要な単語が存在するという事実のみでは、句読点をDNSラベルで使用 すべきだという証拠にはならない。複数の単語で構成された語句として DNSラベルを使用できることは期待されていない。(しかし、特定の言語の 慣習や正字法によってそのようなことが可能な場合には、確かに句読点は 禁止されない)。 ・ レジストリやアプリケーションが使用するユニコードのバージョンにおける 未割り当て文字(割り当てられている文字が無いコードポイント)が使用されて いないこと。この条件は登録されるラベルだけではなく、検索される ラベルにも適用される。この判断を必要とした問題についてはセクション7.7 で論じる。 Klensin Informational [Page 25] RFC 5894 IDNA Rationale August 2010 ・ 現行バージョンのNFKCによって他の文字にマッピングされる文字をIDNAに 入力することは(登録、検索のどちらの場合も)禁止である。 若干の例外を除き、Nameprep[RFC3491] によって他の文字にマッピングされる 文字は、この原則により全て除外される。 上で述べた原則が Tables 文書で詳細に規定されたルール設計を推進した。 これらのルールがIDNAで有効な文字を特定する。ルール自体が規定であり、 文字データベース表はルールから導出される。文字データベース表からルールを 作ったわけではない。 7.1.2. 登録におけるラベルの扱い アプリケーションが意図通りに動作するためには、DNSゾーンに登録されている ラベルは全て有効性検証済でなければならない。つまり、そのラベルが 満たすべき基準を全て満たしているかが検証されていなければならない。 この原則は新しいものではない。DNSが初めて導入された時から、登録される 名前が「ホスト名」の要件[RFC0952]、つまりアプリケーションが期待する要件を 満たしているかを、ゾーン管理者が検証することが期待されてきた。 別のアプリケーションの文脈、例えば特殊なSRV(service location)書式が後に DNSに追加されるなどにより、ゾーン管理者に新たな要件が追加されている。 IDNを登録予定のゾーンがユニコードのバージョンに依存しない対応をするため には、ゾーンに登録される全ての文字列に対して制約を課す必要がある。 具体的に、IDNを登録予定のゾーンには以下の制約が課される。(正確なルールは Protocol 文書[RFC5891]のセクション4に記載がある)。 ・ A-ラベルのように見える全てのラベル、具体的に「xn--」で始まるラベルは 全てIDNAで有効でなければならない。つまり、それらのラベルはセクション2 で議論されたような有効なA-ラベルでなければならない。 ・ 登録するラベルの有効性検証を実行するシステムでは、ユニコードの文字 データベース表(コードポイント、文字クラス、特性値の表)とIDNAの文字 データベース表(「Tables」文書に記載があるようなコンテキストルールの表) が整合していなければならない。ユニコードの最新バージョンの文字データ ベース表を反映させるよう要求していないことに注意してもらいたい。 ただ単にシステム上で使用される全ての文字データベース表が整合していれば よい。 このモデルでは、新しい用字または文字セットを使用できるようにするために、 レジストリが使用する文字データベース表を(ユニコード文字データベース表と 許容されるIDN文字データベース表のどちらも)更新する必要がある。 レジストリが対応を望まない限り、ユニコードの新しいバージョンやIDNで新たに 認可された文字はレジストリに影響を与えない。ゾーン管理者はIDNAだけでは なく、ローカルポリシーの有効性も検証する責任を持つ。レジストリがラベルの 登録に関して設定するローカルポリシーは、ラベルの検索時に必要な検査 よりも多岐に渡る検査になる。DNSラベル、特にIDNラベルをを検索または 名前解決するシステムは、DNSに登録された名前は適切なルールを順守していると 仮定できなければならない。 Klensin Informational [Page 26] RFC 5894 IDNA Rationale August 2010 7.1.3. 検索におけるラベルの扱い IDNAを通してラベルを処理し、DNSゾーンの検索を行う全アプリケーションは、 以下の事柄が要求される。(正確なルールは Protocol 文書[RFC5891]の セクション5に記載がある)。 ・ IDNAとユニコードの文字データベース表について、バージョンの整合性を維持 すること。アプリケーションが Tables 文書[RFC5892]の分類ルールを実行する のでなければ、アプリケーションが使用するIDNA文字データベース表は、 システムがサポートするユニコードのバージョンから導出されたもので なければならない。登録の場合と同様に、文字データベース表がユニコードの 最新バージョンを反映する必要はないが、2つの文字データベース表が 整合していなければならない。 ・ 検索されるラベルに含まれる文字の有効性検証を行うこと。ただし、 検証内容は、U-ラベルがユニコードのバージョンで「DISALLOWED」になって いないか、または未割り当てコードポイントを含んでいないかだけでよい。 ・ ラベルがラベル全体に関する少数のルールに準拠しているか検証すること。 具体的に、以下の事柄について検証を行う。 - 結合記号がラベル先頭に存在しないこと - 右から左に表記する文字を含む場合 Bidi 条件に準拠していること - 必要なコンテキストルールが利用できること - 接合子(joiner character)に関連するコンテキストルール (より一般的には CONTEXTJ 文字)がテスト済みであること ・ 用字が混在するラベルを拒否するルールなど、他のコンテキストルールに よってラベルを拒否しないこと。そのようなルールは、ユーザ インターフェースにおいて表示の決定に影響を及ぼすために使用することは あるが、ドメイン名の検索を回避するために使用するものではない。 コンテキストルールを必要とする文字の処理ルールをより明確にするために、 CONTEXTUAL RULE REQUIRED(つまりコンテキストルールが必要な文字)で ありながらコンテキストルールを持たない文字を設定できることに注意して もらいたい。その場合、ルールが提供されるまでは、その文字は DISALLOWED な 文字と同じように扱われる。この状況は、「この文字を許容するという考えは 原則として認めるが、この文字を安全に使用する方法の合意が得られるまでは、 その使用を認めない」とほぼ同じである。 Klensin Informational [Page 27] RFC 5894 IDNA Rationale August 2010 ルールを追加できるということは、これらの文字について DISALLOWED から PVALID への再分類を禁止する制限を免除することとほぼ同じである。 また、「ルールが存在しない」ことと「ルールは存在するが、テスト結果が 不定(成功する場合と失敗する場合がある)」は明らかに異なる。 検索を拒否する独自基準を持たず、これらのルールにしたがう検索 アプリケーションは、検索対象のドメイン名レジストリとアプリケーションの 間で文字データベース表のバージョンが違っても、その影響を受けにくい。 ただし、検索するラベルがユニコードに最近追加された文字を含む場合は 例外である。 本プロトコルにしたがって名前を処理し、それをDNSで名前解決する アプリケーションまたはクライアントは、登録がIDNAで有効であり、 また使用するIDNA文字データベース表がラベルを構成する文字全てを解釈 するに十分な程度に新しければ、DNSに登録された名前を全て特定する ことができる。検索失敗時のユーザへのメッセージは「未割り当ての コードポイントを含むラベル」による失敗と他のタイプの失敗を区別すべき である。ユニコードバージョンが古いことが原因で失敗した場合、ユーザは 新しいバージョンにアップグレードしたいと考えるかもしれないが、それ以外の 悪影響は生じない。(これは、DNSへの過渡期に、あるホストが特定の形式の 名前やレコードタイプを扱えなかった場合の振る舞いと同じである)。 7.2. 文字解釈の変更 マッピングを廃止した結果、現行バージョンのIDNAは少数の文字について その文字の解釈を前バージョンから変更している。以後のサブセクションで この問題を概説し、考えられる移行戦略を論じる。 7.2.1. 解釈の変更が必要な背景: Eszett と Final Sigma の場合 大文字と小文字を区別する用字では、小文字に対応する明確かつ一意な大文字が 歴史的に存在しないもの、またはその逆の事例が少数存在する。 IDNA2003のStringprepの変換表(mapping table)を作成する際にはマッピングを 使用したが、これはユニコードの大文字小文字の文字種統一(toCaseFold)処理 (ユニコード標準[Unicode52]セクション5.18参照)を使用して実行される。 対応する大文字(小文字)が存在しないこれらの文字に対してこのマッピングを 適用すると、異なる文字または文字セットが生成される。この処理は 不可逆であり、従来の大文字小文字変換よりも多くの情報が失われる。 しかし比較目的のためには従来の変換よりも便利である。このタイプの 2つの顕著な文字として、ドイツ文字の Eszett(Sharp S, U+00DF)と Greek Final Form Sigma (U+03C2) が挙げられる。Eszett を大文字小文字変換 すると、ASCII文字列「ss」になり、Greek Final Form Sigmaを大文字小文字変換 すると、中間形式の (lowercase) Sigma(U+03C3) になる。 Klensin Informational [Page 28] RFC 5894 IDNA Rationale August 2010 7.2.2. 解釈の変更が必要な背景: Zero Width Joiner と Zero Width Non-Joiner の場合 IDNA2003は、ZWJ(Zero Width Joiner, U+200D)とZWNJ(Zero Width Non-Joiner, U+200C)を何にもマッピングしないことで、これらの文字を効率的に全ての ラベルから排除していた。これにより、ラベルにそれらの文字を含んでいても、 マッピングを行うことにより、それらの文字を含まない場合と見た目も扱いも 同一にすることができる。先のセクション3.1.2で論じたように、これらの文字は 特定の用字で数多くの適切なニーモニックを表記するために必要不可欠なもの である。しかし、IDNA2008でこれらの文字を有効なものとして扱うと、 たとえコンテキストの制約を課したとしても、Eszett や Final Sigma の 場合とほぼ同じ問題が生じる。具体的に、IDNA2003では有効であった文字列が、 新しいIDNAバージョンでは同じ文字列であっても異なったラベル解釈を受け、 異なるA-ラベルになるという問題が生じる。 7.2.3. 文字解釈の変更と移行の必要性 A-ラベルとU-ラベルの冪等性を持たせるために、IDNA2008プロトコルより、 大文字小文字の文字種統一を含む必須かつ標準化されたマッピングを廃止する という判断を行った。これにより、これまでに挙げた文字が問題を引き起こす ものとなってしまった。これらの文字の使用を不許可にすると、重要な単語や ニーモニックを正字法の妥当な方法では表記できなくなる。これらの文字を 別の新しい文字として許容すると、情報の損失はなくレジストリも自由度を 確保できる。しかしIDNA2003とIDNA2008の検索結果が異なるA-ラベルに なってしまう可能性がある。 どちらの方法を採っても互換性は損なわれること、それでも互換性の低減は プレフィックスの変更を行うには不十分だという判断に基づき、ワーキング グループは Eszett と Final Form Sigma を異なる PROTOCOL VALID な文字 として扱うべきだと結論づけた。 これらの文字は、IDNAの古いバージョンと新しいバージョンで異なる方法で 解釈されるので、移行の戦略とポリシーが必要になる。幾つかの作業は クライアント側アプリケーションプログラム(検索処理を行ったり、 検索処理を実行させるもの)が適切に行える。しかし、DNSの使用状況は 多様であるから、責任の多くはレジストリが果たす必要がある。 レジストリ、特に第三者のゾーンを管理しているレジストリは、混乱を 生じさせず、また既存の識別子を著しく弱体化させたり無効化させることのない 方法で新しいサービスを導入する方法を決定しなければならない。 これは特に新しい問題ではない。レジストリはこれまでに似たような問題に 直面してきた。例えば、IDNを導入した際に、特にラテン系用字は、ある程度 標準化された慣習にしたがってそれまでASCII文字で表現されていた既存ラベルと 衝突する問題が生じたし、他にも新しい形式の文字列をラベルとして許容した 際にも同様の問題が生じた。 Klensin Informational [Page 29] RFC 5894 IDNA Rationale August 2010 7.2.4. 移行の戦略 新しい文字を導入したり、既存の文字の解釈を古いバージョンのIDNAで行われた マッピングから変更するためのアプローチは幾つか存在する。移行の問題は複雑 である。IDNA2003でこれらのラベルに対して ToUnicode(ToASCII()) 変換を 行って得られる形式は、ただ単に有効というだけで、登録者の意図をはっきり 示せなくなるからである。例えば、「ss」を含む文字列は、単にその文字列を 意図したのか、Eszett を含む意図があったのかわからない。また Lower Case Sigmaを含む文字列は、Final Sigmaを含む意図があったかもしれない。(文字列の 位置に基づいて発見的手法を適用できる可能性はあるが、単語をつなげてラベルを 構成するという長年の伝統のために、この発見的手法は信頼できないだろう)。 あるいは、ZWJやZWNJを含まない文字列は、それを含む意図があったかもしれない。 何らかの優先度や完全性の要求などが無いのであれば、移行手段としては 以下のようなものが考えられる。これらは全て過去において似たような移行を 行った際にレジストリが使用したものである。 1. レジストリレベルで新たに利用可能になった文字の使用を許容しない。 ドメイン名がIDNA2003のマッピング処理を期待して表記されていた場合、 この方策のために検索が失敗する可能性がある。しかし誤った一致が 生じる可能性を無くすことができる。 2. 「サンライズ期間」(※)のような調整を行う。例えば、Eszett の解釈を変更 する場合には、文字列「ss」を含むラベルの所有者に対して、Eszett を含む ラベルの優先登録権(や場合によっては他の便宜)を与える。同様に Lower Case Sigma を含むラベル保有者や、ZWJまたはZWNJをコンテキストに 含むラベル保有者に対して、それぞれFinal SigmaやZero-Width の適切な文字 を含むラベルの優先登録権などを与える。 ※訳注: サンライズ期間とは 新しいドメインを導入する際に利用される手法で、先着順のドメイン名 登録を行う前に、何らかの権利保有者が優先的にドメイン名を登録できる 期間のこと 3. 登録者が解釈変更前と変更後のどちらの文字形式のラベルも得られるように、 ある種の「異体字」を使用するアプローチを採用する。 4. 「異体字」を使用する別のアプローチを採用する。IDNA2003で解釈すると同じ A-ラベルを生成する異体字は、一切登録を許容しないか、またはその異体字の 1つを既に持っている所有者だけが登録できるようにする。 5. 問題を無視する。市場または他の仕組みによって問題が解決されるとみなす。 どの手段を選択するにせよ、(DNSツリーの任意のレベルの)レジストリが、解釈が 変わる文字を含むラベルの登録の許容を選択するか、または今後許容しようと しているのであれば、何らかの方法で既存のラベルと新たに登録するラベルとの 関係(おそらくは衝突する)を解決しなければならないだろう。これはまさに、 IDNがはじめて導入されたときに、既に膨大な数のラベルを保持していたレジストリ が行ったことと同じである。 Klensin Informational [Page 30] RFC 5894 IDNA Rationale August 2010 7.3. 文字マッピングの廃止 セクション6で詳細に論じたように、IDNA2003はNameprep(セクション7.5参照)を 使用して、多くの文字を対応する文字にマッピングしていた。このような マッピングは、もはやIDNA2008の要件には存在しない。IDNA2008の一連の 仕様では、A-ラベルまたはU-ラベルだけをプロトコルコンテキストで使用 すること、より一般的には、できるだけ実用的であることが強く求められる。 IDNA2008は、検索アプリケーションにユーザが入力を行う際に何らかの マッピングを行うことが適切であり望ましいと見込んでいる。この問題に ついての議論がセクション6にあり、固有の推奨が Mapping 文書 [IDNA2008-Mapping] でなされている。 7.4. プレフィクス変更に関する論点 IDNAのACEプレフィックス(IDNA2003が使用していた「xn--」)の変更が必要となる 条件はコミュニティの重大な懸念事項だった。 アルゴリズム変更後の移行期間中に、登録に深刻な曖昧さが生じるような場合、 明らかにプレフィックスの変更が必要になる。本セクションは、プレフィックスの 変更が必要な条件とその変更が意味することについて、ワーキンググループの 結論を要約する。 7.4.1. プレフィックス変更が必要な条件 任意の文字列を検索する際に、プロトコルのバージョンや使用する文字データ ベース表のバージョンに依存して文字列の解釈が異なる場合、IDNプレフィックスの 変更が必要になる。今回のIDNAの改訂では、以下に示す4つの条件のうち、どれか 1つでも合致するものが存在した場合に限り、プレフィックスの変更が必要と されていた。 1. A-ラベルからユニコード(つまりU-ラベル)に変換すると、IDNA2003と IDNA2008で異なる文字列が導かれる場合。 2. IDNA2003で有効だった文字列の入力がIDNA2008でも有効だが、バージョンに よって異なるA-ラベルが生成される事例が無視できない数になる場合。 この条件は先に論じた Eszett と Final Form Sigma の事例と本質的には同じ と見られている。異なる点は問題になる状況の数が非常に少ないことで、 プレフィックスの変更は正当化できないと判断された(セクション7.2参照)。 入力文字列が片方のバージョンで有効だがもう片方では無効の場合、この 条件には当てはまらないことに注意してもらいたい。以下のセクション7.4.2の 第1項を参照のこと。 Klensin Informational [Page 31] RFC 5894 IDNA Rationale August 2010 3. DNSに登録される文字列の意味づけ(semantics)に根本的な変更が生じる場合。 例えば、エンコーディング時に言語や用字の情報を文字列そのものに追加する 判断が行われた場合。 4. 非常に膨大な数の文字がユニコードに追加され、ブロックオフセットを使用 するPunycodeの仕組み(※)では、大きい数値の補足面(supplementary plane)と そのブロックを参照できなくなる場合。この条件が発生する可能性は長期的に 見ても低く、今後数年では発生しないと確信している。 ※訳注 Punycodeでは非ASCII文字を文字コード順に並び替え、前の文字の文字コード との差分をとる処理がある 7.4.2. プレフィックス変更が不要な条件 上で述べた原則にしたがい、以下に示す変更はどれも新しいプレフィックスを 必要としない。 1. 幾つかの文字について、IDNAへの入力を禁止した場合。この禁止により、 禁止前に登録された名前にアクセスできなくなる可能性がある。しかしこの 変更によって名前が変更されるわけではない。 2. IDNA2003では無効だった文字に影響するような正規化の定義の修正など、 IDNAの文字データベース表や動作を修正した場合。 3. IDNAが実行する処理を変更しないようにIDNA形式を変更した場合。 7.4.3. プレフィクス変更が意味すること プレフィックスの変更は可能だが、その変更にかかるコストは膨大である。 レジストリは、(「xn--」で始まる)IDNA2003形式の登録名全てを プレフィックス変更にあわせて新形式に変換し、検索をサポートする アプリケーションの変更に間に合わせることはできないかもしれない。 既存の登録全てを単に無効と宣言しない限り(おそらくは宣言したとしても)、 新旧両方のプレフィックスをサポートする必要のあるシステムでは、まず はじめにIDNA2008ルールで仮適合ラベルを処理し、それを検索し、 それが発見できなければ次にIDNA2003ルールでラベルを処理し、再度検索を 行うという一連の処理を要求される。1つのFQDNの中に古いプレフィックスの ラベルと新しいレフィックスのラベルが混在することもあり得るので、 このような一連の処理はDNSにおけるIDN関連の処理速度を大幅に低下させる。 また、新旧プレフィックスの混在により、DNSのキャッシュが困難になる。 さらに、同じ入力文字列をプレフィックスが異なる2つのA-ラベルとして 検索すると、混乱や攻撃の可能性が生じる。2つのラベルがそれぞれ異なって マッピングされ、異なるDNSエントリに名前解決されるかもしれないためである。 Klensin Informational [Page 32] RFC 5894 IDNA Rationale August 2010 結論として、プレフィックスの変更は、それが可能であっても回避すべきで あったし、実際回避された。プレフィックス変更の回避によって、IDNA2003に おける文字分類の決定は不可逆的に変更され、問題が生じる事例に対しては 特別な処理が必要となるが、それも含めてこの結論が受け容れられた。 7.5. Stringprepの変更と互換性 IDNA2003の重要な要素になっている Nameprep 仕様[RFC3941]は、Stringprep [RFC3454]のプロファイルである。NameprepはIDNAに特化したStringprepだが、 Stringprepは他の多数のプロトコルで使用されている。IDNA2008でStringprepを 変更していたならば、IDNの処理を改善するための変更によりDNS以外での Stringprepの使用で問題を引き起こしていたかもしれない。 代表的な事例を挙げると、Stringprepの変更が身分証明、認証プロトコルに 影響する場合などである。IDNA2008のプロトコル要素では、IDNA2003で 禁止されていた文字に新たに解釈を与えたり、IDNA2003で許容されていた文字を 禁止したりしている。これらのプロトコル要素には、Tables 文書[RFC5892]に 含まれる新しい認可制の情報(文字データベース表)や、登録または検索時の入力で 許容される文字数の削減(セクション3)、Bidi 文書[RFC5893]に記載のある 右から左に表記する文字列の扱いの変更などが含まれる。IDNA2008はNameprepも Stringprepも全く使用しないので、IDNA2008で生じた変更が副作用的に他の プロトコルに影響することはない。 IDNA処理を様々なセキュリティプロトコルの処理と分離したままにしておくことは 極めて重要である。なぜなら、IDNAを円滑かつ分かりやすく使用するために必要な 制約が、他のプロトコルでは無用または望まれないものになる場合があるから である。例えば、良いパスワードまたはパスフレーズの基準は望ましいIDNの基準 とは全く違う。パスワードは推測しにくいものであるべきだが、ドメイン名は 覚えやすいものであるべきとされている。同様に、国際規格化されたSCSI IDや 他のプロトコル要素は、おそらくIDNとは異なる要件を持つだろう。 7.6. 記号に関する論点 本仕様とオリジナルバージョンのIDNA仕様(IDNA2003)の主な違いは、IDNA2003では 句読点文字や罫線文字といった、非英字の記号をプロトコルで許容していた ことである。実際には、それらの文字の使用は常に抑制されていた。特に、IDNAに 関する「IESGの声明(IESG Statement)」とICANNガイドラインの全バージョンの 両方で、ラベルには言語文字のみを使用するよう規定している。本仕様は記号を 全て禁止する。これには下記に示すような幾つかの理由がある。 1. 他の箇所で議論したように、オリジナルIDNA仕様は、直接あるいは他の文字 へのマッピングを通して、できるだけ多くのユニコード文字をIDNで許容する ことを前提としていた。本仕様は認可性モデルで運用する。つまり、 インターネットで非常にうまく機能しているオリジナル「ホスト名」ルール (LDH。Definitions 文書[RFC5890]参照)を元にして、ASCIIベースではなく ユニコードベースで認可リストを作成する。 Klensin Informational [Page 33] RFC 5894 IDNA Rationale August 2010 2. 記号名は英字名よりも問題を引き起こしやすい。特定の記号に対応する グリフについて一般的な合意が無い場合があるし、名前に関しては統一的な 慣習が存在しない。またoutline, solid, shaded形式の異体字が存在する 場合としない場合がある、その他も含めて様々な問題がある。 一例として、「ハート」記号を考える。ハート記号はロゴの中に現れ、 「I love ...」と読ませる場合がある。ユーザはロゴを見て「I love ...」や 「I heart ...」などと読むだろうが、ユニコードのコーディングの違いに 関する相当な知識がなければ、今、目にしている「ハート」型の文字が 複数ある(例えば U+2665, U+2661, U+2765)うちのどれなのかを判断する ことはできないだろう。この問題は、口頭で読み上げられた文字列を聞き手が 理解して書き起こすことが期待される場合には特に重要になる。 3. 盲目のインターネットユーザが使用する読み上げソフトウェアの設計を 考える。ユーザは表示されたIDNドメイン名の読み上げを聞き取り、 おそらくはそれをキーボードで再入力するだろう。ある文字の名前が その言語を知っている人にとって直観的でわかりやすいものでなければ、 そのようなソフトウェアの設計は非常に複雑になる。 4. さらに例を単純化して、誰かがラベルで「ハート」や「スター」記号を 使用したいと考えたとする。しかし、これは問題を引き起こす。 「ハート」や「スター」といった記号名は、ユニコードシステムの名前と しては曖昧なものだからである。(実際のユニコードの名称を与えるには もっと詳細な情報が必要である)。ユーザまたはドメイン名登録希望者 (would-be registrant)は、コード表を注意深く調査しない限り、それが 曖昧なのか(例えば「ハート」に見える文字が複数あれば曖昧)、 そうでないのかを知る方法がない。仮に登録できたとしても、そのラベルを 見ているユーザは、例えば同僚に声でそれを伝えようとしても、どのように 読めばいいのかがわからない。それは「heart」なのか「love」なのか 「black heart」なのか、次の項で示す他の例のようになるのかはわからない。 5. 実際の状況はこれより更に悪くなる。一般的な、気軽なユーザが、U+2665の ハートとU+2765のハートを区別したり、U+2606のスターとU+2729のスターを 区別することは、何らかの理由で見た目が似た文字が複数あるので、その 違いに気をつける必要があることを知らない限りは不可能である。 ユニコードには 白抜きのハート(WHITE HEART, U+2661)と幾つかのベタ塗りの ハート(BLACK HEART)がある。結果として、ハートを含むラベルを記述すると 絶望的に曖昧になる。見てわかることは、ハートに見える幾つかの文字の うちどれかを含んでいること、あるいはその文字の名前「HEART」を含んで いることだけである。「～スクエア」という地名が多い街では、ユーザが スクエア記号をラベルで使いたがるかもしれない。しかし、ユニコードでは ハートやスターよりもはるかに多様なスクエア記号文字が存在する。 Klensin Informational [Page 34] RFC 5894 IDNA Rationale August 2010 これまでに述べた曖昧性から導き出される結論は、記号は信頼できる通信手段で 使用するにはあまりにも貧弱だということである。ユニコード標準は、 識別子として使用する文字列に記号や句読点文字を含めないことを推奨している ので[Unicode-UAX31]、この結論とも矛盾しない。もちろん、記号に関するこれらの 問題は、通常の言語文字のように扱われるピクトグラフを使用する言語 (pictographic language)や用字では発生しない。この2つを混同すべきではない。 7.7. ユニコードバージョンの移行: 未割り当てコードポイントの問題 IDNA2003では、未割り当てコードポイントを含むラベルも検索する。 これは、未割り当てコードポイントがラベル内に存在するとしても、それが マッピングされて名前解決されるのであれば、それは関連する標準が変更された のであって、レジストリは割り当て値を持つコードポイントで構成された ラベルだけを適切に登録しているという想定によるものである。 IDNA2008プロトコルでは、未割り当てコードポイントを含む文字列は検索も 登録も行ってはならない。要約すると、DISALLOWED, PROTOCOL-VALID, CONTEXTUAL RULE REQUIREDカテゴリの未割り当てコードポイントの状態は、 何らかの文字が割り当てられてそれが周知されるまでは評価してはならない。 これには幾つか理由があるが、特に重要なものを以下に示す。 ・ IDNA2008では、文字のコンテキストが必要なテスト(例えば幾つかの文字は 固有のタイプに隣接する場合にしか許容されない)やラベル全体の完全性 テストが必要である。未割り当てコードポイントに対して文字が割り当てられ、 その特性値が完全に周知されるまでは、そのコードポイントがコンテキスト ルールを必要とするか(またどのようなルールが推奨されるか)を判定できない。 したがって未割り当てコードポイントは許容できない。 ・ 未割り当てコードポイントに、Tables 文書[RFC5892]で不許可な文字(例えば 互換文字(compatibility character))が将来関連付けられないかどうかを、 十分な信頼性を持って事前に知ることはできない。IDNA2003はNFKCに直接 依存しない(Stringprepの文字データベース表のエントリの多くはNFKCに 基づくものだが、IDNA2003はStringprepのみに依存する)ので、互換文字を 割り当てたとしても、若干おかしな状況は発生するが、問題にはならない。 IDNA2008では、互換文字は文字別に例外が設定されない限りDISALLOWEDで あるから、未割り当てコードポイントを含む文字列の検索を許容すると、 DISALLOWEDな文字は検索されないという原則を侵害する。 ・ ユニコード標準では、未割り当てコードポイントは(必要なら大文字小文字 の文字種統一を行った上で)自分自身に正規化すると規定している。 未割り当てコードポイントに後で文字が割り当てられる場合、特にその コードポイントが他の結合文字との相対位置を決定する結合クラスを持つ 場合、ある文字(文字が割り当てられたコードポイント)を正規化すると、 別のコードポイントまはたコードポイントの並びに正規化されてしまう 可能性がある。 Klensin Informational [Page 35] RFC 5894 IDNA Rationale August 2010 「上に挙げたような問題は重要ではない。重要な用字や文字はユニコード5.2の 時点(あるいはそれ以前のバージョン時点でさえ)全てコード化されている のだから、未割り当てコードポイントに割り当てられるのは無名な文字や 時代遅れの用字だけだ。したがって、たとえ未割り当てコードポイントを 含んでいてもラベルを検索するという原則を維持した方がよい」 という反論もあるだろう。残念ながら、少なくとも2つの理由から、これが安全な 仮定とは思われない。第1に、ユニコードの以前のバージョンにおいても、 完全性に関する同じ主張が行われた。現実は、世界の大部分の人が知らない ような用字でも、それを使う人々にとっては依然として重要なのである。 文化と言語の保存という原則により、無名な用字がIDNでは重要でないと宣言 することは不適切である。第2に、我々は既に新しい漢字(Han character)に 対応するコードポイント割り当てを(BMP(Basic Multilingual Plane)か ユニコード プレーン2のどちらかに)追加するという反例を経験している。 上記で示した移行に関する技術的問題とは別に、特定の言語をより使いやすく したり順応性を上げるために既存の用字に文字を追加すると、移行の問題が 生じることがわかる。新しい文字を追加すると、特定の文字を表記する際の 推奨形式が変わり、それが例えばキーボードの変換モジュールに反映されて いく。例えば、新しい文字が存在しないユニコードのバージョンと新しい 文字が存在するユニコードのバージョンでは表記形式を変える必要がある。 この段階で、本質的な移行の問題が生じる。ラベルへのアクセスには 古い表記慣習と新しい表記慣習のどちらかが使用されるので、レジストリは ラベルで古い表記慣習の使用を許容するかどうかの対応を求められるためである。 移行の仕組みの検討が必要なのは、よりよい表記体系への順応を目指した ユニコードの発展に本質的に内在する問題であり、DNSにおいてIDNを どう表現するかや、移行の仕組みが整った後に具体的にどう移行させるかは 別問題である。このタイプの移行の要件は、ユニコード5.1.0に マラヤーラム語のChilluを追加した際に明らかになった。 7.8. その他互換性に関する問題 IDNA2003のモデルは、それが開発された経緯により幾つか奇妙な副作用が存在 する。全てではないが、それらの多くは、特に登録処理で「ソース」名(IDNAや Nameprep処理を行っていない名前)の登録を許容する場合に脆弱性への 抜け道になる可能性がある。一例を挙げると、ドイツ語で使用される文字 Eszett は、IDNA2003では拒否されたりそのまま維持されたりするのではなく、文字の 並び「ss」にマッピングされる。「ss」を含み、それ以外の文字は全てASCII である文字列は、(上で定義したU-ラベルの意味で)IDNではない。 NameprepはEszettをマッピングしないので、出力される結果はASCII文字列に なり、xn-- プレフィックスは付与されない。しかし、ユーザに対して表示する 文字列はIDNに見えるかもしれない。IDNA2008 ではこの副作用を 取り除いている。文字は許容されるか禁止されるかのどちらかである。 特定の言語や文化のコンテキストの中でだけ理に適うような事例は、地域化の 問題として、適切な場所で処理することができるようになっている。 Klensin Informational [Page 36] RFC 5894 IDNA Rationale August 2010 8. ネームサーバに関する考慮点 8.1. 非ASCII文字列の処理 既存のDNSサーバは非ASCII形式のIDNを処理するIDNAルールを知らないので、 DNSからそれらのルールを隠ぺいする必要がある。DNSサーバデータベースに 名前を登録する既存の全チャネル(例えば、RFC 1034に記載のあるマスター ファイルや [RFC2136] で規定されるDNSアップデートメッセージ)は、 IDNA以前から存在しているので、これら全てがIDNA対応であるとは考えられない。 本文書の他のセクションに要求される隠ぺいの記載がある。具体的に、 既存チャネルを通してDNSサーバデータベースに登録される国際化ドメイン名が ASCII A-ラベル形式に変換済みであることを保証することにより、 必要な隠ぺいを提供している。 登録用アルゴリズムと検索用アルゴリズム(それぞれ Protocol 文書[RFC5891]の セクション4, 5に記載がある)には違いがあり、登録用アルゴリズムでは、 ASCIIコードポイントだけで構成されるドメイン名はA-ラベルに変換されない。 したがって、任意のU-ラベルに対応する複数のA-ラベルが登録されることは あり得ない。 「DNS仕様の明確化」[RFC2181] で規定されるように、ASCII文字の範囲 (0000..007F)を外れたオクテットをラベルに含むことを明示的に許容しており、 本文書もそれを変更しない。しかし、DNSにおけるオクテット 0080..00FF の 解釈は明確であるが、多くのアプリケーションプロトコルはASCIIラベルしか サポートしていないし、これらの非ASCIIオクテットを文字として解釈する定義は 存在しない。特に、それらを大文字小文字を区別せずに一致照合させる解釈は 存在しない(例えば「DNSは大文字小文字を区別しないということの明確化」 [RFC4343]参照)。これらのオクテットを含むラベルがアプリケーションに 返された場合、その結果生じる振る舞いは予測できない。これらの文字を 含むことのできないA-ラベル形式だけが、DNSプロトコルにおける国際化ラベルの 標準的な表記法である。 8.2. ルートサーバおよび他のDNSサーバに関する考慮点 A-ラベル形式のIDNは一般にこれまでのドメイン名よりも少し長くなるので、 ルートサーバが必要とする帯域をわずかながら上昇させる。また、IDNに対する 問合わせ、応答もおそらくは従来の典型的な問い合わせよりは少し長くなるので、 EDNS0 [RFC2671]のサポートがより重要になるだろう。(対応しなければ、 問合わせ、応答が強制的にUDPからTCPに切り替えられる)。 Klensin Informational [Page 37] RFC 5894 IDNA Rationale August 2010 9. 国際化に関する考慮点 DNSラベルとFQDNは、インターネット上のリソースの特定や参照を補助する ニーモニックを提供する。IDNはニーモニックの範囲を拡張し、西ヨーロッパや ローマ由来の言語や文字セット以外のものを含めるようにする。しかし、 ドメイン「名」は、一般に何らかの言語の単語ではない。文字セットと言語に 関するIETFポリシー(BCP 18, [RFC2277])の推奨は、言語固有のコンテキストを 提供するために言語IDを使用するような状況で適用可能である。対照的に、DNSは グローバルかつ国際的であり、極言すれば言語と何も関係がない。 一般に、IDNに言語を追加する(または同様のコンテキストを追加する)こと、 あるいはDNSの一致照合で使用できる言語を追加するということは、DNSが コンテキスト依存の一致照合を行うことを意味するので、DNSプロトコル自身を 劇的に変更することになる。これはまた、ユーザがラベルを検索するためには、 そのラベルで使用されている言語を特定しなければならないことを意味する。 多くのラベルは何らかの言語の単語とは限らないし、場合によっては複数言語の 単語を組み合わせているような場合もあるので、そのような情報は一般に 利用できない。 10. IANAに関する考慮点 本セクションはIDNAで必要なIANAレジストリの概要を提供する。IDNA2008の ために新規に作成されたレジストリを以下のセクションに示すが、初めの 2つについては、その具体的な定義と仕様に関して Tables 文書[RFC5892]に 記載がある。この文書はレジストリについて記述しているが、IANAの作業に ついては何も規定していない。 10.1. IDNA文字レジストリ 主要な分類「UNASSIGNED」「DISALLOWED」「PROTOCOL-VALID」「CONTEXTUAL RULE REQUIRED」は、Tables 文書の不可欠な要素となっている特別なカテゴリと ルールによって区分される。これは規定ではないが、文字、用字と そのカテゴリに関するIANAレジストリは、ユニコードのバージョン改訂毎に そのバージョンに含まれる文字情報が更新されるので、プログラミングや 有効性検証処理で役に立つだろう。このレジストリの詳細は Tables 文書で 規定される。 Klensin Informational [Page 38] RFC 5894 IDNA Rationale August 2010 10.2. IDNAコンテキストレジストリ IANAは、IDNA文字レジストリで定義される文字のうち、コンテキストルール (セクション3.1.2で記述したルール種別)が必要なものについて、承認済み コンテキストルールのリストを作成し維持している。これらのルールの詳細は Tables 文書に記載がある。 10.3. TLDによるIDN運用のIANAレポジトリ このレジストリは、歴史的に「IANA言語文字セットレジストリ(Language Character Set Registry)」または「IANA用字レジストリ(Script Registry)」と 表記されてきたもので(どちらにせよ、少々誤解を招きやすい用語である)、 ICANNの要求に応じてIANAが維持してきたものである。 これは、IDNポリシーに関する中心的な文書リポジトリを提供しており、 自発的に文書提供の貢献をするTLDレジストリが使用してきた。また、IDNの 使用に関するICANNガイドラインと併せて使用される。 これはIETF管理のレジストリではない。ここで規定したプロトコルの変更に よって文字データベース表の改訂が要請されるかもしれないが、IDNA2008自身は このレジストリに直接影響を与えず、したがってIANAの作業も要求しない。 11. セキュリティに関する考慮点 11.1. IDNAのセキュリティに関する一般的な問題 本文書は純粋に解説と情報提供を行うものであるから、セキュリティの問題を 新たに導入することはない。もちろん、本文書を基にして実装を行うのは良い アイディアとは言えない。そのような試みはほぼ間違いなく相互運用性の問題や セキュリティの問題を引き起こすだろう。関連する経緯を含んだIDNAに関する セキュリティの問題の議論は Definitions 文書[RFC5890]で得られる。 12. Acknowledgments The editor and contributors would like to express their thanks to those who contributed significant early (pre-working group) review comments, sometimes accompanied by text, Paul Hoffman, Simon Josefsson, and Sam Weiler. In addition, some specific ideas were incorporated from suggestions, text, or comments about sections that were unclear supplied by Vint Cerf, Frank Ellerman, Michael Everson, Asmus Freytag, Erik van der Poel, Michel Suignard, and Ken Whistler. Thanks are also due to Vint Cerf, Lisa Dusseault, Debbie Garside, and Jefsey Morfin for conversations that led to considerable improvements in the content of this document and to several others, including Ben Klensin Informational [Page 39] RFC 5894 IDNA Rationale August 2010 Campbell, Martin Duerst, Subramanian Moonesamy, Peter Saint-Andre, and Dan Winship, for catching specific errors and recommending corrections. A meeting was held on 30 January 2008 to attempt to reconcile differences in perspective and terminology about this set of specifications between the design team and members of the Unicode Technical Consortium. The discussions at and subsequent to that meeting were very helpful in focusing the issues and in refining the specifications. The active participants at that meeting were (in alphabetic order, as usual) Harald Alvestrand, Vint Cerf, Tina Dam, Mark Davis, Lisa Dusseault, Patrik Faltstrom (by telephone), Cary Karp, John Klensin, Warren Kumari, Lisa Moore, Erik van der Poel, Michel Suignard, and Ken Whistler. We express our thanks to Google for support of that meeting and to the participants for their contributions. Useful comments and text on the working group versions of the working draft were received from many participants in the IETF "IDNABIS" working group and a number of document changes resulted from mailing list discussions made by that group. Marcos Sanz provided specific analysis and suggestions that were exceptionally helpful in refining the text, as did Vint Cerf, Martin Duerst, Andrew Sullivan, and Ken Whistler. Lisa Dusseault provided extensive editorial suggestions during the spring of 2009, most of which were incorporated. 13. Contributors While the listed editor held the pen, the core of this document and the initial working group version represents the joint work and conclusions of an ad hoc design team consisting of the editor and, in alphabetic order, Harald Alvestrand, Tina Dam, Patrik Faltstrom, and Cary Karp. Considerable material describing mapping principles has been incorporated from a draft of the Mapping document [IDNA2008-Mapping] by Pete Resnick and Paul Hoffman. In addition, there were many specific contributions and helpful comments from those listed in the Acknowledgments section and others who have contributed to the development and use of the IDNA protocols. 14. References 14.1. Normative References [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. Klensin Informational [Page 40] RFC 5894 IDNA Rationale August 2010 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010. [RFC5892] Faltstrom, P., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010. [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010. [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). . 14.2. Informative References [IDNA2008-Mapping] Resnick, P. and P. Hoffman, "Mapping Characters in Internationalized Domain Names for Applications (IDNA)", Work in Progress, April 2010. [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. Klensin Informational [Page 41] RFC 5894 IDNA Rationale August 2010 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 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. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [RFC4290] Klensin, J., "Suggested Practices for Registration of Internationalized Domain Names (IDN)", RFC 4290, December 2005. [RFC4343] Eastlake, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006. [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006. [RFC4713] Lee, X., Mao, W., Chen, E., Hsu, N., and J. Klensin, "Registration and Administration Recommendations for Chinese Domain Names", RFC 4713, October 2006. Klensin Informational [Page 42] RFC 5894 IDNA Rationale August 2010 [Unicode-UAX31] The Unicode Consortium, "Unicode Standard Annex #31: Unicode Identifier and Pattern Syntax, Revision 11", September 2009, . [Unicode-UTS39] The Unicode Consortium, "Unicode Technical Standard #39: Unicode Security Mechanisms, Revision 2", August 2006, . Author's Address John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA Phone: +1 617 245 1457 EMail: john+ietf@jck.com Klensin Informational [Page 43]