[12] IDNA2008 は、 IDNA の頃の改訂版です。

[13] 「頃」というのは、 この種の仕様の例に漏れず、 仕様策定に時間がかかって中に完成していないからです。

[14] IDNA2008 は IDNA2003 を改訂して置き換えるものですが、 非互換な変更を含んでいるため、 IDNA2003 も引き続き実装されて残っていました。

仕様書

Unicode の版

[58] IDNA2008 の RFC は Unicode 5.2 を引用していますが、 特に版Unicodeの版を限定はしておらず、 Unicode が更新されても使えることになっています。

[60] IDNA2008 の実装は Unicodeの特性文字特性などを利用して処理を行うこととなりますが、 この情報については Unicodeの版はいずれか特定の版Unicodeの版でなくてはならず、 部分的に新しい版Unicodeの版になっているなどの齟齬が生じていてはいけません。 >>10 7.1.2, 7.1.3

[59] 登録に当たっては、 レジストリーは新しい版Unicodeの版で追加された文字を扱う必要がない限り、 Unicodeの版を更新する必要はありません。 >>10 7.1.2

Unicode 6.0.0

[100] 付けで (実際にはに) Unicode 6.0.0 版の情報が登録されています。 それについての RFC 6452 (>>102) も発行されています。

[103] Unicode への文字の追加による UNASSIGNED から他の導出特性値への変更の他に、 3つの文字が GeneralCategory の変更に伴って導出特性値が非互換に変更されています >>102。

  • U+0CF1 KANNADA SIGN JIHVAMULIYA DISALLOWED -> PVALID
  • U+0CF2 KANNADA SIGN UPADHMANIYA DISALLOWED -> PVALID
  • U+19DA NEW TAI LUE THAM DIGIT ONE PVALID -> DISALLOWED

Unicode 7.0.0

[120] IETF は Unicode 7.0 で問題が生じた >>113、>>114 として、 Unicode 6.3.0 版を最後にIANA登録簿の更新を中断しています。

その間に既に Unicode 8.0 も出版されているわけですが...[122] Unicode の版に依存しない形で定義したはずなのに 5年くらいで破綻したのは、短いというべきか、十分もったというべきなのか...

[121] 本来実装は IANA登録簿の表ではなく Unicode の特性に基づかなければならないはずなので、 IETF が恣意的にIANA登録簿の更新手続きを停止し続けると正確な実装 (があるとして...) と IANA登録簿が乖離していって好ましくない気がしますが...

[127] IANA登録簿の Unicode 6.3.0 版の導出特性値の表と、 RFC 5892 の規定に基づき計算した表の比較:
  • [123] Compare character sets "$idna-tables-6.3.0:PVALID" and "$rfc5892:PVALID" ( 版) https://chars.suikawiki.org/set/compare?expr1=%24idna-tables-6.3.0%3APVALID&expr2=%24rfc5892%3APVALID
  • [124] Compare character sets "$idna-tables-6.3.0:CONTEXT" and "$rfc5892:CONTEXT" ( 版) https://chars.suikawiki.org/set/compare?expr1=%24idna-tables-6.3.0%3ACONTEXT&expr2=%24rfc5892%3ACONTEXT
  • [125] Compare character sets "$idna-tables-6.3.0:DISALLOWED" and "$rfc5892:DISALLOWED" ( 版) https://chars.suikawiki.org/set/compare?expr1=%24idna-tables-6.3.0%3ADISALLOWED&expr2=%24rfc5892%3ADISALLOWED
  • [126] Compare character sets "$idna-tables-6.3.0:UNASSIGNED" and "$rfc5892:UNASSIGNED" ( 版) https://chars.suikawiki.org/set/compare?expr1=%24idna-tables-6.3.0%3AUNASSIGNED&expr2=%24rfc5892%3AUNASSIGNED

処理

[61] 国際化ラベルの項を参照してください。

IDNA2003 からの主要な変更点

[94] IDNA2008 は IDNA2003 から大きく変更されています。ほとんど別物です。

[36] RFC 5891 - Internationalized Domain Names in Applications (IDNA): Protocol http://tools.ietf.org/html/rfc5891#appendix-A

用語の整理

[19] 伝統的にドメイン名関係の用語はバリエーションが多く定義が曖昧で混乱しており、 IDN 関連用語も例外ではありません。 IDNA2008 では IDN 関連用語が整理され、 IDNA2003 よりも体系的に説明されてわかりやすくなりました。 とはいえ、依然として不明瞭な部分や曖昧な用法も残っています (例えば未検証Aラベル)。

[49] 詳しくはラベルの項を参照してください。

[46] また、それまで妥当とされながらも実際には IDNAラベルでないものを非妥当とした >>36 とあります。これが何を指すのか明確には記述されていませんが、用語の定義の明確化と同時に R-LDHラベルであってAラベルでないものの利用が禁止されたことを指しているのでしょう。

登録プロトコルと lookup プロトコルの分離

[37] ドメイン名の登録と lookup の手順が別々に定義されるようになりました >>36。 IDNA2003 でも AllowUnassigned のようなフラグがあったとはいえ、基本的には登録も lookup も共通の手続きとして規定されていました。これが IDNA2008 では完全に別々の手続きとして定義されています。

Unicode の版の非依存化

[35] IDNA2003 は Unicode 3.2 という特定の版に依存していましたが、 IDNA2008 は特定の版には依存しなくなったとされています >>36, >>10 1.1, >>10 7.1。

[50] Unicode 3.2 に束縛された Stringprep/Nameprep を廃し、 Unicode の特性から機械的に導かれる導出特性値による定義に切り替えられました。 このため、 Unicode の新しい版になってもほぼ自動的に対応できることになっています。

[51] ただし、導出特性値の変更については指定専門家が評価した上でIETF評価プロセスを経る必要があるとされており、 通常の IETF の完全な標準化過程よりは (おそらく) 高速に進められるのでしょうが、 (公式には) ただちに最新版に追随できるわけではなさそうです。

使用できる文字の決定方法の変更

[40] ラベルでの使用を認める文字の決め方が「予めすべて手動で決める」から 「Unicode の特性に従い決める、ただし例外を除く」に変わりました >>36。

[53] IDNA2003 では Unicode 3.2 のうち使用してはいけない文字のリストを決める形で使用可能な文字が定義されており、 これは「exclusion model」と呼ばれています。一方で IDNA2008 では使用してよい文字のリストを決める形になっていて、 「inclusion model」 >>10 3. と呼ばれています。

実際には使用しても良い文字を決めるというよりは、すべての文字について使用しても良いか悪いかを決める形になっています。

[54] その決め方も、 IDNA2003 では IETF で文字のリストを決めていましたが、 IDNA2008 では文字のリストの導出方法を決めています。これにより Unicode の新しい版に機械的に追随できるようになっています。詳しくは導出特性値の項をご覧ください。

[55] ただし新しい版と古い版の互換性のための調整を行うことが認められているために、 完全に機械的に新しい版に移行できるわけではありません。 BackwardCompatible を参照してください。 この作業には IETF評価が必要ですが、完全に仕様全体を改訂するよりは楽です。 十分な運用実績が蓄積された後にはその過程も簡易化されることが示唆されています >>10 7.1。

[41] IDNA2003 では原則的にラベルで使える文字はラベルのどこでも使えましたが、 IDNA2008 では文脈依存で認められる文字が登場しました >>36。 CONTEXT に分類される文字について、文脈的規則を満たす場所でのみ認められます。

正規化と大文字・小文字の区別のプロトコルからの分離

[39] 文字の写像と正規化をプロトコルからは削除し、 アプリケーションが必要に応じて事前に行うこととされました >>36。

[67] IDNA2003 では Nameprep の一部として正規化 (NFKC) を行っていましたが、 IDNA2008 では入力が NFC であることを要請するに留まっています。

[52] IDNA2003 では大文字・小文字の不区別がプロトコルに含まれていて、 小文字に正規化する方法が正確に規定されていました。しかし IDNA2008 では、大文字と小文字の対応は言語により異なることを理由に、 プロトコルの一部ではなく、アプリケーション側で事前に行っておくべき作業としています >>10 1.1。 その具体的な対応関係は規定から外されています。

[73] これによってUラベルとAラベルが完全に一意に変換可能となることが重要だと考えられているようです >>10 7.2.3。 IDNA2003 では正規化が行われるために、同じACEラベルに変換されるような国際化ラベルが多数存在しました。

[84] IDNA2003 では正規化すればACEラベルに対応付けられていた国際化ラベルであっても IDNA2008 ではそうでないものが多数存在することになりますが、プロトコル的文脈では UラベルとAラベルだけを認める (正規化が必要であったバリエーションは認めない) ことが非常に好ましいstrongly preferとされています >>10 7.3。

[85] そうは言っても、これまで正常に利用できていた URL やメール・アドレスがある日突然使えなくなるのは困りますよね・・・。 結局のところこれが IDNA2008 の普及を阻害するのではないでしょうか。 IDNA2008 に移行するとしても、それぞれのアプリケーションで後方互換性のための変換が (プロトコル的文脈の中に) 組み込まれ続けることとなり、しかしそれは標準化されておらず、 相互運用性の問題を残すだけの結果になりそうでおそろしい。

新たに利用できるようになった文字

[62] これらの変更により IDNA2003 では正規化の結果直接利用できなかった文字が IDNA2008 では利用できることがあります。具体的には、

  • [64] U+00DF LATIN SMALL LETTER SHARP S
  • [63] U+03C2 GREEK SMALL LETTER FINAL SIGMA

... が使えるようになりました。 >>10 7.2.1

[65] 大文字・小文字に関する非互換変更はこの2文字だけのようです。

[66] これらの文字に関しては、 IDNA2003 と IDNA2008 でどちらも正しいドメイン名として lookup でき、しかし異なる結果が得られる可能性があります。 レジストリーはそれによって混乱が生じないような方策を練るべきです >>10 7.2.3。

[74] アプリケーション側で出来る対応もあるのでしょうが、多種多様な状況で一律に対策することが難しく、 レジストリーで対策するべき >>10 7.2.3 とされています。

[72] 正書法的には利用できるべきであるものの、 IDNA2003 と Aラベル (ACEラベル) レベルでの互換性が失われてしまうのですが、それがACE接頭辞の変更を伴わずに済むなら、 ということで非互換変更を認めてでもこれらの文字を利用できるようにするべきと判断されました >>10 7.2.3。

Join_controls の扱いの変更

[68] ZERO WIDTH JOINER と ZERO WIDTH NON-JOINER は IDNA2003 では除去されることになっていましたが、 IDNA2008 では文脈によってはラベルを構成する文字として認められるようになりました。 >>10 7.2.2

[69] これは特定の用字系においては mnemonics を構成し得る必要な文字であることが理由とされています。 >>10 7.2.2

[70] これらの文字に関しては、 IDNA2003 と IDNA2008 でどちらも正しいドメイン名として lookup でき、しかし異なる結果が得られる可能性があります。

記号類の排除

[38] 原則として記号と句読点を認めないようになりました >>36。 これまでも IESG や ICANN の指針で言語の表記に必要な狭義の文字以外認めないとされていましたが、 技術的に利用が制限されました。 >>10 7.6

[86] その理由としては、ASCII のドメイン名でも記号類は認めていなかったのと整合的であること、 記号のレンダリングには実装による差異が大きかったり、似たグリフの異なる文字が多数存在したりすること、 記号類の読み方や通常の文字表記と記号による表記の使い分けが一定ではないために音声による伝達に障害が多いことなどが挙げられています >>10 7.6。

bidi 制約の変更

[42] IDNA2003 の bidi に関する制約によれば、ラベルの末尾に結合文字を使うことができず >>10 4.5.、これが原因で Dhivehi や Yiddish の一般的な単語の表記 >>36 に支障が生じていていましたが、規制の緩和によりこれが認められるようになりました。

[44] また、 bidi なドメイン名が異常な感じで表示されにくくなった >>36 とされています。

ラベル分離子の廃止

[45] ラベル分離子という概念がプロトコルから削除されました >>36。 IDNA2003 では . などの「点」によってドメイン名を分割してラベルを取り出して処理することになっていましたが、 その部分は利用者インターフェイスの範疇であるとして削除されました。

fallback

[20] IDNA2003 と IDNA2008 の間の非互換変更により、 IDNA2003 における解釈を期待していたドメイン名が IDNA2008 では解釈できなくなる場合があります。その場合、 lookup は失敗としても構いませんし、 失敗したら IDNA2003 で lookup し直しても構いませんし、最初から IDNA2003 と IDNA2008 の両方で lookup しても構いません。ただし、 解釈の違いを突いた攻撃ができるかもしれないので注意が必要です。

  • [99] RFC 5890 - Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework http://tools.ietf.org/html/rfc5890#section-4.6
[21] IDNA2003 使っても良いとか本当にそんな姿勢でいいのか・・・?

レジストリーにおける移行戦略

[75] >>62、>>68 では IDNA2003 では他の文字列に正規化されてしまい厳密には表現できなかったラベルが IDNA2008 で表現できることになり、 IDNA2003 と IDNA2008 のどちらで lookup するかによって結果が変わってしまい混乱や保安上の問題の元となります。 そのため、レジストリーは何らかの移行戦略を練ることが要求されています >>10 7.2.4。

[76] その具体例として、これまでの類似した状況を参考に、次のような対応策が挙げられています >>10 7.2.4。

[83] ノーガード戦法www

UTS #46

[97] Unicode Consortium は UTS #46 により IDNA2003 と IDNA2008 の中間のどちらとも実用上互換性がある算法「Unicode IDNA互換性処理」を規定しています。 IDNA2003 と IDNA2008 の差異についてはそちらの項も参照してください。

[98] UTS #46 や Unicode Consortium の IDN FAQ は RFC よりかなり詳しく差異が説明されています。ネ申ですねwww

ドメイン名の前処理

[87] IDNA2003 は正規化や大文字から小文字への変換などを含めて規定していましたが、 IDNA2008 はそれは利用者インターフェイスの範疇であった >>11 としてプロトコルから除外しています。これらの処理は利用者が使っている言語などの文脈によって何が適切かが変化するものであり、 画一的にプロトコルのレベルで行うべきではないと考えられています。

[88] IDNA2008 は利用者が与えたドメイン名をどう処理するかの例として次の手順を示していますが、 同時にこれは特定の場面でのみ意味のある例を示したに過ぎず、アプリケーションの実装者が十分に検討するべきであるともしています >>11。

[89] つまり丸投げですね。
  1. [90] 大文字を小文字に変換します。
  2. [91] 全角や半角を正規化します。
  3. [92] NFC にします。
  4. [93] FULL STOP や IDEOGRAPHIC FULL STOP でドメイン名をラベルの列に分割します。

[43] はじめからそのように設計されていたのなら、 アプリケーション依存の利用者インターフェイスの範疇ということで何の問題もなかったのですが、現実にはそうではありません。 IDNA2003 はこれらの処理を含めて規定したのですし、 IDN 以前の元々のドメイン名が大文字・小文字不区別だったのに、 突然その規定が無くなってアプリケーションに丸投げでは、 互換性も相互運用性もあったものではありません。

[134] しかも、ここでいう「アプリケーション」 がアプリケーションプロトコルのことなのかアプリケーションプログラムのことなのかも定かではありません (どちらも含まれているのかもしれませんが)。

[135] 例えば URL では正規化の一部として IDNA2003 の処理が行われているので、 IDNA2008 に移行すると重要な規定が欠落した状態になるため、 どう対処するべきか仕様によっても対応が定まらず長年混乱しています。

[133] 厳密に言えば、この煮え切らない規則が書かれている RFC 5895 >>11 は IETF の標準化過程にある IDNA2008 シリーズの RFC ではなく、 個人提出の Informative な RFC という位置付けになっています >>130。

[136] もちろん同時に RFC 化されたもので全く無関係に開発されたということではありませんが、 IETF の名前の元で発行することすら認められないという辺りに、政治的な闇政治的理由を感じます。

[129] IDNA2008 発行後に Unicode Consortium から発行された UTS #46 は、 同仕様に基づく前処理の方法を規定しています (IDNA2008前処理)。

[137] UTS #46 の著者らも、 IDNA2008 の開発に無関係だったわけではありませんが、 IETF とは別に Unicode Consortium から発行することを選んだ (選ばざるを得なかった) というのもまた闇政治的理由です。

[132] IDNA2008 のこの非互換な変更で、実質的に単体で実装不可能になったため、 多くの実装が IDNA2008 ではなく UTS #46 を採用しています。

[138] Web におけるドメイン名の処理でも、URL Standard で規定されるように UTS #46 が使われています。

PRECIS

[116] IDNA2003 から IDNA2008 への改訂で Stringprep から独自方式へと移行しましたが、 IDN (Nameprep) 以外の Stringprep 応用も多かれ少なかれ問題を抱えていたので、 改訂が必要でした。

[117] IETF は PRECIS と称する仕様を新たに開発し、 Stringprep にかえて各プロトコルで採用することにしました。 PRECIS は2015年に RFC として出版されました。

PRECIS 参照。

[118] PRECIS は IDNA2008 を元に各処理段階を選択可能にしたような形となっています。 大文字・小文字の処理その他の正規化の標準化を IDNA2008 は半ば放棄して実装依存としていますが、 PRECIS はプロファイルが規定する形としています。

[128] IDNA2008 は lookup と登録の方法と比較の手続きを規定していますが、 PRECIS は一般化して準備、執行、比較の3つの演算に整理しています。

[119] RFC 7622 (JID) は、 domainpart における準備、執行、比較の処理を IDNA2008 をベースに規定しています。

[140] IDNA2003 / Stringprep 世代のようにドメイン名以外も対象にすると議論が発散して標準化が進展しなくなるので IDNA2008 を独立させたということなのでしょうが、似て非なるものをいくつも作り出すという悪い結果になりました。

歴史

[1] UTS #46: Unicode IDNA Compatible Preprocessing ( 版) http://www.unicode.org/reports/tr46/tr46-1.html

[2] Unicode IDNA Compatible Preprocesssing ( 版) http://www.unicode.org/reports/tr46/tr46-2.html

[3] draft-ietf-idnabis-mappings-04 - Mapping Characters in IDNA ( 版) http://tools.ietf.org/html/draft-ietf-idnabis-mappings

[4] しかしなんで連中はこう、非互換変更が好きなのかねぇ。

[5] Security Degradations with IDNA2008 (Macchiato) ( 版) http://www.macchiato.com/unicode/idna/security-issues

各種仕様書・実装の対応

[16] Web Applications 1.0 は現在でも IDNA2003 を採用しています。

[106] 起源の定義は >>16 と RFC の2つがあり、それぞれ IDNA2003 と IDNA2008 を採用していて微妙に異なっています。 (起源参照。)

[95] XMPP は JID で Nodeprep や Resourceprep も使用しているため、 IDN だけ新版に移行するわけにもいかず、将来の改訂で IDNA2008 に移行すると予告しつつも IDNA2003 を採用しています。

[105] Widgets も IDNA2003 を採用しています >>104。

メモ

[17] IDNA2008 は IDNA2003 からいくつかの文字の解釈を変更しているので、 ゾーン管理者は注意するべきshouldです。

[22] IDNA2008 の RFC はすごく読みにくい。

[107] IRC logs: freenode / #whatwg / 20120928 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20120928#l-801

[108] IRC logs: freenode / #whatwg / 20121005 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20121005#l-351

[109] Updating RFC 5890-5893 (IDNA 2008) to Full Standard ( ( 版)) http://www.alvestrand.no/pipermail/idna-update/2012-November/007465.html

[110] IRC logs: freenode / #whatwg / 20121116 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20121116#l-141

[111] Updating RFC 5890-5893 (IDNA 2008) to Full Standard ( ( 版)) http://www.alvestrand.no/pipermail/idna-update/2012-November/007467.html

[112] IRC logs: freenode / #whatwg / 20121116 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20121116#l-835

[113] draft-klensin-idna-5892upd-unicode70-04 - IDNA Update for Unicode 7.0.0 ( 版) https://tools.ietf.org/html/draft-klensin-idna-5892upd-unicode70-04

[114] IAB Statement on Identifiers and Unicode 7.0.0 | Internet Architecture Board ( 版) https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-statement-on-identifiers-and-unicode-7-0-0/

[115] RFC 7622 - Extensible Messaging and Presence Protocol (XMPP): Address Format ( 版) https://tools.ietf.org/html/rfc7622

[130] RFC 8170 - Planning for Protocol Adoption and Subsequent Transitions () https://tools.ietf.org/html/rfc8170#appendix-A.2

[131] >>130 は IAB の RFC ですが、 IDNA2008 への移行がうまくいかなかったことに言及があります。 (さすがに失敗だったとまではっきり書いてはいません。)

[139] draft-faltstrom-unicode11-00 - IDNA2008 and Unicode 11.0.0 () https://tools.ietf.org/html/draft-faltstrom-unicode11-00