ニュースレターNo.23/2003年3月発行

JANOG11

2003年1月23日～24日の2日間にわたり、JANOG 11「論」Meetingが開催されました。JANOGとは、JApan Network Operators' Groupの略で、インターネットにおける技術的事項、オペレーションに関する事項の議論、検討、紹介などを行っているグループです。このミーティングでJPNICからは2つのプレゼンを行いましたが、そのうちの1つ「RFC発行直前!? 国際化ドメイン名サイトを運営するには」についてレポートいたします。

JPNICは、1999年5月にタスクフォースを設置し、国際化（多言語）ドメイン名の技術仕様（IDNA）標準化や、国際化ドメイン名機能を実現するためのツールキット（idnkit）開発に取り組んできました。2002年10月24日、IESG（Internet Engineering Steering Group）は国際化ドメイン名の技術仕様を記述したInternet-Draft（3種類）のProposed Standard RFC化を承認しました。これにより私たちが約4年間進めてきた国際化ドメイン名の研究開発が、成果として実を結ぶ段階となりました。さらに、RFC発行後に私たちが行うべき事項や、この技術を活用していくための課題などについて検討を進めています。

この活動の一環として、JANOG11の発表募集に応募し、JPNICから「RFC発行直前!? 国際化ドメイン名サイトを運営するには」と題して、発表を行うことになりました。JANOGは、日本のネットワークオペレータが多数参加する会議であり、特に今回の会議テーマは「論」と言うことで、活発な議論を行うことが目的となっており、有意義な意見交換ができるのではないかとの期待を胸に、会場に向かいました。

会場である秋田へは、1月下旬という時期にもかかわらず空路を選択したため、滑走路の除雪のために秋田上空でしばらく“浮遊”させられたのち、吹雪の中の秋田到着となりました。翌24日（発表当日）会場に入ると、前日からの悪天候にもかかわらず、多くの方が参加していました。インターネットエンジニアの情熱は、雪をも溶かすと言った感じでしょうか……。

そのような熱い雰囲気の中で、国際化ドメイン名による影響などについて説明を行いました。IDNAでは、ネットワーク層においてACE（ASCII互換エンコーディング）化されたPunycodeでドメイン名が表現されるため、DNSソフトウェア（BIND等）の変更やバージョンアップは不要です。しかし、ユーザーが利用するクライアントプログラムは、IDNAに対応したプログラムを使用する必要があります。
※詳しくは文末のURLに掲載の発表資料をご覧ください。

発表を終え質疑応答の時間に入ると、積極的に多くの方々から意見が寄せられました。ここでは、質疑応答のいくつかを紹介いたします。

質問：クライアントプログラムが、IDNAに対応しているのか未対応なのか判断することは難しく、未対応プログラムで国際化ドメイン名を使用してしまうことがあるだろう。リゾルバやキャッシュサーバ（再帰的な問い合わせを行うネームサーバ）で、ACE化する方法は取れないだろうか？
↓
回答：ルートサーバへの負荷などを考えると、なんらかの対応が必要になるかもしれない。最善策について検討していきたい。ただし、IDNAは現在のDNSプロトコルに変更を加えない方式を採用した。また、提案のような方法を実施するためには、他のプロトコルにも影響を与える可能性があるため、IETFのIDN-WGでの議論では、この方法は選択されなかった。この議論の経過から、サーバ側での対応は現実的ではないだろうと思われる。

質問：RACEとPunycodeの両方に対応するツールはないのだろうか？
↓
回答：idnkitはコンパイル時にオプションを指定することで対応可能。

質問：Webサーバやブラウザの説明が多いが、IDNはWeb利用が目的なのか？
↓
回答：ブラウザは、IDN対応のための作業が先行しているため説明させていただいた。IDNはWebだけのものではなく、他のアプリケーションにも広がって行ってほしい。

質問：tracerouteなどは、IDNAに対応させるのか？
↓
回答：是非libidnkitを利用していただきたい。IDNA化作業に協力していただきたい。

意見：nkfやlessにPunycode逆変換機能があると嬉しい。

以上のような活発な議論が行われ、大変有意義な時間を過ごすことができました。皆様から問題提起された課題を一つ一つ解決し、国際化ドメイン名の技術が成熟したものとなるよう、努力していきたいと思います。

（JPNIC 技術部準備室　小島育夫）