国際化(多言語)ドメイン名の標準化がほぼ収束

　第52回IETF MeetingにおけるIDN WG(Internationalized Domain Name Working Group、国際化ドメイン名の標準化を行っている)のMeetingで、日本語ドメイン名を実現する国際化ドメイン名の方式が合意され、標準化の最終段階に入りました。なお、WG Meetingの模様については、 JPNICメールマガジン「JPNIC News & Views」の第7号で報告していますので、あわせてご参照ください。

アーキテクチャ

　国際化ドメイン名は、利用者間のコミュニケーションを円滑にする上でたいへん役立つものですが、アプリケーションプログラムや通信機器間のコミュニケーションにとってはプロトコルのレベルで新しい仕様が追加されることになります。

　インターネットは地域や国の境界を越えて相互に接続されたグローバルなネットワークですから、地域や国に特有な仕様が追加されてしまうことによるコミュニケーションの分断は絶対に避けなければなりません。そのため、国際化ドメイン名のアーキテクチャは以下の2つの条件を満たす必要があります。

下位互換性: 既存のDNSプロトコルやアプリケーションプロトコルと互換性を持ち、既存のインターネットインフラがそのまま使えること
国際性: 地域や国に特有な情報に依存せず、既存の国際標準を利用してドメイン名の国際化に必要な共通の枠組みとすること

　国際化ドメイン名のアーキテクチャは、IDNA(Internationalizing Domain Names in Applications)方式の採用が合意されました。 IDNAは、上記の条件を満たすものであり、以下を規定しています。

国際化ドメイン名が使用する文字セットは、プロトコル内部では国際的な標準でありASCIIと上位互換のUnicodeとする
複数の表現形態(大文字/小文字、全角/半角、合成文字との連結など)を持つ文字の使用により、一つの国際化ドメイン名が複数の表現形態を持って照合に失敗することがないよう、国際化ドメイン名は必ず正規化する
利用者が入力や参照する非ASCII文字で表現された国際化ドメイン名は、ネットワーク上ではASCII文字のみを使用した互換形式(ASCII Compatible Encoding; ACE)で表現する
文字セットの変換、正規化、ACEへの変換はアプリケーションプログラムで行う

正規化

　アルファベットの大文字・小文字のように、一つの文字でも複数の表現形態を持つものが存在します。ドメイン名はアルファベットの大文字・小文字を区別せず同一の文字として扱うことが規定されています。

　国際化ドメイン名はアルファベット以外の文字も使用可能にしますので、アルファベットと同様に一つの文字が複数の表現形態を持つ他の文字についても、それらが同一の文字として扱われるかについての規定が必要であり、その規定に従った文字(列)の変換を正規化と呼んでいます。正規化が行われないと、利用者から見て同一の国際化ドメイン名であっても、アプリケーションプログラム内では異なる文字列となって照合に失敗することがあるため、利用者にとって不利益を生じる危険性があります。

　国際化ドメイン名の正規化は、NAMEPREP(Stringprep Profile for Internationalized Host Names、以前はPreparation of Internationalized Host Namesと呼ばれていた)方式の採用が合意されました。 NAMEPREPは以下を規定しています。

map: NAMEPREPの最初の処理で、大文字・小文字などの文字種を統一する。mapのルールはUnicodeの規定に従う
normalize: mapの次の処理で、濁点などの文字の合成を行ったり、全角・半角などの互換文字を統一する。normalizeのルールはUnicodeの規定に従う
prohibit: normalizeの次の処理で、ドメイン名として使用するのには不適切なスペースなどの文字やコントロール文字の有無をチェックし、あればエラーとする

ACE

　国際化ドメイン名はASCII以外の文字も使用してドメイン名を表現するものですが、ドメイン名を扱う既存のアプリケーションプログラムやサーバはドメイン名としてASCII文字しか扱うことはできません。

　それらすべてのソフトウェアを国際化ドメイン名対応にし、さらに普及させるためにはたいへん多くの労力と時間を必要としますので、既存のソフトウェアとの互換性が保て、 ASCII以外の文字をASCII文字のみを使用して表現する互換形式(ACE)が検討されてきました。

　国際化ドメイン名のACEは、 AMC-ACE-Z(AMC-ACE-Z version 0.3.1)の採用が合意されました。 AMC-ACE-Zの特徴は以下の通りです。

多くの文字数を持つアジア系の言語でも変換効率が良い(表現可能な文字数が多い)
アルゴリズムが比較的簡単
実装が簡単

※AMC-ACE-ZはAdam M Costello氏が考案した26番目(アルファベットではZの位置)のACEという意味で、これまでこの方式の正式名称はありませんでしたが、先ごろAMC氏からアナウンスがあり正式名称はPunycodeになる見込みです。

今後の作業

　上記のアーキテクチャ(IDNA)、正規化(NAMEPREP)、ACE(AMC-ACE-Z)の提案について、提案者による若干の修正を受けたあとWG Last Callと呼ばれる1週間程度の最終確認期間を経て、数週間以内(2002年1月中旬までをめど)に順次WGの最終案としてまとめられることになります。まとまり次第各提案はIESG (Internet Engineering Steering Group)に送られ、 IESGのレビューを経てProposed Standard RFC化されることになります。

2002年2月1日補足:
IDNA、NAMEPREP、ACEのLast Callが2002年1月28日にかかりました。