equivalent

国際化ラベル (ドメイン名)

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

目次

  1. 仕様書
  2. 定義
    1. IDNA2003 の定義
    2. IDNA2008 の定義
    3. メモ
  3. 文字の順序
  4. 比較
    1. IDNA2003 における等価性の定義
    2. IDNA2008 における等価性の定義
  5. DNS 鯖における取り扱い (IDNA2003)
  6. 国際化ドメイン名登録プロトコル
    1. 登録の受付
    2. 入力のチェック
      1. UラベルとAラベルが与えられた場合のチェック
      2. Aラベルだけが与えられた場合のチェック
      3. Uラベルだけが与えられた場合のチェック
    3. 文字のチェック
    4. ラベルの長さチェック
    5. レジストリーでの制約
    6. Punycode で符号化
    7. 登録
  7. ドメイン名 lookup プロトコル
    1. ラベルの入力
    2. Aラベルの場合
    3. 文字とラベルのチェック
    4. Punycode 変換
    5. DNS による名前解決
  8. Punycode 以外のラベル
  9. 関連

仕様書#

定義#

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] IDNA2003IDNA2008 も、 ASCII による (Punycode による) 表現に変換した上でASCII大文字・小文字不区別一致するかどうかを等価であることの定義としています。

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

IDNA2003 における等価性の定義#

[2] >>3

IDNA では、ラベル等価性はそれが ASCIIラベルであるか否かに関わらず、 ToASCII 演算によって ASCII 形を構築した上で定義されます。 ラベルは、 ToASCII によって生成した ASCII 形が大文字・小文字不区別ASCII 比較により一致する場合、その場合に限って、 等価 (とうか) (equivalent) であるとします。 ASCIIラベルに対しては大文字小文字等価とみなすという等価性が既に存在します。 IDNA での等価性はこの従来の等価性の拡張になります。 fooFoo が同じラベルの別の形であるのと同様に、 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ラベルは従来通りの DNSASCII大文字・小文字不区別の一致により等しいかが決まります。

[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ラベルの両方が与えられた場合、

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

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

[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 3743RFC 4290) や中国語における RFC 4713 が挙げられています >>108

[114] LATIN SMALL LIGATURE AEae に関係する各種の文字のように、 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ラベルが次の条件のいずれかに合致する場合には、 DNSlookup を行わずに拒絶しなければなりません>>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 が採用される前は RACEUTF-5 が使われていました。

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

[124] インターネット向けにも2000年頃から直接 UTF-8 を使う方法で名前の登録サービスを提供する業者が出現しましたが、 RACEPunycode による ccTLDgTLD での 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」 という語がありますが、「国際化ラベル」の意でしょうか。