Internet Engineering Task Force (IETF) J. Klensin Request for Comments: 5891 2010年8月 廃止: 3490, 3491 更新: 3492 分類: 標準化過程(Standards Track) ISSN: 2070-1721 アプリケーションにおけるドメイン名の国際化(IDNA): プロトコル 要旨 本文書は、国際化ドメイン名(IDN)に関するプロトコルの改訂を定義する。 プロトコル変更の動機、改訂前の仕様との関連、重要な専門用語などは 他の文書で提供される。本文書は「アプリケーションにおけるドメイン名の 国際化(IDNA)」と呼ばれるプロトコルの仕組み、具体的にDNSの変更を 伴わない方法でIDNをドメイン名登録し、検索する仕組みを規定する。 IDNAはドメイン名を処理するためだけのものであり、一般的な文章を 処理するものではない。 Status of This Memo This is an Internet Standards Track document. 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). Further information on Internet Standards is available in 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/rfc5891. Klensin Standards Track [Page 1] RFC 5891 IDNA2008 Protocol 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. Klensin Standards Track [Page 2] RFC 5891 IDNA2008 Protocol August 2010 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. 専門用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. 要件と適用性 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. 要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. 適用性 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. DNSリソースレコードへの適用 . . . . . . . . . . . . . 6 3.2.2. DNSに保存されたドメイン名以外のデータタイプへの適用 . 6 4. 登録プロトコル . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. IDNA登録への入力 . . . . . . . . . . . . . . . . . . . . . 7 4.2. 許容される文字とラベルの有効性検証 . . . . . . . . . . . . 7 4.2.1. 入力フォーマット . . . . . . . . . . . . . . . . . . . 7 4.2.2. 許容されない文字の拒否 . . . . . . . . . . . . . . . . 8 4.2.3. ラベルの有効性検証 . . . . . . . . . . . . . . . . . . 8 4.3. レジストリの制約 . . . . . . . . . . . . . . . . . . . . . 9 4.4. Punycodeへの変換 . . . . . . . . . . . . . . . . . . . . . 9 4.5. ゾーンへの登録 . . . . . . . . . . . . . . . . . . . . . . 10 5. ドメイン名検索プロトコル . . . . . . . . . . . . . . . . . . . 10 5.1. ラベル文字列の入力 . . . . . . . . . . . . . . . . . . . . 10 5.2. ユニコードへの変換 . . . . . . . . . . . . . . . . . . . . 10 5.3. A-ラベルの入力 . . . . . . . . . . . . . . . . . . . . . . 10 5.4. 有効性検証と文字リストに関するテスト . . . . . . . . . . . 11 5.5. Punycodeへの変換 . . . . . . . . . . . . . . . . . . . . . 13 5.6. DNS名前解決 . . . . . . . . . . . . . . . . . . . . . . . 13 6. セキュリティに関する考慮点 . . . . . . . . . . . . . . . . . . 13 7. IANAに関する考慮点 . . . . . . . . . . . . . . . . . . . . . . 13 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Summary of Major Changes from IDNA2003 . . . . . . . 17 Klensin Standards Track [Page 3] RFC 5891 IDNA2008 Protocol August 2010 本文書は「アプリケーションにおけるドメイン名の国際化(IDNA)」の プロトコル定義を提供する。ここで規定されるバージョンはIDNA2008として 知られるものである。本文書を理解するために必要な極めて重要な定義 および専門用語、またIDNA2008を構成する一連の文書群のロードマップに ついては Definitions 文書[RFC5890]に記載がある。 本文書の付録Aで以前のバージョンのIDNA(以後「IDNA2003」)と本仕様の 関係を記述する。プロトコル変更の動機については、IDNをサポートする ゾーン管理者向けの詳細な説明・アドバイスとともに、非公式に 「Rationale 文書」と呼ばれる他の文書で提供する。 IDNAは、アプリケーションが(特別なプレフィックスで始まる) 特定のASCII[ASCII]ラベルを使用して、非ASCIIラベルを表現することを 許容することで動作する。下位層のプロトコルはこの存在を意識しなくても よいので、IDNAは既存のインフラを全く変更しない。特に、IDNAはDNSサーバ、 リゾルバ、DNSプロトコルの構成要素の変更を一切必要としない。既存の DNSが提供するASCIIの名前サービスをそのままIDNAに使用できるからである。 IDNAが適用できるのは、DNSラベルの特定のサブセットだけである。基となる DNS標準 [RFC1034] [RFC1035]と多数の更新文書によって、ラベルを 組み合わせてFQDNを構成する方法や、ラベルを解析する方法が規定されている。 本文書は2つの独立したプロトコルについて記述する。1つはIDN登録に関する もの(セクション4)、もう1つはIDNの名前検索に関するもの(セクション5)である。 この2つのプロトコルは、専門用語、参照資料、運用を共有する。 2. 専門用語 先に示したように、IDNAの定義で使用する専門用語のうちの幾つかは、 Definitions 文書[RFC5890]が提供する。特に注記しておくが、専門用語の 一部は、ユニコードや他の文字セット標準、DNSで使用する専門用語と 重複しているが、整合は保たれている。読者は Definitions 文書および RFC 1034 [RFC1034]が規定するDNS固有の専門用語を理解しているものとする。 本文書におけるキーワード「しなければならない(MUST)」、「してはならない (MUST NOT)」、「要求される(REQUIRED)」、「するものとする(SHALL)」、 「しないものとする(SHALL NOT)」、「すべきである(SHOULD)」、「すべきでない (SHOULD NOT)」、「推奨される(RECOMMENDED)」、「してもよい/することが できる(MAY)」、「任意である(OPTIONAL)」は、BCP 14, RFC 2119 [RFC2119] に 記述されているとおりに解釈される。 Klensin Standards Track [Page 4] RFC 5891 IDNA2008 Protocol August 2010 3. 要件と適用性 3.1. 要件 IDNAは以下の要件を持つ。 1. DNSアプリケーションが「ホスト名」スタイルの名前(RFC 1034[RFC1034] およびセクション3.2.1参照)の歴史的な推奨項目に準拠していないならば、 IDN非対応のドメイン名スロットにドメイン名を入力する場合 (Definitions 文書[RFC5890]のセクション2.3.2.6参照)、そのドメイン名は ASCII文字だけで構成されていなければならない(MUST)。 (具体的に、ラベルはA-ラベルかNR-LDHラベルのどちらかでなければ ならない)。 2. ラベルは同じ形式を使用して比較しなければならない(MUST)。つまり A-ラベル形式同士またはU-ラベル形式同士で比較しなければならない。 A-ラベルとU-ラベルは情報を失うことなく互いに変換可能なので、これらの 比較は全て等価である。(しかし、実際にはU-ラベル同士を比較する場合、 比較に先立ってそれらが単なるユニコード文字列ではなくU-ラベルである ことを検証する必要がある)。A-ラベルのペアは、(ASCII DNSラベルの比較と 同様に)大文字小文字を区別しないASCII文字として比較しなければならない (MUST)。U-ラベルは大文字小文字の文字種統一処理や他の中間処理をはさむ ことなく、そのままの状態で比較しなければならない(MUST)。 ラベル比較時にラベルの有効性検証を行う必要はないので、ラベル比較の 成功がラベルの有効性を意味するものではない。 ラベル比較に限らず多くの場合に、様々な理由からラベルの有効性検証は 重要であり、実行されるべきである(SHOULD)。 3. 登録されるラベルはセクション4の要件に適合していなければならない (MUST)。名前検索されるラベルおよび名前検索処理はセクション5の 要件に適合していなければならない(MUST)。 3.2. 適用性 IDNAは、明示的に例外と規定されている場合を除き、各プロトコルの ドメイン名スロット全てにおいて、そこで処理される全ドメイン名に対して 適用される。ただし、Definitions 文書[RFC5890]に記載のあるLDH文法規則を 使用しないドメイン名スロットには適用されない。 IDNAはDNSを使用するので、IDNA設計前に規定された多数のプロトコルにも 適用される。そのような古いプロトコルの場合、そのプロトコルと実装が IDNに対応してU-ラベル形式を受理できるようになるまでは、あるいは 更新されない限りにおいては、そのプロトコルのドメイン名スロットで 処理されるIDNはA-ラベル形式でなければならない(MUST)。DNSの問合わせや 応答の中に実際に現れるIDNはA-ラベルでなければならない(MUST)。 Klensin Standards Track [Page 5] RFC 5891 IDNA2008 Protocol August 2010 IDNA対応プロトコルおよびその実装は、U-ラベルかA-ラベル、または両方を そのプロトコルが規定する方式で受理してもよい(MAY)。 IDNAは拡張ラベルタイプ(RFC 2671 [RFC2671]セクション3参照)に関する規定を 持たない。 3.2.1. DNSリソースレコードへの適用 IDNAが適用されるのは、CLASSがINのDNSリソースレコードのNAMEフィールドと RDATAフィールドに含まれるドメイン名に対してだけである。これらの用語の 厳密な定義はDNS仕様[RFC1035]を参照のこと。 DNSリソースレコードへのIDNA適用は、レコードのクラスだけに依存し、 以下に示す例外を除きタイプには依存しない。今後新しいタイプが 定義されたとしても、そのタイプがタイプ固有のルールを導入しない限り、 この規定は有効である。 SRVレコードで使用される特別な名前付けの慣習(より一般的には「アンダー スコアを含むラベル」)は、Definitions 文書[RFC5890]の特に セクション2.3.2.3で論じるように、IDNAコーディングと非互換である。 IDNラベルを使用するドメインのドメインツリーの上位レベルでアンダースコアを 含むラベルを使用することはもちろん構わない。 3.2.2. DNSに保存されたドメイン名以外のデータタイプへの適用 IDNAは非ASCII文字によるドメイン名表現を可能にするが、ドメイン名に 保存される他のデータタイプの中で非ASCII文字表現を可能にするわけでは ない。具体的に、構造化されたRDATAフォーマットを持つタイプの場合に、 そのRDATAフィールド内で非ASCII文字表現を可能にするわけではない。 例えば、Eメールアドレスのlocal-part は、SOAレコードのRDATAの一部として RNAMEフィールド内に保存される(例えば hostmaster@example.comは hostmaster.example.comとして表現される)。IDNAはlocal-part内で ASCII文字しか許容しない既存の電子メール標準を更新しない。電子メール アドレスの国際化[RFC4952]を定義する作業は進められているが、SOA RDATAの 電子メールアドレス部分の変更を行うためには、他の標準、より具体的には SOA RRのフォーマットを規定する標準の対応または更新が必要となるだろう。 4. 登録プロトコル 本セクションは、IDN登録のモデルを定義する。このモデルは実装非依存である。 任意のラベルに対して正確に同じ結果を生成する処理手順は全て適正な実装 である。 登録プロトコル(本セクション)と名前検索プロトコル(セクション5)は あらゆる点で非常に似ているが、これら2つは同一ではなく、実装者は 本仕様に記述される処理手順を慎重に理解すべきである。 Klensin Standards Track [Page 6] RFC 5891 IDNA2008 Protocol August 2010 4.1. IDNA登録への入力 登録処理、特にドメイン名登録申請者に対応する組織(大抵「レジストラ」と 呼ばれる)がゾーン管理者(「レジストリ」)とやり取りする前に行われる処理は 本定義の範囲外であり、地域的要請に応じて本定義とは異なるかもしれない。 本仕様で規定するIDNA登録処理に文字列を入力するまでに、その文字列をNFC形式 (Normalization Form C, NFC [Unicode-UAX15])のユニコードにしなければ ならない(MUST)。ゾーンファイルに責任を持つ組織(「レジストリ」)は、 何らかのマッピングやローカルな調整をせずに、登録要求された文字列だけを 受理しなければならない(MUST)。レジストリは以下の3つの様式のどれかで 入力された文字列を受理することができる(MAY)。 1. A-ラベルとU-ラベルのペア 2. A-ラベルのみ 3. U-ラベルのみ これらのうち、はじめの2つの様式を推奨する(RECOMMENDED)。A-ラベルの使用に より、あいまい性が生じる可能性を回避できるためである。通常の場合、1つめの 様式は2つめの様式よりも望ましい。ユーザの意図をより深く検証できるから である(セクション4.2.1参照)。 4.2. 許容される文字とラベルの有効性検証 4.2.1. 入力フォーマット U-ラベルとA-ラベルの両方が利用可能な場合、レジストリは A-ラベル形式が小文字で記述されている状態を確保し、U-ラベルへの変換を 行い、そのU-ラベルに対して以下に示す処理とテストを実行し、そのU-ラベル からセクション4.4に示す手順で生成したA-ラベルが当初入力されたA-ラベルと 一致すること を保証しなければならない(MUST)。また、入力されたU-ラベルと、入力された A-ラベルを変換して得たU-ラベルは完全に一致しなければならない(MUST)。 何らかの理由でテストが失敗した場合、登録を拒否しなければならない(MUST)。 A-ラベルだけが入力され、U-ラベルへの変換を行わない場合であっても、 レジストリは入力されたA-ラベルが見かけ上は有効であることを検証しなければ ならない(MUST)。具体的にPunycodeエンコーディング[RFC3492]で禁じている ハイフン(マイナス)での終了が現れないこと、また全ての文字がASCIIで構成 されていることなどを検証しなければならない。A-ラベルであるように見える 文字列(例えば「xn--」で始まっている)や、A-ラベルを想定した処理(様式の フィールドに記入されるなど)で提供された文字列が、本段落で規定する有効な A-ラベルでない場合、それらをIDNAをサポートするDNSゾーンに保存しては ならない(MUST NOT)。 Klensin Standards Track [Page 7] RFC 5891 IDNA2008 Protocol August 2010 A-ラベルだけが提供された場合、U-ラベルへの変換は実行されないが、 前の段落に記述した見かけ上有効であるかどうかの検査は実行される。 この場合、登録手続きにおいて、セクション4.2、4.3、4.4に記載のある、 ユニコードに関連した検査やU-ラベルへの変換を伴う検査・処理などは バイパスしてもよい(MAY)。大抵の場合はそうするだろう。 4.2.2. 許容されない文字の拒否 登録対象のユニコード文字列は、Tables 文書[RFC5892]が規定する 「DISALLOWED」および「UNASSIGNED」リストにある文字を含んでは ならない(MUST NOT)。 4.2.3. ラベルの有効性検証 登録申請されたラベル(ユニコード文字列形式の、少なくとも見かけ上はU-ラベルに 見える文字列)に対し、1文字以上の検査を必要とするテストを実行する。 文字の順番はネットワークオーダ(ネットワーク上を流れる順番: on-the-wire order)である。ネットワークオーダはディスプレイオーダ(表示される順番: display order)とは同じでない場合がある。 4.2.3.1. ハイフンの制約 ユニコード文字列は「--」(2つの連続するハイフン)を3文字目、4文字目の位置に 含んではならない(MUST NOT)。また「-」(ハイフン)で開始または終了しては ならない(MUST NOT)。 4.2.3.2. 先頭に位置する結合記号 ユニコード文字列は結合記号または結合文字(厳密な定義についてはユニコード標準 セクション2.11 [Unicode]参照のこと)で開始されてはならない(MUST NOT)。 4.2.3.3. コンテキストルール ユニコード文字列は、有効性がコンテキストに依存する文字を含んではならない (MUST NOT)。ただしその有効性がコンテキストルールで有効側に承認される場合は 例外とする。これを検査するため、Tables 文書[RFC5892]でCONTEXTJまたは CONTEXTOだと特定される各コードポイントには、何かしらルールが設定されて いなければならない(MUST)。 これらのコードポイントにルールが存在しない場合、 そのコードポイントを含むラベルは無効である。ルールは存在するが、 ルールを適用した結果が否定(negative)または不確定(inconclusive)である場合、 登録申請されたラベルは無効である。 4.2.3.4. 右から左に表記する文字を含むラベル 登録申請されたラベルが右から左に表記する用字の文字を含む場合、 Bidi 基準[RFC5893]に準拠していなければならない(MUST)。 Klensin Standards Track [Page 8] RFC 5891 IDNA2008 Protocol August 2010 4.2.4. 登録時における有効性検証の妥当性 少なくとも1文字の非ASCII文字を含み、先に記載した処理手順を踏んで生成 されており、内容はセクション4.2.3のテストをパスしており、63文字以下の ACE(ASCII-compatible)エンコーディング形式(セクション4.4参照)で表現可能な 文字列は、U-ラベルである。 要約すると、セクション4.2で行われるテストは、無効文字の検査、無効な文字の 組み合わせの検査、個々に有効な文字であっても組み合わせた結果無効となる ラベルの検査、右から左に表記する文字に関する制約に準拠しないラベルの 検査である。 4.3. レジストリの制約 先に説明したルールとテストに加えて、登録申請されたラベルをレジストリが 拒否する多くの理由が存在する。トップレベルだけに限らず、DNSのあらゆる レベルのレジストリは、ラベル登録に関してポリシを確立しているはずである。 そのポリシはおそらくその地域の言語と、それを記述する用字で情報提供 されており、ラベルの中に含まれる文字を始めとする多くの要素に依存 するだろう(例えば、登録済みの他のラベルに基づくラベルは拒否される かもしれない)。レジストリポリシに関する詳細な議論と推奨については Rationale 文書[RFC5894]セクション3.2を参照のこと。 セクション4.2の処理手順で生成された文字列はローカルレジストリの 制約に照らして検査され、適切に処理される。レジストリの制約の適用に より、ある種のラベルが拒否されたり、あるいは他者に対して特別な制約を 課する結果になる場合がある。 4.4. Punycodeへの変換 セクション4.2.1に示したように、A-ラベルを変換して得られたU-ラベルを もう一度A-ラベルに変換する(Definitions 文書[RFC5890]のセクション2.3.2.1の 定義による)。その結果得られるA-ラベルは、U-ラベルをPunycodeアルゴリズム [RFC3492]でエンコードし、ACEプレフィックス「xn--」を文字列の先頭に 付加したものである。最終的に得られた文字列は、当然DNSの文字列長の制約に 準拠していなければならない。 本文書はRFC 3492が規定するPunycodeアルゴリズムの更新または変更を一切 行わない。ただし、RFC 3492はACEプレフィックスの値および構造に関する 情報について、RFC 3490とNameprep[RFC3491]を有用な参照先として使用 している。整合性と読者の利便を図るために、IDNA2008は事実上、それらの情報に 関する参照先を本文書に更新する。この変更がプレフィックス自身を 変更することはない。プレフィックス「xn--」はどちらの一連の文書でも 同じである。 Klensin Standards Track [Page 9] RFC 5891 IDNA2008 Protocol August 2010 Pucycode出力の最大文字列長テストは例外だが、セクション4.1から セクション4.3までで規定した処理手順を踏んで生成したU-ラベルを入力する 限り、Punycodeエンコーディング手続きにおいて、処理が失敗する状況は 発生し得ない。 4.5. ゾーンへの登録 A-ラベルをゾーンに書き込むことにより、ラベルはDNSに登録される。 5. ドメイン名検索プロトコル ドメイン名検索はドメイン名登録とは異なるので、クライアント上で行われる テストも異なる。プロトコルにおける深刻な問題を回避するために幾つかの 有効性検査は必要だが、クライアント側におけるテストはより寛容で、DNSに 登録されている名前は有効であるという前提に依存する。しかしこの前提は 脆弱である。DNSの中にワイルドカードが存在すると、実際にはDNSに登録されて いない文字列のドメイン名検索が成功してしまう場合があるからである。 5.1. ラベル文字列の入力 ユーザはローカルな文字集合で構成された文字列を直接タイプしたり、 URI(Uniform Resource Identifier[RFC3986])やIRI(Internationalized Resource Identifier[RFC3987])等のドメイン名を含むリソース識別子を クリックしたりコピー＆ペーストする等の手段を経て、ローカルな文字集合で 構成された文字列を提供する。あるいは、ユーザによる直接の操作を必要と しない何らかの処理で、ファイルからそのような文字列を読み取ったり、 他の何らかの手段でそのような文字列を得たりすることもあるかもしれない。 本セクションの処理とセクション5.2で規定する処理はローカルな問題であり、 IDNAが実際に起動する前に完了しているものとする。 5.2. ユニコードへの変換 ローカルな文字集合で入力された文字列がユニコードでないならば、 これをユニコードに変換する。ローカルな需要に応じて、この変換時に幾つかの 文字を他の文字にマッピングする必要があるかもしれない。 これらの問題は、Rationale 文書[RFC5894]のマッピングに関するセクション (セクション4.2, 4.4, 6, 7.3)と、マッピングに関して独立にまとめられた Mapping 文書[IDNA2008-Mapping]で議論される。結果として得られる文字列は、 NFC形式のユニコード文字列でなければならない(MUST)。 Klensin Standards Track [Page 10] RFC 5891 IDNA2008 Protocol August 2010 5.3. A-ラベルの入力 この手続きに入力された文字列がA-ラベルのように見える(大文字小文字を 区別せずに解釈すると「xn--」で開始されている)場合、ドメイン名検索 アプリケーションはそれをU-ラベルに変換しようと試みてもよい(MAY)。 はじめにA-ラベルが全て小文字になっている状態を確保し(必要なら小文字に 変換するなどして)、セクション5.4のテストを実施し、セクション5.5の 変換処理を行う。Punycodeデコードアルゴリズムを使用してラベルを ユニコード(U-ラベル形式)に変換する場合、先の2つのセクションで 規定した処理を実行しなければならない(MUST)。また結果として得られた 文字列がオリジナルと同一でないならばそのラベルを拒否しなければ ならない(MUST)。本トピックに関する追加の議論は Rationale 文書[RFC5894]の セクション8.1を参照のこと。 ドメイン名が後に通常の文字を使用してユーザに提示される場合 (この場合ドメイン名検索アプリケーションはIDNA対応になっている必要がある)、 A-ラベルを変換して得られた結果がU-ラベルになっているかのテストを実行 すべきである(SHOULD)。この処理を行わない場合であっても、ドメイン名 検索処理は少なくとも入力された文字列が確かにA-ラベルかどうか、 またPunycodeデコード仕様が規定する無効なフォーマットでないかどうかを テストすべきである(SHOULD)。当たり前だが、IDNA未対応のアプリケーションは このテストを省略する。その場合、他のアプリケーションは、ユーザに対する 保護と情報提供は犠牲になるが、追加の処理を避け、この文字列を形式不明瞭な ものとして扱ってもよい(MAY)。 5.4. 有効性検証と文字リストに関するテスト セクション4に記述したドメイン名登録手続きと同様に、ユニコード文字列の 各文字がIDNAドメイン名検索手続きへの入力として有効であるかを検査する。 先のセクションおよび Rationale 文書[RFC5894]で論じたように、 ドメイン名検索時の検査はドメイン名登録時の検査よりも寛容である。 Definitions 文書[RFC5890] セクション2.3.2.1で議論されるように、 適用ルールに適合しているかを完全に検査していないラベルを 「仮適合(putative)」ラベルと呼ぶ。以下に示す性質を持つ仮適合U-ラベルは DNS検索前に拒否しなければならない(MUST)。 ・ ラベルがNFC形式[Unicode-UAX15]ではない。 ・ ラベルの3文字目、4文字目に「--」(2つの連続したハイフン)を含む。 ・ ラベルの先頭文字が結合記号(ユニコード標準 セクション2.11[Unicode]参照) になっている。 ・ ラベルが禁止されたコードポイントを含む場合。具体的に、 Tables 文書[RFC5892]の「DISALLOWED」カテゴリに属するものを含む場合。 Klensin Standards Track [Page 11] RFC 5891 IDNA2008 Protocol August 2010 ・ ラベルが Tables 文書の「CONTEXTJ」に属するコードポイントを含む 場合。つまり、ドメイン名検索時にコンテキストに基づく例外的処理を必要と するが、それがルールに適合していない場合。これはルールを空(null)の ままにせず定義しなければならないことを意味する。コンテキストルールが 必要だがそれが定義されていない文字は、この処理段階でルールへの適合に 失敗したものとして扱う。 ・ ラベルが Tables 文書の「CONTEXTO」に属するコードポイントを含むが、 その文字に対するルールがルール表に存在しない場合。DNS名を名前解決する、 あるいは同様の操作を行うアプリケーションは「CONTEXTO」文字のコンテキスト ルールをテストすることを要求されず、ただ単にルールが定義されているかを 検査するだけである。(ユーザに対してより良い保護と情報提供をするために これらのテストをしてもよい(MAY)ことにはなっているが)。 ・ アプリケーションが使用するユニコードのバージョンでは割り当てられて いないコードポイントをラベルが含む場合。具体的に Tables 文書の 「UNASSIGNED」カテゴリに属するものを含む場合。 この要件は、アプリケーションは、本セクションの他の要件を満たす ユニコードのバージョンの「UNASSIGNED」文字リストを使用しなければならない ことを意味する。アプリケーションは、自身が使用するユニコードのバージョン を知る必要はないが、その情報はアプリケーションが動作する環境の情報として 与えられるかもしれない。 さらに、アプリケーションは以下のテストを適用すべきである(SHOULD)。 ・ 文字列が Bidi 文書[RFC5893]が規定する右から左に表記する文字列に 関する要件を満たしているかの検査。 このテストは特別な状況下では省略してもよい。例えば、「条件を満たさない 文字列のドメイン名検索や名前解決は、ゾーン内にワイルドカードが存在しない 限りほぼ確実に失敗する」といった具合に、この条件がどこかで強制されることを ドメイン名検索アプリケーションが知っている場合である。しかし、このテストを 行えばドメイン名検索が失敗した理由についてより詳しい情報が得られるので、 それを可能な範囲でユーザに提示できれば、単にDNS名前検索が失敗したという だけの情報よりもはるかに良い情報を提供できるだろう。 先に示した仮適合ラベルや右から左に表記する文字列以外の全ての文字列に ついては、ドメイン名検索アプリケーションがラベルの有効性やラベルが含む 文字の有効性を判定する際に、ラベルがDNSの中に存在しているかどうかに 依存しなければならない(MUST)。ラベルが登録されていれば、それらは有効であると 推定される。ラベルが存在しなければ、そのラベルの有効性は不明である。 ドメイン名検索アプリケーションは、その文字列の正当性が疑わしい可能性がある ことを適切に警告してもよいが、一方でアプリケーションが先に記述したルールに 適合する文字(つまりルールに適合するがDNSには存在しない文字)の処理を拒否する ことは本プロトコルに違反する。 Klensin Standards Track [Page 12] RFC 5891 IDNA2008 Protocol August 2010 5.5. Punycodeへの変換 ドメイン名検索前の有効性検証が終わった文字列にPunycodeアルゴリズムを 適用してACE形式に変換し、ACEプレフィックス(「xn--」)を先頭に付加する。 5.6. DNS名前解決 セクション5.5の変換処理で得られた、または直接提供された(セクション5.3 参照)A-ラベルは、必要に応じて他のラベルを組み合わせてFQDNが構成され、 通常のDNSリゾルバ処理を使用してDNS検索が行われる。当然だが、 ドメイン名検索は成功するか(情報が得られるか)失敗するかのどちらかである。 6. セキュリティに関する考慮点 本バージョンのIDNAのセキュリティに関する考慮点については、右から左に 表記する用字および文字に関する特別なものを除き、Definitions 文書[RFC5890] に記述する。後者の考慮点については Bidi 文書[RFC5893]で論ずる。 他のラベルと見間違えやすくするという故意または偶然の攻撃や、文字描画に 関する特別な問題等を回避するために、IDNAモデルは、レジストリがどのラベルを 登録可とするかに関して最新の気配りと思慮深さを発揮するよう求める。 この問題は本文書のセクション4.3で議論されているが、より広範囲にわたる 議論については Rationale 文書[RFC5894]が提供している。 7. IANAに関する考慮点 本バージョンのIDNA(IDNA2008)に関するIANAへの要求は Tables文書 [RFC5892]で規定され、Rationale 文書[RFC5894]で非公式な議論がなされて いる。本文書に記述したIDNAの機能はIANAに何も要求しない。 8. Contributors While the listed editor held the pen, the original versions of this document represent 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. This document draws significantly on the original version of IDNA [RFC3490] both conceptually and for specific text. This second-generation version would not have been possible without the work that went into that first version and especially the contributions of its authors Patrik Faltstrom, Paul Hoffman, and Adam Costello. While Faltstrom was Klensin Standards Track [Page 13] RFC 5891 IDNA2008 Protocol August 2010 actively involved in the creation of this version, Hoffman and Costello were not and should not be held responsible for any errors or omissions. 9. Acknowledgments This revision to IDNA would have been impossible without the accumulated experience since RFC 3490 was published and resulting comments and complaints of many people in the IETF, ICANN, and other communities (too many people to list here). Nor would it have been possible without RFC 3490 itself and the efforts of the Working Group that defined it. Those people whose contributions are acknowledged in RFC 3490, RFC 4690 [RFC4690], and the Rationale document [RFC5894] were particularly important. Specific textual changes were incorporated into this document after suggestions from the other contributors, Stephane Bortzmeyer, Vint Cerf, Lisa Dusseault, Paul Hoffman, Kent Karlsson, James Mitchell, Erik van der Poel, Marcos Sanz, Andrew Sullivan, Wil Tan, Ken Whistler, Chris Wright, and other WG participants and reviewers including Martin Duerst, James Mitchell, Subramanian Moonesamy, Peter Saint-Andre, Margaret Wasserman, and Dan Winship who caught specific errors and recommended corrections. Special thanks are due to Paul Hoffman for permission to extract material to form the basis for Appendix A from a draft document that he prepared. 10. References 10.1. Normative References [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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. Klensin Standards Track [Page 14] RFC 5891 IDNA2008 Protocol August 2010 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010. [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010. [Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", September 2009, . 10.2. Informative References [ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968. ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet. [IDNA2008-Mapping] Resnick, P. and P. Hoffman, "Mapping Characters in Internationalized Domain Names for Applications (IDNA)", Work in Progress, April 2010. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006. Klensin Standards Track [Page 15] RFC 5891 IDNA2008 Protocol August 2010 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007. [RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010. [Unicode] The Unicode Consortium, "The Unicode Standard, Version 5.0", 2007. Boston, MA, USA: Addison-Wesley. ISBN 0-321-48091-0. This printed reference has now been updated online to reflect additional code points. For code points, the reference at the time this document was published is to Unicode 5.2. Klensin Standards Track [Page 16] RFC 5891 IDNA2008 Protocol August 2010 Appendix A. Summary of Major Changes from IDNA2003 1. Update base character set from Unicode 3.2 to Unicode version agnostic. 2. Separate the definitions for the "registration" and "lookup" activities. 3. Disallow symbol and punctuation characters except where special exceptions are necessary. 4. Remove the mapping and normalization steps from the protocol and have them, instead, done by the applications themselves, possibly in a local fashion, before invoking the protocol. 5. Change the way that the protocol specifies which characters are allowed in labels from "humans decide what the table of code points contains" to "decision about code points are based on Unicode properties plus a small exclusion list created by humans". 6. Introduce the new concept of characters that can be used only in specific contexts. 7. Allow typical words and names in languages such as Dhivehi and Yiddish to be expressed. 8. Make bidirectional domain names (delimited strings of labels, not just labels standing on their own) display in a less surprising fashion, whether they appear in obvious domain name contexts or as part of running text in paragraphs. 9. Remove the dot separator from the mandatory part of the protocol. 10. Make some currently valid labels that are not actually IDNA labels invalid. 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 Standards Track [Page 17]