メインコンテンツへジャンプする

JPNICはインターネットの円滑な運営を支えるための組織です
文字サイズ:
プリント用ページ

ニュースレターNo.44/2010年3月発行


インターネット歴史の一幕:
国際化ドメイン名の標準化

株式会社日本レジストリサービス 米谷 嘉朗

国際化ドメイン名(Internationalized Domain Name、以降IDNと略記します)のRFCが発行されたのは2003年3月ですから、IDNが標準化されてもう7年近く経過したことになります。この7年間で、IDNを取り巻く状況は随分と変化しました。例えば、PC用の主要なブラウザは、全てIDNに対応したので、IDNのWebサイトへのアクセスは自然と行えるようになりましたし、さまざまなメディア上でIDNを見かけることも増えてきました。2010年中には、IDNのTLDまで登場します。

IDNの標準化に関わった一人として、この広がりを大変に嬉しく思っています。

IDNの標準化を通じて学んだことは、以下の5点です。

(1) 国外に仲間を作る

国際標準を作るということは、相当の力が必要であり、独力で成し得るのは困難です。また、世界中の人が利用するものですから、特定の地域や国の都合が感じられる提案は、受け入れられるのも困難です。そのため、国内はもとより国外にも一緒に提案をしていく仲間を作ることが、標準化組織の場で合意を得るためには重要です。

具体的にIDNの標準化においてやったことですが、中国・日本・韓国・台湾のccTLDで共同技術チーム(Joint Engineering Team、以降JETと略記します)を編成して技術的な検証や提案を共同で行ったり、IETFでの経験が豊富で影響力がある人にドキュメントの共著者となってもらったりしました。個別にJETの会合を開き、時には12時間以上にも及ぶ激しい議論を繰り返しながら4者の意見を集約し、それをIETFで提案することで説得力を持たせ、標準化を進めることができました。

(2) 実装を作る

IDNの標準化過程では、文字列正規化の方式やASCII互換表現(ASCII Compatible Encoding、以降ACEと略記します)への変換アルゴリズムに複数の提案が行われました。それら提案が、想定したシナリオ通りに動作するか、相互接続性を持つか、そもそも実装可能かということを検証するために、JPNICでmDNkitおよびidnkitという参照実装を開発し(私もこの開発には深く関わりました)、オープンソースのツールキットとして公開しました。提案が実際に動くことを示すことは、標準化の方式を決定していく上で非常に大きな説得力を持ちました。

また、idnkitは緩やかなライセンスのツールキットとして開発したため、ブラウザベンダーやDNSソフトウェアベンダーなどに採用を働きかけ、早期のIDN環境整備に役立てることができました。

(3) 対立提案を評価する

前述の通り、IDNの標準化過程では多くのACE変換アルゴリズムが提案されました。そのため、どのアルゴリズムを採用するのが適切なのかを判断しなければならず、具体的な評価に基づく比較が必要でした。そこで、JETで既に登録された多数のIDN(試験登録を含む)をサンプルに、各ACEアルゴリズムを評価し、それぞれのccTLDの観点(韓国ではハングル、中国・台湾では漢字、日本では漢字と仮名の混合など)から優れたACEを導き出しました。その結果を合同で「適切と思われるACE」としてIETFで提案し、結論として合意されました。

(4) プロトコルと運用を分ける

中国語文化圏では、台湾などで使われている繁体字と中国などで使われている簡体字は、例えば「國」と「国」など由来が同じであれば同じ文字とみなしたいという要求が強くあります。そのため、IDNの標準化過程において、アルファベットの大文字と小文字を区別しないのと同様に、それをプロトコルレベルで取り入れるべきという主張が続いていました。しかし、それは前述のように特定の地域や国の都合であるため受け入れられず、一時期平行線をたどっていました。

IDNの標準化が達成されないことは誰にとっても望まれないことであったため、長い議論の末、JETの中でプロトコルでは別の文字として扱うが、運用では同じ文字として扱うという方針が合意され、そのための運用ガイドライン作成を行いました。

この運用ガイドラインはRFC3743として発行され、IDN登録と運用に関する重要なモデルとなっています。

(5) 標準化はゴールではなく、スタートである

標準化は、グローバルなサービスを提供するために必要なツールの一つです。標準化しその標準に準拠することよって、同じ機能を持つサービスや製品を異なる人が実装しても相互接続性が保証されるのです。

ところで、それらサービスや製品の実装者は、標準と需要があって初めて実装を開始します。一方、利用者はアプリケーションなどの実装があって初めてサービスを利用するため、往々にして鶏と卵問題を引き起こします。

IDNの場合は、ブラウザのIDN対応がブレイクスルーでしたが、それも、IDNの標準化が行われたからこそです。


IDNが標準化され、IDN登録サービスが始まり、IDN対応アプリケーションが普及したことにより、IDNの利用が増加しました。それに伴って新たな課題が見つかっています。例えば、見かけが文字に良く似た記号を使って、著名ドメイン名との誤解を招くようなドメイン名を登録できてしまう問題の解決などです。運用対処だけでは困難なこともあるため、現在、IDNの標準そのものの改訂作業が行われています。改訂作業も最終段階にあり、今年中には新しいRFCが発行される見込みです。

プロトコルが見直され、改訂されていくということは、それがグローバルに使われていることの証左であると言えるでしょう。IDNがホットトピックとなりそうな今年、IDNの歴史を振り返って見るということは、なかなか興味深いのではないかと思います。

このページを評価してください

このWebページは役に立ちましたか?
ページの改良点等がございましたら自由にご記入ください。

このフォームをご利用した場合、ご連絡先の記入がないと、 回答を差し上げられません。 回答が必要な場合は、お問い合わせ先をご利用ください。

▲頁先頭へ