JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト


ドメイン名関連会議報告

2006年

IDNに関する最近の話題(前編)

~2006年3月のIETF、ICANN会合報告~

2006/04/12

今年になって、IDNに関連する国際的な検討が活発化しています。特に注力して検討されているのがIDNガイドライン、国際化メールアドレス、TLDへのIDN導入などです。そして、派生的ではありますが、「中国がオルタネート・ルート(*1)を使ってIDN TLDを導入したのではないか」という話題もありました。
これらにつき、2006年3月に行われたIETFおよびICANNの両会合の状況も踏まえ、その経緯と動向を2回に分けて報告します。今回、前編として、IDNガイドラインと国際化メールアドレスについて報告します。次回は、後編として、TLDへのIDN導入とオルタネート・ルートに関して報告する予定です。

IDNについては、1990年代末より、英語圏以外の利用者が使いやすいドメイン名が必要であるという強い動機のもと、CJK(中国語、日本語、韓国語)地域が中心となり、技術、サービス両面で世界を引っ張ってきました。その結果、2003年3月には基本プロトコルがRFC(*2)として発行され、同6月には、.jpを始め、幾つかのTLDでRFC準拠のIDN登録管理サービスが開始されました。

それと並行し、ユーザーがIDNを使うためのアプリケーションの開発・普及が進み、特にWebブラウザは、ほとんどの種類のソフトウェアでIDNを扱うことができるようになりました。圧倒的シェアを誇るMicrosoft社のInternet Explorerには、まだIDN機能が搭載されていませんが、これも2004年12月のICANN会合で、Microsoft社のシニア・プログラム・マネージャーから「2006年にIDN対応する」ということが公表され、それを裏付けるように現在入手可能なInternet Explorer 7のベータ版ではすでにIDN機能の実装が確認されています。これをきっかけとしてか、2005年から、開発途上国のccTLDを含む多くのTLDで、IDNサービス導入の検討が急激に進み、さらには、「TLDにもASCII以外の文字を使用可能とすべき」という要求も急激に現実のものとして表面化するようになってきました。

会議の模様
会議の模様

(1) IDNガイドライン


ここでいうIDNガイドラインとは、ドメイン名レジストリがIDN登録管理を行うときに従うべき(もしくは従うことが望ましい)ガイドラインをまとめたものです。そもそもは、2000年11月にVeriSignがIDN登録管理サービスを始めたとき、「UNICODE表のすべての文字を任意に組み合わせて作ることができる文字列すべてをIDNとみなす」というルールを作ったことに始まります。結局、それが、IDNにおいて、各国語の文字を適当に組み合わせたり記号を用いたりということにつながり、英語圏以外でも使いやすくしたいという本来の目的からかけ離れた無意味なIDNを数多く生みました。また、等価な複数の文字(たとえば中国での繁体字と簡体字)を違うものとして扱うことによりサイバースクワッティングなどを増加させるという問題も生じました。IDNガイドラインは、「健全なIDN環境のためには、IDNの利用が広がる前に、これらの問題の解決を図る仕組みを作っておく必要がある」という共通認識が生まれたというところに端を発しています。

この問題に対し、CJK地域のccTLDレジストリの技術者が集まったチームJET(Joint Engineering Team)が作成したガイドライン(後にRFC3743(*3)となった)や、他の技術者が提案したガイドラインに関する議論がIETFでなされ、それらをまとめる形で、2003年6月、ICANNがドメイン名レジストリに対するガイドライン(IDNガイドラインv1.0)を作成し、公開しました。同時に、.jpなどそのガイドラインに沿ったサービスを提供するTLDも現れました。

ガイドラインでは、主に次のことが規定されています。

  ・基本プロトコルはRFCに従うこと
  ・IDNで使える文字の集合を(列挙するなどにより)明確に規定すること
  ・各IDNを言語に結びつけること(複数の言語に属する文字を混ぜないこと)
  ・必要に応じ、等価文字を定義すること

このガイドラインに従い、レジストリ、レジストラ、アプリケーション開発者、利用者がIDNに関する経験を積む中で、ガイドラインの改訂すべき点が見えてきました。一つは、言語という概念だけでなく、言語とスクリプト(*4)の組合せで、各IDNが構成される文字を規定すべきであるということです。二種以上のスクリプトを用いる言語や一つのスクリプトを共有する2つ以上の言語に対応するための改訂です。もう一つは、2つ以上の言語およびスクリプトの文字を一つのIDNラベル内で混ぜて使ってはいけないという原則をさらに細かく規定したことです。これは、2005年2月に一時騒がれたIDNで使える似た文字をフィッシングに使うというセキュリティ問題の抑制(*5)、また、UNICODEコンソーシアムが文字表記の類似性を細かく分析しそれらを抑制するために作成した規定(UTR#36(*6)およびUTS#39(*7))に基づくものです。これらに基づき、2005年11月と2006年2月にIDNガイドラインが改訂されました(それぞれv2.0、v2.1(*8))。v1.0からv2.0、v2.1に改訂されるに際し、ガイドラインそのものの意図は変わっていませんが、規定が明確にされたととらえてよいと考えます。

このガイドラインは、ICANNと契約しているgTLDは必ず守るべきものであるとされています。しかし、それにとどまらず、ccTLDレジストリのIDN登録管理サービスや、ドメイン名登録者がサブドメイン名を作るときにおいても、健全で他TLDと調和したIDN登録管理のために参照できるガイドラインを目指しています。また、このガイドラインをさらにICANNコミュニティ外にも広く使ってもらうべく、IETFのBCP(Best Current Practice)文書にする作業も進められています。

(2) 国際化電子メールアドレス

ドメイン名を使う代表的なアプリケーションは、Web閲覧と電子メールです。Web閲覧に関しては、ブラウザのアドレスバーやhtmlテキスト内のリンク先として、Web閲覧であることを示す「http://」に続けてIDNを書けば、それでIDNを利用できるため、アプリケーションがIDN標準技術にしたがって作成されていれば、ユーザーはIDNを使えるということになります。しかし、電子メールについては、@の左側(ローカルパートと呼ばれます)も必ず書かねばならず、この部分にASCII以外が使えるという「国際化電子メールアドレス」への要望が大きくなっています。しかし、ローカルパートはドメイン名ではないため、ASCII以外を使えるようにするには新たな技術標準が必要になります。さらに、ローカルパートの記法とその解釈は、その名の通り(たとえばメールサーバを運用する企業単位で)ローカルに決められている場合もあり、IDNのように標準化が簡単ではありません。

本件に関しても、JETのメンバが検討を主導し、その必要性をアピールするとともに、基本技術をIETFに提案し、技術検討のベースを作っています。ただし、2002年頃にIDNの基本プロトコルの検討が佳境であったときとは異なり、IDNが本格的にインターネット全体で受け入れられ始めていること、電子メールには関連するプロトコルが数多くありIDNを扱えるようにするためには広範囲の技術者の協力が必要であることなどから、最初から世界中の多くの技術者を巻き込んで検討が行われています。

国際化メールアドレスに関するIETFでの検討は、2003年の2月上旬から始まったメーリングリストでの議論から始まります。この時点では、IDNがWeb閲覧にすら広く使われていなかったことから、実現への市場要求も地に足がついたものではなく、その後IETFでは2003年11月と2004年3月に2度BoFが開催されたあとは、一旦検討休止の状況となっていました。しかし、最近のIDN利用環境の充実により、2005年にJETでの国際化メールアドレスの検討が再始動し、2005年8月IETFでのBoF準備会合、2005年11月IETFでのBoFを経て、2006年3月にIETFのEAI WG(Email Address Internationalization Working Group(*9))が設立されました。その直後の2006年3月IETFで、数十名を集めて第1回WG会合が開かれました。主な論点は、国際化電子メールアドレスを扱うための

  ・全体フレームワーク
  ・電子メールヘッダの構成
  ・SMTPの拡張
  ・国際化電子メールアドレスに対応したソフトと対応しないソフトの通信方法

に関する技術です。

現在の予定では、EAI WGは今後1年程度で実験提案を作成して初期技術検討を終わり、2007年3月から、正式な技術標準化を目指した活動に移行することになっています。電子メールに関連するプロトコルも数多く、また、それを実装しているサーバやクライアントソフトウェアも数多くあるため、技術標準となった後も、インターネットユーザーが一般的に国際化電子メールアドレスを利用できるまでには、まだ時間がかかるものと思われます。

(*1)
オルタネート・ルート(alternate root)
DNSはルートを頂点とした階層構造が保たれています。これに対して、様々な技術を用いて独自のルートサーバを設置し「擬似的な」TLDを創設したものをオルタネート・ルートと呼んでいます。ICANNを中心とするインターネット資源管理構造の中でドメイン名の一意性が保たれていますが、オルタネート・ルートの存在によってその一意性が保証できないため、問題であるとされています。
(*2)
IDN関連プロトコルのRFC
RFC3454 (STRINGPREP)
http://www.ietf.org/rfc/rfc3454.txt
RFC3490 (IDNA)
http://www.ietf.org/rfc/rfc3490.txt
RFC3491 (NAMEPREP)
http://www.ietf.org/rfc/rfc3491.txt
RFC3492 (Punycode)
http://www.ietf.org/rfc/rfc3492.txt
(*3)
JETガイドライン
RFC3743 (JET Guidelines for IDN)
http://www.ietf.org/rfc/rfc3743.txt
(*4)
スクリプト (script)
言語を表記するのに使用する特定の体系に則ってまとめられた文字の集合のことで、用字ともいいます。たとえば、漢字、ひらがな、カタカナ、ハングル、ギリシャ文字はそれぞれスクリプトです。複数の言語が一つのスクリプトを共有することもあります(欧州のラテン文字など)し、一つの言語が複数のスクリプトを使用する(日本語の漢字、ひらがな、カタカナ、アルファベットなど)こともあります。
(*5)
国際化ドメイン名(IDN)のフィッシング詐欺脆弱性について
http://日本語.jp/access/phishing.html
(*6)
UTR#36 Unicode Security Considerations
http://www.unicode.org/reports/tr36/
(*7)
UTS#39 Unicode Security Mechanisms
http://www.unicode.org/reports/tr39/tr39-1.html
(*8)
IDNガイドラインVersion2.1
http://www.icann.org/general/idn-guidelines-22feb06.htm
(*9)
Email Address Internationalization (eai) Working Group
http://www.ietf.org/html.charters/eai-charter.html

本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。

「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。