Edit

Page

Page title:

Page body:

[12] [DFN[IDNA2008]] は、 [[IDNA]] 
の[TIME[西暦2008年(平成20年)][2008]]頃の改訂版です。

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

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

* 仕様書

[REFS[
- [6] [CITE@en[RFC 5890 - Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework]] ([TIME[2010-08-05 01:32:35 +09:00]] 版) <http://tools.ietf.org/html/rfc5890>
- [7] [CITE@en[RFC 5891 - Internationalized Domain Names in Applications (IDNA): Protocol]] ([TIME[2010-08-05 01:32:40 +09:00]] 版) <http://tools.ietf.org/html/rfc5891>
- [8] [CITE@en[RFC 5892 - The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)]] ([TIME[2010-08-05 01:32:32 +09:00]] 版) <http://tools.ietf.org/html/rfc5892>
- [9] [CITE@en[RFC 5893 - Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)]] ([TIME[2010-08-05 01:32:45 +09:00]] 版) <http://tools.ietf.org/html/rfc5893>
- [10] [CITE@en[RFC 5894 - Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale]] ([TIME[2010-08-05 01:32:43 +09:00]] 版) <http://tools.ietf.org/html/rfc5894>
- [11] [CITE@en[RFC 5895 - Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008]] ([TIME[2010-09-15 04:55:59 +09:00]] 版) <http://tools.ietf.org/html/rfc5895>
- [15] [[IDNA2003]] のうち [[Punycode]] ([[RFC 3492]]) は [[IDNA2008]] でも使われています。
- [101] [CITE[IDNA Parameters]] 
<http://www.iana.org/assignments/idnabis-tables/idnabis-tables.xml>
- [102] [CITE@en[RFC 6452 - The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0]] ([TIME[2011-11-13 16:13:22 +09:00]] 版) <http://tools.ietf.org/html/rfc6452>
]REFS]

* Unicode の版

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

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

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

** Unicode 6.0.0

[100] 
[TIME[西暦2011年(平成23年)8月12日][2011-08-12]]付けで 
(実際には[TIME[9月21日][2011-09-21]]に) [[Unicode]] 6.0.0 版の情報が登録されています。
それについての [DFN[[[RFC 6452]]]] (>>102) も発行されています。

[103] [[Unicode]] への[[文字]]の追加による [CODE(char)[[[UNASSIGNED]]]] から他の[[導出特性値]]への変更の他に、
3つの[[文字]]が [CODE(char)[[[GeneralCategory]]]] の変更に伴って[[導出特性値]]が非互換に変更されています [SRC[>>102]]。
[FIG(list)[
- [CODE(char)[[[U+0CF1]]]] [CODE(charname)@en[[[KANNADA SIGN JIHVAMULIYA]]]] [CODE(char)[[[DISALLOWED]]]] -> [CODE(char)[[[PVALID]]]]
- [CODE(char)[[[U+0CF2]]]] [CODE(charname)@en[[[KANNADA SIGN UPADHMANIYA]]]] [CODE(char)[[[DISALLOWED]]]] -> [CODE(char)[[[PVALID]]]]
- [CODE(char)[[[U+19DA]]]] [CODE(charname)@en[[[NEW TAI LUE THAM DIGIT ONE]]]] [CODE(char)[[[PVALID]]]] -> [CODE(char)[[[DISALLOWED]]]]
]FIG]

** Unicode 7.0.0

[120] [[IETF]] は [[Unicode 7.0]] で問題が生じた [SRC[>>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]] の[[規定]]に基づき計算した表の比較:
[REFS[
- [123] [CITE@en[Compare character sets "$idna-tables-6.3.0:PVALID" and "$rfc5892:PVALID"]] ([TIME[2016-01-05 18:09:10 +09:00]] 版) <https://chars.suikawiki.org/set/compare?expr1=%24idna-tables-6.3.0%3APVALID&expr2=%24rfc5892%3APVALID>
- [124] [CITE@en[Compare character sets "$idna-tables-6.3.0:CONTEXT" and "$rfc5892:CONTEXT"]] ([TIME[2016-01-05 18:09:28 +09:00]] 版) <https://chars.suikawiki.org/set/compare?expr1=%24idna-tables-6.3.0%3ACONTEXT&expr2=%24rfc5892%3ACONTEXT>
- [125] [CITE@en[Compare character sets "$idna-tables-6.3.0:DISALLOWED" and "$rfc5892:DISALLOWED"]] ([TIME[2016-01-05 18:09:43 +09:00]] 版) <https://chars.suikawiki.org/set/compare?expr1=%24idna-tables-6.3.0%3ADISALLOWED&expr2=%24rfc5892%3ADISALLOWED>
- [126] [CITE@en[Compare character sets "$idna-tables-6.3.0:UNASSIGNED" and "$rfc5892:UNASSIGNED"]] ([TIME[2016-01-05 18:09:57 +09:00]] 版) <https://chars.suikawiki.org/set/compare?expr1=%24idna-tables-6.3.0%3AUNASSIGNED&expr2=%24rfc5892%3AUNASSIGNED>
]REFS]

* 処理

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

* IDNA2003 からの主要な変更点

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

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

** 用語の整理

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

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

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

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

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

** Unicode の版の非依存化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[62] これらの変更により [[IDNA2003]] では[[正規化]]の結果直接利用できなかった[[文字]]が
[[IDNA2008]] では利用できることがあります。具体的には、
- [64] [CODE(char)[[[U+00DF]]]] [CODE(charname)@en[[[LATIN SMALL LETTER SHARP S]]]]
- [63] [CODE(char)[[[U+03C2]]]] [CODE(charname)@en[[[GREEK SMALL LETTER FINAL SIGMA]]]]

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

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

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

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

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

** Join_controls の扱いの変更

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

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

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

** 記号類の排除

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

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

** bidi 制約の変更

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

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

** ラベル分離子の廃止

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

** fallback

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

[REFS[
-[99]  [CITE@en[RFC 5890 - Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework]] 
<http://tools.ietf.org/html/rfc5890#section-4.6>
]REFS]

;; [21] [[IDNA2003]] 使っても良いとか本当にそんな姿勢でいいのか・・・?

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

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

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

- [77] 新たに利用できるようになった[[文字]]を使った[[登録]]を認めない。
-- [78] [[IDNA2003]] で [[lookup]] できていたものができなくなることはありますが、意図しないものに
[[lookup]] されてしまうのは防げます。
- [79] [["sunrise"-like arrangement]]: 複数の表現の片方を既に[[登録]]している人がいれば、
優先的に新しい表現を[[登録]]できるようにする。
- [80] "[[variant]]" approach その1: 両方の表現を[[登録者]]は取得できる。
- [81] "[[variant]]" approach その2: 一方の表現が[[登録]]されていれば、他方の表現では[[登録]]できないか、
もう一方の[[登録者]]に限って[[登録]]できる。
- [82] 何もせず、[[市場]]その他に委ねる。

;; [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]] はそれは[[利用者インターフェイス]]の範疇であった [SRC[>>11]]
として[[プロトコル]]から除外しています。これらの処理は[[利用者]]が使っている[[言語]]などの文脈によって何が適切かが変化するものであり、
画一的に[[プロトコル]]のレベルで行うべきではないと考えられています。

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

;; [89] つまり丸投げですね。

[FIG(steps)[
= [90] [[大文字]]を[[小文字]]に変換します。
= [91] [[全角]]や[[半角]]を正規化します。
= [92] [[NFC]] にします。
= [93] [CODE(charname)@en[[[FULL STOP]]]] や [CODE(charname)@en[[[IDEOGRAPHIC FULL STOP]]]]
で[[ドメイン名]]を[[ラベル]]の列に分割します。
]FIG]

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

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

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

[133] 厳密に言えば、この煮え切らない規則が書かれている [[RFC 5895]] [SRC[>>11]]
は [[IETF]] の[[標準化過程]]にある [[IDNA2008]] シリーズの [[RFC]] ではなく、
個人提出の [[Informative]] な [[RFC]] という位置付けになっています [SRC[>>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]] における[[ドメイン名]]の処理でも、[CITE[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]]) は、 [CODE[[[domainpart]]]] における[[準備]]、[[執行]]、[[比較]]の処理を
[[IDNA2008]] をベースに規定しています。

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

* 歴史

[1] [CITE@en-us[UTS #46: Unicode IDNA Compatible Preprocessing]]
([TIME[2008-12-10 08:56:55 +09:00]] 版)
<http://www.unicode.org/reports/tr46/tr46-1.html>

[2] [CITE@en-us[Unicode IDNA Compatible Preprocesssing]]
([TIME[2009-09-30 06:24:51 +09:00]] 版)
<http://www.unicode.org/reports/tr46/tr46-2.html>

[3] [CITE@en[draft-ietf-idnabis-mappings-04 - Mapping Characters in IDNA]]
([TIME[2009-09-29 08:04:24 +09:00]] 版)
<http://tools.ietf.org/html/draft-ietf-idnabis-mappings>

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

[5] [CITE[Security Degradations with IDNA2008 (Macchiato)]]
([TIME[2010-01-29 03:18:08 +09:00]] 版)
<http://www.macchiato.com/unicode/idna/security-issues>

* 各種仕様書・実装の対応

[16] [[Web Applications 1.0]] は現在でも [[IDNA2003]] を採用しています。 [TIME[2011-03-19T10:39:25.300Z]]

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

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

[105] [[Widgets]] も [[IDNA2003]] を採用しています [SRC[>>104]]。 [TIME[2012-02-10T14:10:22.700Z]]

[REFS[
- [96] [CITE@en[RFC 6122 - Extensible Messaging and Presence Protocol (XMPP): Address Format]] ([TIME[2011-03-31 08:23:44 +09:00]] 版) <http://tools.ietf.org/html/rfc6122>
- [104] [CITE[Widget Access Request Policy]] ([TIME[2012-02-04 04:00:27 +09:00]] 版) <http://dev.w3.org/2006/waf/widgets-access/#processing>
]REFS]

* メモ

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

[REFS[
- [18] [CITE@en[RFC 5890 - Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework]] 
<http://tools.ietf.org/html/rfc5890#section-4.1>
]REFS]

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

- [23] 複数の [[RFC]] に分かれているせいで話題がまとまっていない
-- [47] 他の [[RFC]] を読まないとまったく理解できない話題が突然登場したりするので、なぜ分割されているのかわからない
-- [48] 内容がきっちり分離できるとか、どちらかが完全に部分集合になってるとかじゃないと複数に分割する意味はないんじゃないの
- [24] 同じ概念を表す用語と思われるもののぶれが大きく、わざわざ別の表現で言い直したり
-- [25] [[非妥当Uラベル]]などはわざわざ数種類の同じ意味の表現を導入している
-- [26] 定義されているのはまだましな方で、殆どの場合は本当に同じ意味なのかどうか文脈で推測するしかない
- [27] 他の場所への言及がわかりにくい
-- [28] 「第○節のチェック」というのはましな方で、「以降のチェック」とか「○○文書の一覧表」など曖昧なポインターを多用している
--- [34] しかもそのポインターが、同じとみられるものでも場所によって違う表現になっている
-- [29] せめて何か相互参照用の名前か数字でも付けて欲しいものだ
- [30] 手順の説明に補足説明や関連する話題が混じったり、手順内での条件分岐がよく読まないと気づかなかったりで、読んで容易に追えるようになっていない
- [71] 章節の構成が一貫しておらず、並列なものが並んでいるように見せかけて一部そうでないものが混じっていたりする
- [33] 何が要件でいつそれが満たされなければならないのか明確でない
-- [31] 実装依存の要件が多く、その要件に依存した要件や説明があったりして難解過ぎる
-- [32] [[RFC 2119]] の[[助動詞]]を使っていたり、[[小文字]]の[[助動詞]]を使ったりして、何に従えばいいのかわからない
- [56] 想定読者の種類が多すぎるにも関わらず誰に対する説明か不明瞭である
-- [57] [[登録]]作業を行う人、[[登録]]の手続きを決める人、[[IDNA]] 対応プロトコルを作る人、[[IDNA]] 対応プロトコルを実装する人、 [[IDNA]] 対応プロトコルに対応したアプリケーションを実装する人、...

[107] [CITE[IRC logs: freenode / #whatwg / 20120928]]
( ([TIME[2012-10-03 22:06:16 +09:00]] 版))
<http://krijnhoetmer.nl/irc-logs/whatwg/20120928#l-801>

[108] [CITE[IRC logs: freenode / #whatwg / 20121005]]
( ([TIME[2012-10-08 21:33:56 +09:00]] 版))
<http://krijnhoetmer.nl/irc-logs/whatwg/20121005#l-351>

[109] [CITE[Updating RFC 5890-5893 (IDNA 2008) to Full Standard]]
( ([TIME[2012-11-18 10:28:39 +09:00]] 版))
<http://www.alvestrand.no/pipermail/idna-update/2012-November/007465.html>

[110] [CITE[IRC logs: freenode / #whatwg / 20121116]]
( ([TIME[2012-12-02 12:20:05 +09:00]] 版))
<http://krijnhoetmer.nl/irc-logs/whatwg/20121116#l-141>

[111] [CITE[Updating RFC 5890-5893 (IDNA 2008) to Full Standard]]
( ([TIME[2012-11-18 10:28:39 +09:00]] 版))
<http://www.alvestrand.no/pipermail/idna-update/2012-November/007467.html>

[112] [CITE[IRC logs: freenode / #whatwg / 20121116]]
( ([TIME[2012-12-02 12:20:05 +09:00]] 版))
<http://krijnhoetmer.nl/irc-logs/whatwg/20121116#l-835>

[113] [CITE@en[draft-klensin-idna-5892upd-unicode70-04 - IDNA Update for Unicode 7.0.0]]
([TIME[2015-04-24 04:25:15 +09:00]] 版)
<https://tools.ietf.org/html/draft-klensin-idna-5892upd-unicode70-04>

[114] [CITE@en-US[IAB Statement on Identifiers and Unicode 7.0.0 | Internet Architecture Board]]
([TIME[2015-05-22 16:49:22 +09:00]] 版)
<https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-statement-on-identifiers-and-unicode-7-0-0/>

[115] [CITE@en[RFC 7622 - Extensible Messaging and Presence Protocol (XMPP): Address Format]]
([TIME[2015-12-08 07:08:54 +09:00]] 版)
<https://tools.ietf.org/html/rfc7622>

[130] [CITE@en[RFC 8170 - Planning for Protocol Adoption and Subsequent Transitions]] ([TIME[2017-05-25 22:30:49 +09:00]]) <https://tools.ietf.org/html/rfc8170#appendix-A.2>

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

[139] [CITE@en[draft-faltstrom-unicode11-00 - IDNA2008 and Unicode 11.0.0]]
([TIME[2018-06-19 18:15:24 +09:00]])
<https://tools.ietf.org/html/draft-faltstrom-unicode11-00>

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)