[10] LDHラベルを拡張して非ASCII文字を利用できるようにしたものを、 国際化ラベルinternationalized labelといいます。

仕様書

定義

IDNA2003 の定義

[1]

国際化こくさいかinternationalizedラベルlabelは、 ToASCII 操作 (フラグ UseSTD3ASCIIRules は未設定) が失敗しないようなラベルです。 STD 13 の長さ制限を満たす各ASCIIラベルは国際化ラベルです。 従って国際化ラベルは従来の ASCIIラベルと新しい非ASCIIラベルの両方を含む一般化した用語です。 ほとんどの Unicode 文字が国際化ラベル中に現れることができますが、 入力文字列によっては ToASCII が失敗することがあり、そのような文字列は妥当な国際化ラベルではありません。 >>3

IDNA2008 の定義

[13] IDN の1つのラベル、すなわちAラベル、Uラベル、NR-LDHラベルのいずれかであるラベルを国際化ラベルinternationalized labelといいます。 下線ラベルなどは国際化ラベルではありません。 >>12

メモ

[14] IDNA2003 ではLDHラベルの条件を満たさなくてもテキスト・ラベルであれば国際化ラベルに含まれましたが、 IDNA2008 では LDHラベルと Uラベルだけが国際化ラベルです。 ToASCIIが失敗しない非ASCII 文字列の集合とUラベルである文字列の集合も異なっています。

文字の順序

[26] ラベルにおける文字の順序は、表示順ではなく論理順です >>25。

[115] ラベルを含んだドメイン名全体については、ドメイン名の項を参照してください。

比較

[16] IDNA2003 も IDNA2008 も、 ASCII による (Punycode による) 表現に変換した上でASCII大文字・小文字不区別で一致するかどうかを等価であることの定義としています。

[23] 両者とも表面的には同じ定義になっていますが、実際には IDNA2003 の ToASCII 演算と IDNA2008 のAラベルへの変換が大きく異なっているので、等価性の定義も実は大きく異なっています。

IDNA2003 における等価性の定義

[2] >>3

IDNA では、ラベルの等価性はそれが ASCIIラベルであるか否かに関わらず、 ToASCII 演算によって ASCII 形を構築した上で定義されます。 ラベルは、 ToASCII によって生成した ASCII 形が大文字・小文字不区別の ASCII 比較により一致する場合、その場合に限って、 等価とうかequivalentであるとします。 ASCIIラベルに対しては大文字と小文字は等価とみなすという等価性が既に存在します。 IDNA での等価性はこの従来の等価性の拡張になります。 foo と Foo が同じラベルの別の形であるのと同様に、 IDNA において等価なラベルは同じラベルの別の形であるものとして取り扱います。

IDNA2008 における等価性の定義

[30] IDNA2008 の2つのラベルが等価equivalentであるとは、

... のいずれかであることをいいます >>15, >>29。

[36] UラベルとAラベルは互いに情報の損失なく変換できるので、 Uラベルとしての比較と Aラベルとしての比較は必ず同じ結果になります >>29。

[37] Aラベルは LDHラベルであり、従来の DNS の規定に基づく等価性の定義、 つまり ASCII大文字・小文字不区別の比較が適用されますが、 Uラベルにはこれが適用されず、そのまま比較することとなっています。 >>15, >>29 正規化なども行われません。

[39] NR-LDHラベルは従来通りの DNS の ASCII大文字・小文字不区別の一致により等しいかが決まります。

[38] UラベルもAラベルも、妥当性の検証は比較のために必須ではありません >>29。 (つまり未検証Uラベル同士や未検証Aラベル同士で比較できます。) しかし妥当性検証は諸々の理由でどのみち重要であって行うべきである >>29 とされています。

DNS 鯖における取り扱い (IDNA2003)

[8] ゾーンに蓄積されるドメイン名は、 Stringprep における蓄積文字列の規則に従います。 >>7

[9] DNS鯖は、 ASCII で表現できない国際化ラベルは、 ToASCII 演算を適用し、 ACE 形を使って表現しなければなりません。 >>7

国際化ドメイン名登録プロトコル

[46] 非ASCII文字を含む国際化ラベルの登録にあたっては、 IDNA2008 によれば次の手順に従うこととされています。

登録の受付

[40] レジストラを経てレジストリーに至る登録手続きについては IDNA では適用範囲外とされており、レジストリー (ゾーン管理者) による登録のみが規定されています。登録手続きの段階で個別の事情に応じて変換などが行われるかもしれませんが、 IDNA 仕様による制約の及ばない範囲とされています。レジストリー (ゾーン・ファイルに責任をもつ者) は、 (そうした手続きの後の) 実際に登録を行うべき文字列そのものだけを受け付けなければなりません。 登録する文字列は Unicode で、 NFC でなければなりません。 >>41 4.1

[42] レジストリーは、次の3つのいずれの形式の入力であっても受け付けて構いませんが、 Aラベルによって曖昧性を回避できるため、 >>43 と >>44 が推奨されています。 更に、検証が可能という点において >>44 より >>43 が通常好ましいpreferredとされています。 >>41 4.1

[111] >>40 の要件 (AラベルとUラベルを受け付け、それ以外は受け付けてはいけないとするもの) は、 登録者registrantが何を登録しようとしているか理解することを要求するとともに、 これら正準形の利用を促進することが目的である、とされています >>108。

[112] UラベルやAラベルでないものを受け付けるということは、例えば NFC になっていない文字が含まれるラベルの登録を受け付けるということになりますが、 これは望ましくなく、実際に技術的に利用可能である正規化済みのラベルを登録者が理解した上で登録手続きがなされるべき、ということでしょう。[113] もっとも、これが特定の符号列によって登録者とレジストリーがやりとりを行うことを強制するものではないとされています >>108。 極端な話、紙で申請されていても、それがプロトコル上の意味での登録が始まる時点までにUラベルやAラベルに曖昧無く変換されているのであれば、この要件の趣旨は達成できているということでしょうね。

入力のチェック

[121] 与えられたのがUラベルであるかAラベルであるかに応じて、次のチェックを行います。

UラベルとAラベルが与えられた場合のチェック

[47] UラベルとAラベルの両方が与えられた場合、

  • [52] Aラベルについて、
    1. [48] 小文字化し、
    2. [49] AラベルをUラベルに変換し、
    3. [50] Uラベルに対する手順を実行し、
    4. [51] Aラベルに変換 (RFC 5891 4.4) し、
    5. [53] 元のAラベルと一致するか確認しなければなりません。 >>41 4.2
  • [54] Uラベルについて、
    1. [55] >>49 と一致するか確認しなければなりません。 >>41 4.2
  • [56] >>52、>>54 で一致しない場合は登録を拒絶しなければなりません。 >>41 4.2

Aラベルだけが与えられた場合のチェック

[57] Aラベルだけが与えられた場合で Uラベルへの変換を行わない場合、

  • [58] Aラベルが表面的に妥当であるか (Punycode 違反、例えば末尾が - でないか、すべてがASCII文字であるか、など) を確認しなければなりません。 >>41 4.2
  • [59] Aラベルに見える文字列 (xn-- で始まるなど) であったり、 Aラベルを与えるべきところで与えられた文字列であったりするものが >>58 でいうところの妥当な Aラベルでなければ、これを IDNA に対応した DNSゾーンに配置してはなりません。 >>41 4.2
  • [60] 登録手続きにおいては、以後のチェックを飛ばして構いませんし、通常はそうします。 >>41 4.2

[120] UラベルはきちんとチェックさせておきながらAラベルでこうやって抜け道を残す意図はなんでしょうかね。

Uラベルだけが与えられた場合のチェック

[61] Uラベルだけが与えられた場合に特に行うチェックは規定されていません。

文字のチェック

[64] 与えられた Unicode 文字列に対して次のチェックを行います。 ここで使う文字の順序はネットワーク順であって、 表示順であってはいけませんmay not。 >>41 4.2.3

[66] Aラベルだけが与えられた場合は通常このチェックを飛ばします (>>60)。

ラベルの長さチェック

[74] Uラベルであるためには、非ASCII文字を1文字以上含んでいなければならず、 ACE形 (Punycode で符号化して最初に xn-- をつけたもの >>41 4.4) にした状態で63文字以下でなければなりません。 >>41 4.2.4

レジストリーでの制約

[75] 以上の構文的な制約に加えて、レジストリーは個々の事情に応じて必要な制約を課し、 それを満たさないラベルを拒否して構いません。 >>41 4.3

[109] IDNA2008 はレジストリーの方針を定義することもできないし定義するべきではないとしつつも、 各レジストリーは混乱を避けるなどの必要に応じて制約を設けるべきであるとしています。 特に、一般に複数の用字系の文字を含むラベルは好ましくないと考えられているとしています。 >>108

[110] そのようなレジストリーの制約で用いられる技法の具体例として、 JET仕様書 (RFC 3743、RFC 4290) や中国語における RFC 4713 が挙げられています >>108。

[114] LATIN SMALL LIGATURE AE と ae に関係する各種の文字のように、 2文字の列と1文字が言語によっては等価とみなされることがあります。 そのような言語を扱うレジストリーでは、 JET仕様書でいう variant モデルを採用するか、どちらかの表現での登録を認めないなどの措置を検討するべきです。 >>108 4.3.

[119] IANA は各 TLD での方針を集めた Repository of IDN Practices を管理しています。

Punycode で符号化

[78] Uラベルを Punycode で符号化し、最初に xn-- をつけて Aラベルを得ます。 >>41 4.4

[76] Punycode の符号化の算法は失敗することがありますが、 この手順でのチェックを終えたUラベルについては、文字列の最大長についてのものを除き、 失敗することがありません。 >>41 4.4

登録

[77] こうしてラベルがチェックを通過したなら、 DNS にはAラベルを登録します。 >>41 4.5

ドメイン名 lookup プロトコル

[79] ドメイン名の lookup にあたっては、 IDNA2008 によれば次の手順で処理することとなっています。

[80] この手順は登録よりはチェックが緩くなっていますが、これは DNS に登録されている名前はチェック済みであり、 lookup はそれとの一致を確認するに過ぎないことによります。 とはいえ、ワイルドカードのような仕組みがあるため、まったくチェックをしないわけにもいきません。 >>41 5.

ラベルの入力

[81] まずは、利用者が直接入力した URL から取り出す、クリックして選択する、 ファイルに保存されている文字列から取り出すなどの形でドメイン名を入力として得ます。 >>41 5.1

[82] この文字列が元々どんな文字コードで表されていたにせよ、 Unicode に変換します。 >>41 5.2

[83] 必要に応じて、純粋な文字コードの変換だけではなく、 文字から文字への写像を適用しても構いません。 >>41 5.2

[84] 最終的に入力となる文字列は NFC としなければなりません。 >>41 5.2

Aラベルの場合

[85] さて、入力に未検証Aラベルがある場合、 全体を小文字に変換し、チェックを行った上でUラベルに変換して構いません。 ここで Punycode の復号の算法によって Uラベルに変換される場合には、 指定された手順に従わなければならず、その結果得られたラベルが元のAラベルと同じにならなければ拒絶しなければなりません。 >>41 5.3

[86] この変換は、ドメイン名を後でUラベル式に表示するのであれば、行うべきです。 >>41 5.3

[87] 変換を行わない場合であっても、与えられた文字列が実際に Aラベルであるか、 Punycode の復号の仕様上非妥当な書式でないかを最低でもチェックするべきです。 >>41 5.3

[88] IDNA 未対応のアプリケーションがもちろんこのチェックを行う必要はありませんが、 対応しているアプリケーションであっても、与えられた文字列を不透明なものとして扱い、 チェックを省略しても構いません。 もちろんその場合は利用者に対して行える保護や提供できる情報は少なくなります。 >>41 5.3

文字とラベルのチェック

[89] 未検証Uラベルが次の条件のいずれかに合致する場合には、 DNS の lookup を行わずに拒絶しなければなりません。 >>41 5.4

[102] 更に、次の検査を行うべきです。 >>41 5.4

[104] この検査は、他のところでチェックがなされているとわかっている場合など、 特別な状況にあっては省略して構いません。というのも、チェックを通らない文字列を lookup しても、ワイルドカードが使われている場合を除き、単に DNS lookup が失敗するだけであろうからです。ただ、単に名前解決に失敗したと報告するよりは、 事前にチェックしてそのことを利用者に伝えられる方が有用かもしれません。 >>41 5.4

[105] この検査を通過した文字列については、 lookup アプリケーションはそのラベルが妥当であるか否かは DNS でラベルが存在するか否かによって判断しなければなりません。 登録されていれば妥当であり、登録されていなければ妥当性は意味を持ちません。 lookup アプリケーションが独自に検査して警告を出すなどしても構いませんが、 それを根拠に DNS に問い合わせないなど通常の処理を行わないとしたら、それはこのプロトコルに適合しません。 >>41 5.4

Punycode 変換

[106] Punycode によって符号化し、 xn-- を最初に付けます。 >>41 5.5 これでAラベルが得られます。

DNS による名前解決

[107] こうして得られたAラベルについて、適宜他のラベルと組み合わせたり FQDN 化したりした上で、 DNS で名前解決します。 >>41 5.6

Punycode 以外のラベル

[122] 現在 IDNラベルとして正式に利用できる ASCIIラベルは Punycode を用いた XNラベルだけですが、 IDNA2003 が採用される前は RACE や UTF-5 が使われていました。

[123] また、イントラネットなどでは ACE を使わずに直接 UTF-8 や ISO-8859-1 などが DNS 上で利用されることがあります。これは IDNA が標準化された後も引き続き行われています。

[124] インターネット向けにも2000年頃から直接 UTF-8 を使う方法で名前の登録サービスを提供する業者が出現しましたが、 RACE や Punycode による ccTLD や gTLD での IDN が提供されるになるにつれ、衰退してゆきました。

関連

[4] 国際化ラベルに対し、ASCII文字のみのラベルをASCIIラベルといいます。 ASCIIラベルは国際化ラベルの部分集合です。

[5] 国際化ラベルの Punycode 化表現は ACEラベル (IDNA2003) や Aラベル (IDNA2008) といいます。IDNA2003 はこの国際化ラベルから ASCIIラベルへの変換を「ToASCII 演算」として規定しています。

[24] http://tools.ietf.org/html/rfc5890#section-2.3.3 には「IDN labels」 という語がありますが、「国際化ラベル」の意でしょうか。