[10] LDHラベルを拡張して非ASCII文字を利用できるようにしたものを、 国際化ラベルといいます。
国際化ラベルは、
ToASCII操作 (フラグUseSTD3ASCIIRulesは未設定) が失敗しないようなラベルです。 STD 13 の長さ制限を満たす各ASCIIラベルは国際化ラベルです。 従って国際化ラベルは従来の ASCIIラベルと新しい非ASCIIラベルの両方を含む一般化した用語です。 ほとんどの Unicode 文字が国際化ラベル中に現れることができますが、 入力文字列によってはToASCIIが失敗することがあり、そのような文字列は妥当な国際化ラベルではありません。 >>3
[13] IDN の1つのラベル、すなわちAラベル、Uラベル、NR-LDHラベルのいずれかであるラベルを国際化ラベルといいます。 下線ラベルなどは国際化ラベルではありません。 >>12
[14] IDNA2003 ではLDHラベルの条件を満たさなくてもテキスト・ラベルであれば国際化ラベルに含まれましたが、 IDNA2008 では LDHラベルと Uラベルだけが国際化ラベルです。 ToASCIIが失敗しない非ASCII 文字列の集合とUラベルである文字列の集合も異なっています。
[26] ラベルにおける文字の順序は、表示順ではなく論理順です >>25。
[16] IDNA2003 も IDNA2008 も、 ASCII による (Punycode による) 表現に変換した上でASCII大文字・小文字不区別で一致するかどうかを等価であることの定義としています。
[23] 両者とも表面的には同じ定義になっていますが、実際には IDNA2003 の ToASCII 演算と IDNA2008 のAラベルへの変換が大きく異なっているので、等価性の定義も実は大きく異なっています。
IDNA では、ラベルの等価性はそれが ASCIIラベルであるか否かに関わらず、
ToASCII演算によって ASCII 形を構築した上で定義されます。 ラベルは、ToASCIIによって生成した ASCII 形が大文字・小文字不区別の ASCII 比較により一致する場合、その場合に限って、 等価であるとします。 ASCIIラベルに対しては大文字と小文字は等価とみなすという等価性が既に存在します。 IDNA での等価性はこの従来の等価性の拡張になります。fooとFooが同じラベルの別の形であるのと同様に、 IDNA において等価なラベルは同じラベルの別の形であるものとして取り扱います。
[30] IDNA2008 の2つのラベルが等価であるとは、
... のいずれかであることをいいます >>15, >>29。
[36] UラベルとAラベルは互いに情報の損失なく変換できるので、 Uラベルとしての比較と Aラベルとしての比較は必ず同じ結果になります >>29。
[37] Aラベルは LDHラベルであり、従来の DNS の規定に基づく等価性の定義、 つまり ASCII大文字・小文字不区別の比較が適用されますが、 Uラベルにはこれが適用されず、そのまま比較することとなっています。 >>15, >>29 正規化なども行われません。
[38] UラベルもAラベルも、妥当性の検証は比較のために必須ではありません >>29。 (つまり未検証Uラベル同士や未検証Aラベル同士で比較できます。) しかし妥当性検証は諸々の理由でどのみち重要であって行うべきである >>29 とされています。
[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 が通常好ましいとされています。 >>41 4.1
[111] >>40 の要件 (AラベルとUラベルを受け付け、それ以外は受け付けてはいけないとするもの) は、 登録者が何を登録しようとしているか理解することを要求するとともに、 これら正準形の利用を促進することが目的である、とされています >>108。
[121] 与えられたのがUラベルであるかAラベルであるかに応じて、次のチェックを行います。
[64] 与えられた Unicode 文字列に対して次のチェックを行います。 ここで使う文字の順序はネットワーク順であって、 表示順であってはいけません。 >>41 4.2.3
[74] Uラベルであるためには、非ASCII文字を1文字以上含んでいなければならず、
ACE形 (Punycode で符号化して最初に xn-- をつけたもの >>41 4.4)
にした状態で63文字以下でなければなりません。 >>41 4.2.4
[75] 以上の構文的な制約に加えて、レジストリーは個々の事情に応じて必要な制約を課し、 それを満たさないラベルを拒否して構いません。 >>41 4.3
[109] IDNA2008 はレジストリーの方針を定義することもできないし定義するべきではないとしつつも、 各レジストリーは混乱を避けるなどの必要に応じて制約を設けるべきであるとしています。 特に、一般に複数の用字系の文字を含むラベルは好ましくないと考えられているとしています。 >>108
[114] LATIN SMALL LIGATURE AE と ae に関係する各種の文字のように、
2文字の列と1文字が言語によっては等価とみなされることがあります。
そのような言語を扱うレジストリーでは、 JET仕様書でいう variant
モデルを採用するか、どちらかの表現での登録を認めないなどの措置を検討するべきです。
>>108 4.3.
[119] IANA は各 TLD での方針を集めた Repository of IDN Practices を管理しています。
[78] Uラベルを Punycode で符号化し、最初に xn-- をつけて
Aラベルを得ます。 >>41 4.4
[76] Punycode の符号化の算法は失敗することがありますが、 この手順でのチェックを終えたUラベルについては、文字列の最大長についてのものを除き、 失敗することがありません。 >>41 4.4
[79] ドメイン名の lookup にあたっては、 IDNA2008 によれば次の手順で処理することとなっています。
[80] この手順は登録よりはチェックが緩くなっていますが、これは DNS に登録されている名前はチェック済みであり、 lookup はそれとの一致を確認するに過ぎないことによります。 とはいえ、ワイルドカードのような仕組みがあるため、まったくチェックをしないわけにもいきません。 >>41 5.
[81] まずは、利用者が直接入力した URL から取り出す、クリックして選択する、 ファイルに保存されている文字列から取り出すなどの形でドメイン名を入力として得ます。 >>41 5.1
[82] この文字列が元々どんな文字コードで表されていたにせよ、 Unicode に変換します。 >>41 5.2
[83] 必要に応じて、純粋な文字コードの変換だけではなく、 文字から文字への写像を適用しても構いません。 >>41 5.2
[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
[106] Punycode によって符号化し、 xn-- を最初に付けます。
>>41 5.5 これでAラベルが得られます。
[107] こうして得られたAラベルについて、適宜他のラベルと組み合わせたり FQDN 化したりした上で、 DNS で名前解決します。 >>41 5.6
[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」 という語がありますが、「国際化ラベル」の意でしょうか。