Internet Engineering Task Force (IETF) J. Klensin Request for Comments: 5890 2010年8月 廃止: 3490 分類: 標準化過程(Standards Track) ISSN: 2070-1721 アプリケーションにおけるドメイン名の国際化(IDNA) 定義および文書のフレームワーク 要旨 本文書は、一連の文書群を構成する複数文書の中の1つで、他の文書と併せて IDNA(Internationalized Domain Names for Applications)の古いバージョンを 置き換える改訂版のプロトコルと、プロトコルが使用される状況について 記述する。本文書は他の関連文書を含む一連の文書群について記述し、 その一連の文書群で共通に参照される定義や他の資料を提供する。 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/rfc5890. Klensin Standards Track [Page 1] RFC 5890 IDNA Definitions 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 5890 IDNA Definitions August 2010 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. IDNA2008 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1. 想定する読者 . . . . . . . . . . . . . . . . . . . . . 4 1.1.2. 基準を定める用語 . . . . . . . . . . . . . . . . . . . 5 1.2. IDNA2008に関連する文書群のロードマップ . . . . . . . . . . 5 2. 定義と専門用語 . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. 文字と文字セット . . . . . . . . . . . . . . . . . . . . . 6 2.2. DNSに関連する専門用語 . . . . . . . . . . . . . . . . . . 6 2.3. IDNA固有の専門用語 . . . . . . . . . . . . . . . . . . . . 7 2.3.1. LDH ラベル . . . . . . . . . . . . . . . . . . . . . . 7 2.3.2. IDNラベルコーディングに関する用語 . . . . . . . . . . 11 2.3.2.1. IDNA適合文字列とA-ラベル、U-ラベル . . . . . . . . 11 2.3.2.2. NR-LDHラベル . . . . . . . . . . . . . . . . . . . 13 2.3.2.3. 国際化ドメイン名と国際化ラベル . . . . . . . . . . 13 2.3.2.4. ラベルの等価性 . . . . . . . . . . . . . . . . . 14 2.3.2.5. ACEプレフィックス . . . . . . . . . . . . . . . . 14 2.3.2.6. ドメイン名スロット . . . . . . . . . . . . . . . . 14 2.3.3. ラベルにおける文字の順序 . . . . . . . . . . . . . . . 15 2.3.4. 「Punycode」という用語の明確化 . . . . . . . . . . . . 15 3. IANAに関する考慮点 . . . . . . . . . . . . . . . . . . . . . . 16 4. セキュリティに関する考慮点 . . . . . . . . . . . . . . . . . . 16 4.1. 一般的な問題 . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. U-ラベルの長さ . . . . . . . . . . . . . . . . . . . . . . 16 4.3. ローカルな文字集合に関する問題 . . . . . . . . . . . . . . 17 4.4. 視覚的に似た文字 . . . . . . . . . . . . . . . . . . . . . 17 4.5. IDNAの検索・登録処理が基本DNS仕様に与える影響 . . . . . . 18 4.6. 旧来のIDNラベル文字列に関する問題 . . . . . . . . . . . . 18 4.7. セキュリティの観点から見たIDNA2003との違い . . . . . . . . 19 4.8. その他 . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Normative References . . . . . . . . . . . . . . . . . . . 20 6.2. Informative References . . . . . . . . . . . . . . . . . . 21 Klensin Standards Track [Page 3] RFC 5890 IDNA Definitions August 2010 1. はじめに 1.1. IDNA2008 本文書は、一連の文書群を構成する複数文書の中の1つで、他の文書と併せて 2008年に大規模な改訂が完了したIDNA(Internationalized Domain Names for Applications)のプロトコルと、プロトコルが使用される状況について記述する。 この新しい改訂版のIDNAは、この一連の文書群や他の文書で「IDNA2008」として 知られるものである。一連の文書群は、[RFC3490]および[RFC3491]に記載がある IDNAの古いバージョンを置き換える。便宜を図るために、一連の文書群では この古いバージョンのIDNAを「IDNA2003」と表記する。新しいバージョンでも、 古いバージョンで使用していたPunycodeアルゴリズム[RFC3492]と ACE(ASCII-compatible encoding)プレフィックスを継続して使用する。 一連の文書群に関する説明はセクション1.2で行う。そこで改めて示唆するが、 本文書は一連の文書群で共通に参照される定義と資料を提供するものである。 1.1.1. 想定する読者 多くのIETF仕様はもっぱらプロトコル実装者を対象としているが、 IDNAはその性質上、以下のような事柄について判断を下す責任者も、 その仕様を理解し適切に使用または運用することが求められる。 ・ DNSゾーンファイルで許容する名前 ・ 名前および名前付けに関連するポリシー ・ ファイルやシステム内におけるドメイン名文字列の処理。これはドメイン名を 検索で使用する場合に限らない。 本文書および他の文書に含まれる、プロトコル定義、右から左に表記する文字を 含む場合の文字列処理ルール、実際に対象となる文字およびカテゴリ(category)の リストといった記述は、プロトコル実装者の主な興味だろう。一方で、本文書と 他の文書に含まれる解説資料は、プロトコル実装者以外の主要な興味をひく だろう。しかし、彼らもまた何らかの記述について詳細な情報を得るために、 一連の文書に含まれる他の文書を参照する必要があるかもしれない。 本文書と他の関連文書は、IDNAについて知っているユーザまたはIDNA対応 アプリケーション・実装の視点から記述している。これら一連の文書では、 読者の便宜を図るために基本的なDNSルールや要件を再度記述する場合があるが、 DNSの基本的な事柄を全て網羅するような記述はしていない。したがって、 これらの記述がDNSプロトコルおよびDNS仕様の完全な理解を与えると 考えるべきではない。 Klensin Standards Track [Page 4] RFC 5890 IDNA Definitions August 2010 1.1.2. 基準を定める用語 本文書におけるキーワード「しなければならない(MUST)」、「してはならない (MUST NOT)」、「要求される(REQUIRED)」、「するものとする(SHALL)」、 「しないものとする(SHALL NOT)」、「すべきである(SHOULD)」、「すべきでない (SHOULD NOT)」、「推奨される(RECOMMENDED)」、「してもよい/することがで きる(MAY)」、「任意である(OPTIONAL)」は、[RFC2119]の記述どおりに解釈 される。 1.2. IDNA2008に関連する文書群のロードマップ IDNA2008は以下の文書で構成される。 ・ 本文書：一連の文書群を構成する他の文書を理解するために必要な定義と 資料を含む。他の文書から非公式に「Defs」または「Definitions」という 名称で参照される。 ・ RFC 5894 [RFC5894]：プロトコル概観と、プロトコルが対象とする 文字データベース表を解説資料とともに提供する。またIDNA2008を開発 するに至った動機付けも提供する。さらに、この文書はレジストリ処理や 国際化ドメイン名(IDN)の利用者に向けたアドバイスも含む。 他の文書からは非公式に「Rationale」という名称で参照される。 この文書はプロトコル規定を行うものではない。 ・ RFC 5891 [RFC5891]：IDNA2008の主要なプロトコルとその処理を記述する。 この次に示す「Bidi」文書と併せて、RFC 3490を明示的に更新する。 他の文書からは非公式に「Protocol」という名称で参照される。 ・ RFC 5893 [RFC5893]：右から左に表記する文字を含むラベルに対して 適用する特別なルール(Bidi)を規定する。 ・ RFC 5892 [RFC5892]: ユニコード 5.2 [Unicode52]のコードポイント 割り当ておよびIDNA2008固有の付加的ルールに基いて、コードポイントの 分類と、通常の文字(後にセクション2.3.2.1で「U-ラベル」として詳細に 定義する)で構成するラベルが許容するコードポイントを特定するルールを 規定する。ユニコードに関連するルールは、ユニコード標準が更新されても 安定していること、すなわちユニコードのバージョンとは独立している ことが期待される。この規定はRFC 3491と、RFC 3491が参照する文字 データベース表を使用するIDNを廃止する。他の文書からは非公式に 「Tables」という名称で参照される。 Klensin Standards Track [Page 5] RFC 5890 IDNA Definitions August 2010 ・ 文書 [IDNA2008-Mapping]：ある文字を別の文字にマッピングする際に発生する 問題を論ずる。またマッピングすることが適切である場合にその処理を行う ガイドラインを提供する。他の文書から非公式に「Mapping」という名称で 参照されるこの文書はアドバイスを提供するものであり、IDNAの必須部分 ではない。 2. 定義と専門用語 2.1. 文字と文字セット コードポイントとは、コード化された文字セットのコード空間内に含まれる 整数値である。ユニコードでは、0から0x10FFFFまでの整数値である。 ユニコード [Unicode52] はコード化された文字セットであり、バージョン5.2の 時点で100,000文字を若干越えるコードポイントが割り当てられている。 一連の文書群において、単一のユニコードコードポイントを表記する場合、 「U+」に4桁～6桁の16進数を続ける表記法を使用する。また、ユニコード コードポイントの範囲を表記する場合はプレフィックスを付けず、2つの 4桁～6桁の16進数を「..」で区切る表記法を使用する。 「ASCII」はUS-ASCII [ASCII] を意味する。ASCIIは 0000..007Fの範囲内にある コードポイントを持つ128文字のコード化された文字セットである。ユニコードは 全てのASCII文字を含み、各文字を等価なコードポイントにそれぞれ関連づけて いるので、ユニコードはASCIIのスーパーセットであり、ASCIIの一般化と 考えられる。 「英字(letters)」はASCIIおよびその用語から受ける常識的な認識を非公式に 一般化したものである。つまり、数字・記号・句読点以外の文を記述する際に 使用する文字を指す。公式には、「L」から始まるユニコードのGeneral Category (一般カテゴリ)値を持つ文字である (ユニコード標準 [Unicode52]の セクション4.5参照)。 2.2. DNSに関連する専門用語 本文書でDNSについて論じる場合、DNS仕様 [RFC1034] [RFC1035] で使用された 専門用語は [RFC1123] および [RFC2181] で改訂されているものとして扱う。 「検索(lookup)」という用語は、IDNA2008プロトコルが実行する処理と DNSリゾルバが実際に実行する処理の組み合わせを表現する際に使用する。 エントリをDNSに追加する処理を「登録(registration)」と呼ぶことにする。 これは他の文脈の中で伝統的に広く使用されてきたものと同様である。 したがって、本文書では、あらゆるDNSゾーン管理作業主体を「レジストリ」と 表記する。また「レジストリ」という用語は、実際の管理上の取り決めや DNSツリーのレベルによらず、「ゾーン管理者」という用語と置き換え可能な ものとして使用する。これらの用語の関係に関する詳細は Rationale 文書に 記載がある。 Klensin Standards Track [Page 6] RFC 5890 IDNA Definitions August 2010 「LDHコードポイント」という用語は本文書が定義するもので、ASCII英字 (ユニコードコードポイント 0041..005A および 0061..007A)、数字 (0030..0039)、ハイフン(マイナス) (U+002D) のいずれかに含まれる コードポイントである。「LDH」は「英字,数字,ハイフン」の短縮形だが、 本文書では特にセクション2.3.1以降に記載する名前付けルールの集合を 指す際に使用する。 基本DNS仕様 [RFC1034] [RFC1035] では「ドメイン名」と「ホスト名」について 記述しているが、これらの文書の幾つかのセクションにおいて、この2つの用語を 置き換え可能なものとして使用したことから、多くの人々もまたこの2つの用語を 置き換え可能なものとして使用している。しかし、これまでに幾つかの事例に おいて、専門用語が指し示すものが明確でないことによって、意図が正しく 伝わらず混乱が生じている。これらの文書では、一般に「ドメイン名」という 用語を使用する。例えばホスト名の書式の制約といった内容に言及する場合、 これらの文書では明示的にその用語を定義した適切な文書を引用している。 このサブセクションで行われる残りの定義は本質的にはレビューである。 ここで行われる定義と、基本DNS文書で行われる定義または以下で引用する 文書の定義の間に違いがある場合、後者の文書群の定義を優先するものとする。 ラベルはドメイン名の個々の構成要素である。通常、ラベルはドット(.)で 区切って示される。例えば、ドメイン名「www.example.com」は3つのラベル 「www」,「example」,「com」で構成される。(RFC 1123 [RFC1123] に 記載がある、ドメイン名の最後にドットを付ける名前表記の慣習を使用するか どうかで、明示的に「www.exampe.com.」とも暗示的に「www.example.com」とも 書けるが、本仕様では検討の対象としない)。IDNAはテキストとして処理される ラベルで使用可能な文字セットを拡張する。(テキストで処理されるとはつまり、 RFC 1035とRFC 2181 [RFC2181]で規定するバイナリ文字列ラベルや、RFC 2673 [RFC2673]で規定するビット列ラベルとは別の処理を行うことを意味する)。 しかしこれは特定の文脈の中だけのことである。別の利用可能な文字セットに 対応する異なる文脈については、次のセクションで概略を示す。本文書の 残りの部分と本文書に関連する文書において、この拡張された文脈も考慮し、 「ラベル」とは「テキストラベル」の簡略表現であり、「各ラベル」は 「各テキストラベル」を意味するものとする。 2.3. IDNA固有の専門用語 本セクションでは、過去に問題を引き起こした用語や定義への依存を低減させる ために、幾つかの専門用語を定義する。各定義の関係を図1および図2に示す。 これらの図の上部に書かれている()で囲まれた数字は、図の下に記した注記の 番号を参照する。 2.3.1. LDH ラベル 多少の制約はあるが、ホスト名 [RFC0952]で使用されてきた古典的なラベル形式。 書式は、RFC 1034[RFC1034]のセクション3.5で「望ましい名前の書式」として 初めに記述され、後にRFC 1123[RFC1123]で修正されたものと同じである。 (訳注：次ページ先頭に続く） Klensin Standards Track [Page 7] RFC 5890 IDNA Definitions August 2010 簡潔にまとめると、LDH ラベルとは、 ASCII英字、数字、ハイフンで構成された 文字列で、ハイフンが文字列の先頭または末尾に現れないという制約を満たす ものである。全てのDNSラベル同様に、ラベルの全長が63オクテットを超えては ならない。 LDHラベルは、IDNAが使用する特殊なラベル(以下で「A-ラベル」と記述する)と、 幾つかの付加的な制約を持つ形式(以下に記述する)を含む。 IDNA導入に際し、明確な記述を円滑に行うために、LDHラベルのサブセットを 新規に2つ作成する。それぞれR-LDH(Reserved LDH)ラベル、NR-LDH(Non-Reserved LDH)ラベルと呼ぶことにする。R-LDHラベルは別の文脈で「タグ付きドメイン名」 として知られるもので、3文字目および4文字目に「--」を含むという特徴を 持つが、それ以外はLDHラベルのルールに準拠するものである。このR-LDHラベルの サブセットだけがIDNA対応アプリケーションで使用できる。このサブセットは、 プレフィックス「xn--」(大文字・小文字に非依存)で始まる以外はLDHラベルの ルールに準拠するラベルのクラスで構成される。IDNA2008に関連する一連の 文書群では、このサブセットを「XN-ラベル」と呼ぶ。 XN-ラベルは、プレフィックスを除いた文字(「xn--」以後の文字)が Punycode アルゴリズム [RFC3492]の有効(valid)な出力であるか、そうでないか(後述)に 応じて更に分類される。有効な Punycode の出力で構成される XN-ラベルは、 後述するIDNA有効性検査の基準を満たしていれば「A-ラベル」として知られるもの となる。LDHラベル(および事実上全てのDNSラベル)は63オクテットを超える長さで あってはならないので、XN-ラベル中の Punycode アルゴリズムから導出される 部分は、ASCII 文字 59文字以内でなければならない。 NR-LDHラベルは、3文字目および4文字目の位置に「--」を含まない有効な LDHラベルの集合である。 通常のユニコード文字(U-ラベルの項参照)で表現された有効な文字に対して 制約を課した結果が文字種注釈(mixed-case annotation。RFC 3492 [RFC3492]の 付録Aに概略がある)なのだが、これは決して便利なものではない。 有効なA-ラベルはU-ラベルをPunycodeエンコーディングした結果なのだから、 DNS内に存在する潜在的な(大文字で構成された、または大文字小文字が混在して 構成された)ラベルの一致検査は必要であるにせよ、A-ラベルは小文字だけを 使用して生成すべきである。 ある文字列に「xn--」プレフィックスを付加して作られたラベルは、 Punycode アルゴリズムの出力ではないかもしれない。あるいは後述する 他のテストで不正と判断されたり、IDNAに関する他の制約に違反するなどして 有効なIDNAラベルではない場合がある。便宜上これらを「疑似A-ラベル」と 呼ぶことにする。 Klensin Standards Track [Page 8] RFC 5890 IDNA Definitions August 2010 R-LDHラベルのクラスに属するが、「xn--」プレフィックスを持たない ラベルも有効なIDNAラベルではない。将来において、IDNAに似た仕組みの 使用を許容するために、IDNA準拠のプログラムはこれらのラベルを 通常のLDHラベルとして処理してはならない(MUST NOT)。 また、同じゾーン内でIDNAラベルと混在させるべきではない(SHOULD NOT)。 本質的にはLDHラベルに属するこれらのラベル間の区別は、今現在「IDN対応」の ソフトウェアや、または現在と同じ「プレフィックスを先頭に付加する エンコーディング」モデルを使用する将来の拡張においてだけ意味を持つ。 IDNA対応システムにとって有効なラベルタイプとは、A-ラベル、U-ラベル、 NR-LDHラベルである。 IDNAラベルには2つの形式がある。ACE でエンコードされた形式と、通常の文字 をユニコードで表現した形式である。これらをそれぞれ A-ラベル、U-ラベル と呼び、詳細を次のセクションに示す。 Klensin Standards Track [Page 9] RFC 5890 IDNA Definitions August 2010 ASCIIラベル __________________________________________________________________ | | | ____________________ LDH ラベル (1) (4) _______________ | | | ___________________________________ | | | | |IDN Reserved LDHラベル | | | | | | ("??--")またはR-LDHラベル | _______________ | | | | | _______________________________ | | Non-Reserved| | | | | | | XNラベル | | | LDH ラベル | | | | | | | _____________ ___________ | | | (NR-LDH | | | | | | | | A-ラベル | | 疑似 (3) || | | ラベル) | | | | | | | | "xn--"(2) | | A-ラベル || | |_____________| | | | | | | |___________| |__________|| | | | | | | |_____________________________| | | | | | |_________________________________| | | | |_______________________________________________________| | | | | _____________非LDH ラベル ________ | | | ______________________ | | | | |アンダースコアラベル| | | | | | 例えば _tcp | | | | | |____________________| | | | | | 先頭または末尾に | | | | | | ハイフンが存在する | | | | | | ラベル 「-abcd」 | | | | | | または 「xyz-」 | | | | | | または 「-uvw-」 | | | | | |____________________| | | | | | 他の非LDH ASCII文字| | | | | | で構成されたラベル | | | | | | 例えば #$%_ | | | | | |____________________| | | | |________________________________| | |________________________________________________________________| (1) ASCII 英字 (大文字および小文字)、数字、ハイフン。 ハイフンは先頭・末尾には現れない。63オクテットを 超えない。 (2) 「xn--」に続く文字列はPunycodeアルゴリズムの有効な出力で なければならず、また有効なU-ラベル形式と相互に変換可能で なければならないことに注意してもらいたい。 (3) 疑似A-ラベルはプレフィックス「xn--」を持つが、それに続く ラベルがPunycodeアルゴリズムの有効な出力「ではない」ことに 注意してもらいたい。 (4) LDHラベルの亜種はIDNA未対応のアプリケーションには 区別できない。 図1: IDNAおよび関連するDNSの専門用語の関係図 -- ASCIIラベルに関連するもの Klensin Standards Track [Page 10] RFC 5890 IDNA Definitions August 2010 __________________________ | 非ASCII | | | | ___________________ | | | U-ラベル (5) | | | |_________________| | | | | | | | バイナリラベル | | | | (High-bitがONの | | | | ものも含む ) | | | |_________________| | | | | | | | ビット列ラベル | | | | | | | |_________________| | |________________________| (5) IDNA未対応のアプリケーションからはU-ラベルと バイナリラベルとを区別できない 図2: 非ASCIIラベル 2.3.2. IDNラベルコーディングに関する用語 2.3.2.1. IDNA適合文字列とA-ラベル、U-ラベル IDNA対応アプリケーション用の有効なラベルは「A-ラベル」「U-ラベル」 「NR-LDHラベル」の3種類であり、以下のように定義される。 これら3つの関係は図1および図2に示した。 ・ 文字列がIDNAラベルに関する一連の仕様が定めた条件に適合する場合、 その文字列は「IDNA適合」である。IDNA適合文字列は、この直後に定義 するように、あるいはNR-LDHラベルのサブセットから引用するように、 2つの形式のどちらかで現れる。IDNA適合文字列は、基本的なDNSのラベルに 関する要件全てに準拠していなければならない。IDNA2008に関連する一連の 文書群は、IDNA適合文字列の2つの形式に関して、それを区別することが 重要なあらゆる文脈では、これらを個別に参照する。 ・ 「A-ラベル」は ACE (ASCII-Compatible Encoding。セクション2.3.2.5参照) 形式で表現されたIDNA適合文字列である。A-ラベルは、それ自体で完成した ラベルでなければならない。IDNAはラベルに対して定義されるものであり、 ラベルの一部分だけまたはドメイン名全体に対して定義されるものではない。 これはつまり、定義により、各A-ラベルはIDNA ACEプレフィックス「xn--」で 始まり(セクション2.3.2.5参照)、Punycodeアルゴリズム [RFC3492]の有効な 出力である文字列がそれに続くもので、またその長さがASCII文字で 最大59文字であることを意味する。プレフィックスと文字列は、ともに DNSに保存可能なラベルに関する要件全てに準拠していなければならない。 この要件はセクション2.3.1に記載があるLDHラベルに関するルールも含む。 上に示した要件に適合する文字列がU-ラベルにデコードできる場合に限り、 その文字列はA-ラベルであると言える。 Klensin Standards Track [Page 11] RFC 5890 IDNA Definitions August 2010 ・ 「U-ラベル」はNFC形式のユニコード文字で構成されており、 (UTF-8のような)標準ユニコードエンコーディング形式で表現された 最低1文字の非ASCII文字を含むIDNA適合文字列である。また、U-ラベルは Protocol文書のセクション4.2が規定する、プロトコルが許容する文字に 関する制約を満たし、Tables文書のセクション2およびセクション3の ルールに準拠する。さらに、ラベルが右から左に表記する用字(言語を表現 するために用いられる文字)の文字を含む場合、Bidi文書が規定する制約と、 この後に記述するA-ラベルとの1:1対応に関する制約も満たす。U-ラベルと A-ラベルの変換は「Punycode」仕様 [RFC3492]にしたがって行われ、必要に 応じてACEプレフィックスが追加または削除される。 U-ラベルおよびA-ラベルが有効であるためには、両者とも重要な1:1対応に 関する制約を満たさなければならない。この制約をテストするには様々な手法が あるが、A-ラベルA1はU-ラベルU1を変換して生成できなければならず、その U-ラベルU1はA-ラベルA1を変換して生成できなければならない。 特に、これはU-ラベルとA-ラベル双方がユニコードNFC正規化形式 [Unicode-UAX15]の文字列でなければならないことを意味する。 これらの文字列は、IDNA2008に関連する一連の文書群で規定された文字だけで 構成されなければならず、また一連の文書群で適切と規定されたコンテキスト だけで使用されなければならない。 一般にDNSに適用される任意のルールまたは慣習は、U-ラベルに対しても、 A-ラベルに対しても、より制約が強い形で適用される。この基本原則には 例外が2つ存在する。第1に、ASCII文字に対する制約はU-ラベルには適用されない。 第2に、A-ラベル形式を拡張してU-ラベルにする場合、Pynycodeアルゴリズムの 圧縮効率の影響で、生成される文字列はDNSの一般的な制限である63オクテットを 大きく越える場合がある(潜在的には最大252文字までになる)。 そのような長大な長さを持つU-ラベルは、IDNAの観点からは有効だが、 アプリケーションによってはより短い制限を採用している場合があるので 注意が必要である。 IDNA未対応アプリケーションは、LDHラベルがDNSゾーンファイル内または 問い合わせ内に現れる場合、それら全てを有効なものとして扱うので、 アプリケーションによっては付加的なタイプ(LDHラベルの制約を受けない)の ラベルを許容する場合もある。 IDNA対応アプリケーションの場合、DNSゾーンファイル内または問い合わせ内で 許容するのはA-ラベルおよびNR-LDHラベルだけである。 U-ラベルに関しては、何らかの表示を行う場合や、ユーザインターフェース フォーム、IDNA形式を使用するがDNSを使用しないプロトコルの中で、A-ラベル またはNR-LDHラベルに付随して現れることができる。 Klensin Standards Track [Page 12] RFC 5890 IDNA Definitions August 2010 具体的に、IDNA対応アプリケーションおよびIDNAコンテキストが許容する 3つの区分は、A-ラベル、U-ラベル、NR-LDHラベルである。 R-LDHラベル(Reserved LDHラベル)ではA-ラベルだけがIDNA使用に 有効である。 見かけ上A-ラベルまたはU-ラベルに見える文字列は、Protocol文書 [RFC5891]の 様々な操作で処理される。これらの文字列は、この段階ではまだ有効性検証の 処理中であるから、先に概説した条件に明確に適合することが検証されていない。 このような文字列は「有効性未検証の」「仮適合の」「見掛け上の」と称される。 あるいは、規定された適合性条件を満たすか検証が済んでいないことを示す ラベルタイプの「形態を持つ」と称される。 有効性未検証のA-ラベルはXN-ラベルだけであることが知られているが、 疑似A-ラベルはA-ラベルテストの幾つかに失敗することが実証されたラベル である。同様に、有効性未検証のU-ラベルは、単にU-ラベルの要件を満たすか 満たさないかが不明な非ASCIIラベルである。 2.3.2.2. NR-LDHラベル IDNA2008に関する一連の仕様において、「NR-LDHラベル」という語は、 セクション2.3.1に記述するLDHラベルの書式にしたがい、IDNでもIDNAが予約する ラベル形式(R-LDHラベル)でもない全てのASCIIラベルを正確に指す場合に 使用する。全てのA-ラベルは、ラベル長の制約を除けば「ホスト名」[RFC0952] ルールにしたがうということとは強調しておくべきだろう。 2.3.2.3. 国際化ドメイン名と国際化ラベル 「国際化ドメイン名」(IDN)は少なくとも1つのA-ラベルまたはU-ラベルを含む ドメイン名だが、他のラベルはNR-LDHラベル、A-ラベル、U-ラベルが混在して いてもよい。ASCII名の事例と同様に、DNSゾーン管理者は、もともとDNSや IDNAが持つ制約に加えて、管理するゾーンに登録するラベルに含まれる文字 または文字列に関して、何らかの付加的な制約を導入するかもしれない。 U-ラベルで使用できる文字の多様性のために混乱が生じる可能性があるため、 IDNA2008仕様にはこのような制約が含まれないものの、IDNレジストリや ゾーン管理者にはこの制約が必須である(この問題については Protocol文書 [RFC5891]のセクション4.3に詳細な議論がある)。「レジストリの制約」として 知られるこれらの制約は、登録されるラベルにだけ影響し、検索処理は 影響されないので、DNSプロトコルメッセージの構文や意味付けには何も 影響がない。つまり、ある名前への問い合わせに一致するレコードが 存在しなければ、その情報がゾーン内に存在しない理由に関わらず 同じメッセージが返される。問い合わせを発行したり、応答を解釈したりする クライアントがゾーン固有の制約または慣習について知っているという前提を 置くことはできない。詳細な議論については Rationale文書 [RFC5894]の 登録ポリシのセクションを参照のこと。 Klensin Standards Track [Page 13] RFC 5890 IDNA Definitions August 2010 「国際化ラベル」という語は、IDNに含まれる単一ラベルを参照する語が必要な 場合に使用する。これはつまり、国際化ラベルはNR-LDHラベル、A-ラベル、 U-ラベルのどれかになるということである。DNSラベルは幾つか標準化された 書式を持つが、例えばSRV(Service Location)レコード [RFC2782] が使用する 「アンダースコアラベル」は、この3つの分類のどれにも属さないので 国際化ラベルではない。 2.3.2.4. ラベルの等価性 IDNAでは、ラベルが等価であるという概念はA-ラベルの観点から定義される。 A-ラベルが大文字小文字を区別しない形式で等価であれば、その2つのラベルが どのように表示されているかに関わらず、それらは等価だと見なす。 IDNA2008ではA-ラベルとU-ラベルは同型(isomorphism)なので、U-ラベル同士を 比較することもできる。詳細は Protocol文書 [RFC5891] を参照のこと。 伝統的なLDHラベルは既に等価の概念を持っている。LDHラベルを構成する 個々の文字は、それぞれ大文字であっても小文字であっても等価であると見なす。 IDNAの等価の概念は従来の概念を拡張したものだが、プロトコルは必須の マッピングを規定しておらず、U-ラベルとA-ラベルの同型だけを対象とする ことから、等価といえる状態は以下に示すものだけである。 ・ U-ラベルのペアが完全一致する(ビット列レベルで同一になる)。 ・ A-ラベルのペアがDNSが通常使用する大文字小文字を区別しない一致照合 ルールで一致する。 ・ U-ラベルとA-ラベルの等価性は、U-ラベル形式をA-ラベル形式に変換し、 その後A-ラベル同士をDNSが通常使用する大文字小文字を区別しない 一致照合ルールで一致するかどうかで判定する。 2.3.2.5. ACEプレフィックス 「ACEプレフィックス」は本文書が定義する用語で、各A-ラベルの先頭に現れる ASCII文字列「xn--」を指す。「ACE」は「ASCII-Compatible Encoding」を表す。 2.3.2.6. ドメイン名スロット 「ドメイン名スロット」は本文書が定義する用語で、ドメイン名を渡すことが 明示的に指定されたプロトコル要素や関数の引数、戻り値(等々)を指す。 ドメイン名スロットの例として、DNSクエリのQNAMEフィールドや、標準Cライブラリ 関数のgethostbyname()またはgetaddrinfo()の引数、E-Mailアドレスの＠記号に 続く部分でSMTP MAILまたはRCPTコマンドのパラメータやE-Mailメッセージヘッダ の「From:」フィールドで使われる部分、HTML タグの src 属性のURIの ホスト部などが挙げられる。ドメイン名の構文を持つが、一般的なテキストの中に 現れる文字列はドメイン名スロットに入っていない。例えば、E-Mailメッセージの 平文ボディ部に現れるドメイン名はドメイン名スロットを占有しない。 Klensin Standards Track [Page 14] RFC 5890 IDNA Definitions August 2010 「IDNA対応ドメイン名スロット」はIDNA2008に関連する一連の文書群のために 定義される用語で、本文書が定義する国際化ドメイン名を渡すことが明示的に 指定されるドメイン名スロットを指す。指定は静的(例えばプロトコルの仕様や インターフェース仕様で指定する)に行ってもよいし、動的(例えば対話型 セッションでネゴシエート結果に応じて指定する)に行ってもよい。 IDNA対応でないドメイン名スロットは、明らかにIDNA以前に仕様が規定された 全てのドメイン名スロットを含む。DNSにデータを保存する幾つかの プロトコルでは、その要件がIDNの使用を抑制することに注意してもらいたい。 例えば、サービスロケーションプロトコル [RFC2782] が使用するアンダースコア ラベルの要求フォーマットは、DNSにおけるA-ラベルを使用した非ASCIIラベル 表現を排除している。SRVに関連するラベルはアンダースコアで始まらなければ ならないからである。もちろん、アンダースコアラベルを含むドメイン名の 一部が非ASCII IDNラベルになることもある。 2.3.3. ラベルにおける文字の順序 IDNラベルは右から左に読んだり優先して表示したりする文字を含む場合が あるので、どの文字がラベルの「先頭」かは潜在的に不明確である。 IDNA2008の一連の仕様を記述するに際して、ラベルや文字は厳密に順序 づけられ、ネットワークオーダ(ネットワーク上を流れる順番: on the wire order)で現れると考える。 この順序は、左から右に読むラベルの場合、左端の文字が先頭になり、 右から左に読むラベルの場合、右端の文字が先頭になるのと等価である。 読む順序に影響を与える条件に関する更なる議論は Bidi 仕様に記載がある。 2.3.4. 「Punycode」という用語の明確化 「Punycode文字列」はACEプレフィックスを含むのかどうか、またACE プレフィックス付き文字列をToASCII処理(RFC 3490セクション4 [RFC3490] 参照)の出力とすることが要求されているのかについて、ある種の混乱が 存在した。本仕様では、「Punycode」という用語をエンコーディング法や RFC 3492 [RFC3492]のアルゴリズム以外のものを指す場合には使用しない。 先に定義した用語は「Punycode文字列」という用語よりもはるかに明確 なので、これらの用語を優先して使用する。 Klensin Standards Track [Page 15] RFC 5890 IDNA Definitions August 2010 3. IANAに関する考慮点 本バージョンのIDNA(IDNA2008)に関するIANAへの要求は Tables文書 [RFC5892]で規定される。多様なIANAレジストリ間の関係の概略は Rationale文書 [RFC5894]に記載がある。本文書はIANAへの要求を 規定しない。 4. セキュリティに関する考慮点 4.1. 一般的な問題 インターネット上のセキュリティは部分的にDNSに依存する。したがって、 DNSの特性に関するあらゆる変更は、インターネットの大部分における セキュリティに変更を生じさせ得る。 ユーザはインターネットホストや他のネットワークリソースを特定したり 接続したりする際にドメイン名を使用する。単一の国際化ドメイン名を 入力したユーザが、国際化ドメイン名の異なる解釈によって、異なるサーバに 接続された場合、インターネットのセキュリティは侵害される。 IDNA2003およびマッピングの慣習(セクション4.6参照)が許容する文字に ついて、現在の仕様では少量の文字の解釈を変更し、以前のバージョンとは 異なるマッピングを行う。ゾーン管理者はこれが原因で生じる可能性のある 問題について意識し、適切な対策を採るべきである。この問題の背景に ついては Rationale文書 [RFC5894]に詳細な議論がある。 本文書のセキュリティに関する考察の記述に加えて、Bidi文書 [RFC5893]に 通常右から左に表記する用字の文字を含むラベル固有のセキュリティに 関する問題の記載がある。 4.2. U-ラベルの長さ RFC 1035の一般的な制約と、メッセージ生成時に6ビットのラベル長に実際に DNSへの問い合わせるラベルを続ける形式で処理する必要性から、DNSに 関連するラベルは伝統的に63オクテット以内に制限されていた。 この書式は他のアプリケーションでも使用されており、またドメイン名を ドットで区切ったラベルの並びとしての表現と、文字列長-文字列のペアでの 表現は置き換え可能なものとして扱われてきた。A-ラベル(実際にDNSで 使用される形式)はUTF-8よりも圧縮率が高い場合が多い(またUTF-8は一般に UTF-16またはUTF-32よりも圧縮率が高い)ので、A-ラベルとの1:1対応や 他の制約に全てしたがうU-ラベルは、やや長くなってしまう場合がある。 潜在的には最大252文字(ユニコードコードポイント)にまでなる可能性がある。 このようなラベルを含むFQDNは、明らかに通常の名前の上限である 255オクテットを越えてしまう。U-ラベルを使用するアプリケーション作者は、 バッファオーバーフローや切り詰め(truncation)エラー、より短い文字列が 期待される状況における攻撃などを回避するために相当の注意を発揮しなければ ならない。 Klensin Standards Track [Page 16] RFC 5890 IDNA Definitions August 2010 4.3. ローカルな文字集合に関する問題 システムがASCIIやユニコードではなくローカルな文字集合を使用する場合、 アプリケーションまたはローカルシステムにあわせてローカルな文字集合と ユニコードを変換する問題が生じる。異なるアプリケーション(または同一 アプリケーションの異なるバージョン)が符号化文字集合間で異なる変換 ルールを実装する場合、それらのアプリケーションは同じ名前をそれぞれ 異なって解釈し、異なるサーバにコンタクトする可能性がある。 この問題は TLS(Transport Layer Security) [RFC5426]のようなセキュリティ プロトコルでは解決されない。これらのプロトコルはローカルな文字集合を 考慮に入れていないからである。 4.4. 視覚的に似た文字 視覚的によく似た文字同士(「紛らわしい文字(confusable)」と呼ばれることも ある)の混同を抑制する一助として、ドメイン名が複数の用字を含む場合、特に それらの用字が視覚的に混同しやすいものである場合(例えばギリシア文字の オミクロンがラテン文字のテキストと混在しているような場合)には、実装が そのことを視覚的に指摘するよう提案がなされている。 このような仕組みは、名前に中国語の簡体字と新字形(Simplified form)の 繁体字が混在している場合や、数字の0(ゼロ)と1(イチ), 英字のO(大文字オー)と l(小文字エル)が混在する場合にも使用することができる。 DNSゾーン管理者は、(一連の文書のどこか他の場所で規定した条件にしたがって) 視覚的に似た文字や意味的に同様に解釈される文字を最小限にとどめるために 何らかの制限を導入してもよい。 あるラベルが複数文字で構成されていて、そのラベルが単一の用字の文字だけ しか使用していない場合、個別に比較すると他の文字と混同しやすい文字で あっても、明確で混同しにくいものになるかもしれない。 一方で、2つ以上の用字を含むラベル(「用字が混在するラベル」と呼ばれる)の 場合には、そのような解釈行為によってリスクがより高まる。 ユーザは、表示された文字が自分が期待する文字だとして見がちであるし、 文字の前後関係はその誤った視覚的認知を強力に後押ししてしまう。 一方で、用字が混在するラベルのリスクは明確だが、ラベル内で用字を混在 させることを単に禁止したとしても、特に近い関係にある用字が関与する場合 には問題は解消しない。例えば、ラベル全てがギリシア文字またはキリル文字で 構成された文字列の多くは、それぞれお互いに、あるいはラテン文字で構成 された文字列と混同しやすい。 紛らわしい文字の問題を統合的に解決する技術的対策が存在しないことは 注記に値する。この問題の影響範囲を限定する方法は様々なものが存在するが、 この問題を解消することはおそらくできないだろう。ユニコードコンソーシアムの 出版物 [Unicode-UTR36] の中に、この紛らわしい文字の特定と処理に関する 幾つかの提案が記載されている。 Klensin Standards Track [Page 17] RFC 5890 IDNA Definitions August 2010 4.5. IDNAの検索・登録処理が基本DNS仕様に与える影響 Protocol文書 [RFC5891] は、非ASCII文字を含めた結果、基本DNS仕様 (セクション2.3.1参照)と互換性がなくなったラベルの登録と検索に関する 処理を記述している。この処理は、従来の基本DNS仕様がホスト名で許容する 文字だけで構成した特別なACE形式を使用することに依存する。使用する エンコーディングはPunycode [RFC3492] である。ACEエンコーディングを 導入することそのものに関するセキュリティ問題の有無はさておき、 エンコーディング処理によって文字列長が長くなることや、新たに許容される 値が増えること、またエンコードされた値を使用することによる セキュリティ上の問題は存在しない。 ドメイン名(またはその一部)をドメイン名の集合と比較して、その集合の要素と 一致した場合に特別な処理を行う場合が存在する。例えば他のドメイン名よりも 権限を強めるとか、ドメイン名によってアクセスを拒否するなどである。 そのような状況では特に、Protocol 文書 [RFC5891]の「要件」に関する セクションで規定した手法を使用して、比較を適切に行うことが重要である。 ラベルが既にASCII形式であれば、この適切な比較は、これまで常に行われて きたASCIIラベルの比較と同様の大文字小文字を区別しないASCII文字の比較に 限定することができる。ただしこの場合、IDNA対応アプリケーションはA-ラベル またはNR-LDHラベルだけしか検索しないことが求められる。つまりA-ラベル ではないR-LDHラベルの検索はできない。 これまでは、IDNAを導入するということは、既存のラベルでACEプレフィクスで 開始されるものは、A-ラベルとして構成されていることを意味した。少なくとも A-ラベルに関する検査に失敗するまでは、検査に失敗する(不正な)A-ラベルの 登録がゾーン管理者またはドメイン名登録者の意図によるものかどうかに 関わらず、そのA-ラベルは正当なものであるとされていた。RFC 3490導入以後に、 このような状況が原因で実際的な問題が生じたという証拠は存在しないが、 原理上リスクは今でも存在し続けている。 4.6. 旧来のIDNラベル文字列に関する問題 URI標準 [RFC3986] や多数のアプリケーション仕様(例えば SMTP [RFC5321]、 HTTP [RFC2616])は、プロトコル中でDNS名として非ASCIIラベルを許容しない。 つまり、これらのコンテキストではIDNのA-ラベル形式だけが許容される。 A-ラベルしか使用されない場合、IDNA2003と現バージョン(IDNA2008)で解釈の 違いが生じるのは、現バージョンで解釈を実際に変更した文字だけである (例えばZWJやZWNJのような文字。これらはIDNA2003では何にもマッピング されていなかったが、IDNA2008仕様では幾つかのコンテキストで適正であると される)。仕様上は禁止されているにも関わらず、ドメイン名文字列を 通常の文字で表現した膨大な数のファイルやデータベースが インターネット上に存在する。それらの文字列の一部は通常の文字で 構成したラベルを使用しており、有効なA-ラベルを生成する IDNA2003マッピングを必要とする。(訳注：次ページ先頭に続く） Klensin Standards Track [Page 18] RFC 5890 IDNA Definitions August 2010 そのようなラベルの扱いは、アプリケーションのタイプや、アプリケーション 設計者が指定する優先度に応じて多様化するだろう。IDNA2003とIDNA2008で 解釈が異なる文字が含まれる場合、ある状況ではユーザに警告したり、 そのような文字を徹底的に排除することが適当かもしれない。 他の状況では、IDNA2008に厳密に準拠した検索処理が失敗した場合に IDNA2003のマッピングを試したり、IDNA2003とIDNA2008の両方のルールを 使用して検索処理をさせるなどするほうが適当かもしれない。この一般的な 状況については Rationale文書 [RFC5894] により詳細な議論がある。 しかし、IDNA2003とIDNA2008で異なる解釈がされる可能性のある文字列を どのように処理するかに関してレジストリの配慮が不足している場合、 両プロトコルバージョンの違いが、紛らわしい文字を使用した 名前を混同させる攻撃に使用されるかもしれない。したがって、 この点に関して配慮することが適当である。 4.7. セキュリティの観点から見たIDNA2003との違い IDNA2008に関する一連の文書群で規定した登録および検索モデルは、既存の 検索アプリケーションが入力されたラベルの有効性を判定する際に利用する 仕組みを変更した。幾つかの点で検査機能は強化された。例えば、IDNA2003では 許容していた未割り当てコードポイントを含む仮適合ラベルを現在のIDNA2008は 拒否する(この理由に関する議論は Rationale 文書 [RFC5894] 参照)。 一方で、IDNA2008仕様は、ドメイン名登録時に使用されたプロトコルバージョンの 情報に関して、名前を検索するアプリケーションがそれを判定したり利用したり できるという前提を持てなくなった。理論上、アプリケーションが検索前に行える 有効性検証が減るのでリスクが増大する可能性がある。しかし現実問題として、 RFC 4690 [RFC4690]およびIDNA2008に関する一連の文書群の他の場所で説明 されている理由により、テストによって達成される保護は錯覚でしかない。 Stringprep [RFC3454] はIDNA2003で概要を規定され、また使用された。 このStringprepに対して何らかの変更を行うと、IDNA2003だけに留まらず、 より広くとらえるなら、IETFでモデル化された国際化文字列を使用する他の 異なるプロトコルについても、プロトコルの振る舞いが変化したり、既に 展開済みのアプリケーションやデータベースが無効になるなどのリスクが 発生する。しかしIDNA2008は Stringprep を何も変更しない。先に挙げた プロトコルは単にバイパスするだけでよい。IDNA2008に関する一連の文書群は Stringprepに依存しないので、Stringprepに依存する他のプロトコルを アップグレードすべきかという問いは、そのプロトコルの専門家に委ねる ことができる。つまり、IDNAがセキュリティプロトコルやセキュリティに 関する慣習を変更したりアップグレードするかは本仕様とは独立した問題 である。 Klensin Standards Track [Page 19] RFC 5890 IDNA Definitions August 2010 4.8. その他 名前や何らかの識別子を使用する仕組みだけでは、名前付けや識別子割り当ての 仕組みに依存しない幅広く多様なセキュリティ上の脅威や攻撃を防ぐことは できない。これらの攻撃にはページ偽造やDNSの問い合わせを横取りして 書き換える攻撃なども含まれる。 5. Acknowledgments The initial version of this document was created largely by extracting text from early draft versions of the Rationale document [RFC5894]. See the section of this name and the one entitled "Contributors", in it. Specific textual suggestions after the extraction process came from Vint Cerf, Lisa Dusseault, Bill McQuillan, Andrew Sullivan, and Ken Whistler. Other changes were made in response to more general comments, lists of concerns or specific errors from participants in the Working Group and other observers, including Lyman Chapin, James Mitchell, Subramanian Moonesamy, and Dan Winship. 6. References 6.1. Normative 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. [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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Klensin Standards Track [Page 20] RFC 5890 IDNA Definitions August 2010 [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). . 6.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. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, 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. [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. Klensin Standards Track [Page 21] RFC 5890 IDNA Definitions August 2010 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010. [RFC5892] Faltstrom, P., Ed., "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. [RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010. [Unicode-UTR36] The Unicode Consortium, "Unicode Technical Report #36: Unicode Security Considerations, Revision 7", July 2008, . Klensin Standards Track [Page 22] RFC 5890 IDNA Definitions August 2010 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 23]