[12] IDNA2008 は、 IDNA の頃の改訂版です。
[14] IDNA2008 は IDNA2003 を改訂して置き換えるものですが、 非互換な変更を含んでいるため、 IDNA2003 も引き続き実装されて残っていました。
[58] IDNA2008 の RFC は Unicode 5.2 を引用していますが、 特に版を限定はしておらず、 Unicode が更新されても使えることになっています。
[60] IDNA2008 の実装は Unicodeの特性などを利用して処理を行うこととなりますが、 この情報については Unicodeの版はいずれか特定の版でなくてはならず、 部分的に新しい版になっているなどの齟齬が生じていてはいけません。 >>10 7.1.2, 7.1.3
[59] 登録に当たっては、 レジストリーは新しい版で追加された文字を扱う必要がない限り、 Unicodeの版を更新する必要はありません。 >>10 7.1.2
[100] 付けで (実際にはに) Unicode 6.0.0 版の情報が登録されています。 それについての RFC 6452 (>>102) も発行されています。
[103] Unicode への文字の追加による UNASSIGNED から他の導出特性値への変更の他に、
3つの文字が GeneralCategory の変更に伴って導出特性値が非互換に変更されています >>102。
[120] IETF は Unicode 7.0 で問題が生じた >>113、>>114 として、 Unicode 6.3.0 版を最後にIANA登録簿の更新を中断しています。
[121] 本来実装は IANA登録簿の表ではなく Unicode の特性に基づかなければならないはずなので、 IETF が恣意的にIANA登録簿の更新手続きを停止し続けると正確な実装 (があるとして...) と IANA登録簿が乖離していって好ましくない気がしますが...
[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ラベル)。
[46] また、それまで妥当とされながらも実際には IDNAラベルでないものを非妥当とした >>36 とあります。これが何を指すのか明確には記述されていませんが、用語の定義の明確化と同時に R-LDHラベルであってAラベルでないものの利用が禁止されたことを指しているのでしょう。
[37] ドメイン名の登録と lookup の手順が別々に定義されるようになりました >>36。 IDNA2003 でも AllowUnassigned のようなフラグがあったとはいえ、基本的には登録も lookup も共通の手続きとして規定されていました。これが IDNA2008 では完全に別々の手続きとして定義されています。
[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 の新しい版に機械的に追随できるようになっています。詳しくは導出特性値の項をご覧ください。
[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ラベルだけを認める (正規化が必要であったバリエーションは認めない) ことが非常に好ましいとされています >>10 7.3。
[62] これらの変更により IDNA2003 では正規化の結果直接利用できなかった文字が IDNA2008 では利用できることがあります。具体的には、
... が使えるようになりました。 >>10 7.2.1
[66] これらの文字に関しては、 IDNA2003 と IDNA2008 でどちらも正しいドメイン名として lookup でき、しかし異なる結果が得られる可能性があります。 レジストリーはそれによって混乱が生じないような方策を練るべきです >>10 7.2.3。
[72] 正書法的には利用できるべきであるものの、 IDNA2003 と Aラベル (ACEラベル) レベルでの互換性が失われてしまうのですが、それがACE接頭辞の変更を伴わずに済むなら、 ということで非互換変更を認めてでもこれらの文字を利用できるようにするべきと判断されました >>10 7.2.3。
[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。
[42] IDNA2003 の bidi に関する制約によれば、ラベルの末尾に結合文字を使うことができず >>10 4.5.、これが原因で Dhivehi や Yiddish の一般的な単語の表記 >>36 に支障が生じていていましたが、規制の緩和によりこれが認められるようになりました。
[45] ラベル分離子という概念がプロトコルから削除されました >>36。
IDNA2003 では . などの「点」によってドメイン名を分割してラベルを取り出して処理することになっていましたが、
その部分は利用者インターフェイスの範疇であるとして削除されました。
[20] IDNA2003 と IDNA2008 の間の非互換変更により、 IDNA2003 における解釈を期待していたドメイン名が IDNA2008 では解釈できなくなる場合があります。その場合、 lookup は失敗としても構いませんし、 失敗したら IDNA2003 で lookup し直しても構いませんし、最初から IDNA2003 と IDNA2008 の両方で lookup しても構いません。ただし、 解釈の違いを突いた攻撃ができるかもしれないので注意が必要です。
[75] >>62、>>68 では IDNA2003 では他の文字列に正規化されてしまい厳密には表現できなかったラベルが IDNA2008 で表現できることになり、 IDNA2003 と IDNA2008 のどちらで lookup するかによって結果が変わってしまい混乱や保安上の問題の元となります。 そのため、レジストリーは何らかの移行戦略を練ることが要求されています >>10 7.2.4。
[97] Unicode Consortium は UTS #46 により IDNA2003 と IDNA2008 の中間のどちらとも実用上互換性がある算法「Unicode IDNA互換性処理」を規定しています。 IDNA2003 と IDNA2008 の差異についてはそちらの項も参照してください。
[87] IDNA2003 は正規化や大文字から小文字への変換などを含めて規定していましたが、 IDNA2008 はそれは利用者インターフェイスの範疇であった >>11 としてプロトコルから除外しています。これらの処理は利用者が使っている言語などの文脈によって何が適切かが変化するものであり、 画一的にプロトコルのレベルで行うべきではないと考えられています。
[88] IDNA2008 は利用者が与えたドメイン名をどう処理するかの例として次の手順を示していますが、 同時にこれは特定の場面でのみ意味のある例を示したに過ぎず、アプリケーションの実装者が十分に検討するべきであるともしています >>11。
[43] はじめからそのように設計されていたのなら、 アプリケーション依存の利用者インターフェイスの範疇ということで何の問題もなかったのですが、現実にはそうではありません。 IDNA2003 はこれらの処理を含めて規定したのですし、 IDN 以前の元々のドメイン名が大文字・小文字不区別だったのに、 突然その規定が無くなってアプリケーションに丸投げでは、 互換性も相互運用性もあったものではありません。
[134] しかも、ここでいう「アプリケーション」 がアプリケーションプロトコルのことなのかアプリケーションプログラムのことなのかも定かではありません (どちらも含まれているのかもしれませんが)。
[135] 例えば URL では正規化の一部として IDNA2003 の処理が行われているので、 IDNA2008 に移行すると重要な規定が欠落した状態になるため、 どう対処するべきか仕様によっても対応が定まらず長年混乱しています。
[133] 厳密に言えば、この煮え切らない規則が書かれている RFC 5895 >>11 は IETF の標準化過程にある IDNA2008 シリーズの RFC ではなく、 個人提出の Informative な RFC という位置付けになっています >>130。
[129] IDNA2008 発行後に Unicode Consortium から発行された UTS #46 は、 同仕様に基づく前処理の方法を規定しています (IDNA2008前処理)。
[132] IDNA2008 のこの非互換な変更で、実質的に単体で実装不可能になったため、 多くの実装が IDNA2008 ではなく UTS #46 を採用しています。
[116] IDNA2003 から IDNA2008 への改訂で Stringprep から独自方式へと移行しましたが、 IDN (Nameprep) 以外の Stringprep 応用も多かれ少なかれ問題を抱えていたので、 改訂が必要でした。
[117] IETF は PRECIS と称する仕様を新たに開発し、 Stringprep にかえて各プロトコルで採用することにしました。 PRECIS は2015年に RFC として出版されました。
[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 を採用していて微妙に異なっています。 (起源 (>>120)参照。)
[95] XMPP は JID で Nodeprep や Resourceprep も使用しているため、 IDN だけ新版に移行するわけにもいかず、将来の改訂で IDNA2008 に移行すると予告しつつも IDNA2003 を採用しています。
[17] IDNA2008 は IDNA2003 からいくつかの文字の解釈を変更しているので、 ゾーン管理者は注意するべきです。
[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