JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
増刊号
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2006-04-06━
◆ FROM JPRS 増刊号 vol.52 ◆
━！ＪＰ━━━━━━━━━━━━━━━━━━━━━━━━━ＪＰＲＳ━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
IDNに関する最近の話題（前編）
～2006年3月のIETF、ICANN会合報告～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
今年になって、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)
http://jprs.jp/
http://日本レジストリサービス.jp/
会議報告： http://jpinfo.jp/event/
メールニュース配信解除： http://jpinfo.jp/mail/
ご意見・ご要望： from@jprs.jp
当メールマガジンの全文または一部の文章をホームページ、メーリングリスト、
ニュースグループまたは他のメディア等へ許可なく転載することを禁止します。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Copyright(C), 2006 Japan Registry Services Co., Ltd. 2006年04月06日
Copyright©2001-2024 Japan Registry Services Co., Ltd.