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

JPNICはインターネットの円滑な運営を支えるための組織です

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索

2003年2月14日

IESGが国際化ドメイン名(IDN)の運用に関する声明を発表

 2002年2月11日、インターネットの標準作成に重要な権限を持つInternet Engineering Steering Group(IESG)が、 国際化ドメイン名(IDN)の運用に関する声明を発表しました。

 この声明では、IDNの技術仕様を規定するRFCの発行に先立ち、 技術標準では対応しきれないIDNの運用上の注意点について喚起しています。

 以下にJPNICによる、声明文の和訳を掲載します。原文はIESG Statement on IDN(11 Feb 2003)http://www1.ietf.org/mail-archive/ietf-announce/Current/msg22545.htmlです。


IDNに関するIESGからの声明:

 IDNAは、Unicode文字集合に含まれる文字のエンコーディングを規定しています。 このエンコーディングは、現行のホスト名の規定と互換性を持つものです。 これはすなわち、IDNAに従ってエンコードされたドメイン名は、 既存のプロトコル(DNSプロトコルを含む)を使って通信ができるということを意味しています。

 IDNAは、Nameprepの要件を満たすために、 「文字の持つ性質」のみに基づいた等価テーブルを使用します。 そこでは、ドメイン名で使用されている「意図された言語」 (もしそれがあるならば)に対する注意は全く払われていません。 しかしながら、多くのドメイン名において、 その一部もしくは大部分が「意図された言語」 であることはユーザーにとって実際に重要なことです。

 同様に、多くのドメイン名は、 そこで使われている「文字」がどの「言語の文字」なのかがわからなければ、 明瞭な形で表示したり使用したりすることはできません。 どちらのケースにおいても、この追加的な情報は、 レジストリが関心を持つべきものであると思われます。

 もしドメイン名をゾーンに登録するに当たって何の制約も無いのであれば、 人々は誤解やサイバースクワッティングやその他の様々な混乱のリスクを増やすような文字の組み合わせで登録をすることができます。 IDNAの導入の前にもこれに少し似た状況が実際にありました。 例えば、example.comとexamp1e.comというようなドメイン名のケースです。 (後者は、"L"という文字の代わりに数字の"1"を使っています。)

 人間が使ういくつかの言語においては、 等価または等価に近い意味を持つ文字列が存在します。 誰かがそのような文字列を含むドメイン名を登録した場合、 レジストリは、意味的にまたは表示上等価である文字列の一覧を自動的に生成し、 それらも合わせて登録するよう提示するような仕組みを望んでいるかもしれません。 さらに、レジストリの中には、「言語」という観点からの理由で、 特定の文字を使わせないようにすることを望んでいるかもしれません。

 いくつかのレジストリ、特にgTLDレジストリは、当然のことながら、 特定の言語グループに含まれるという位置づけにはなっていません。 このようなケースにおいては、そこで使われる可能性のある言語について、 受け入れることのできない問題を発生させないよう特別な注意が払われる必要があります。

 IDNAベースのドメイン名の受付を開始するに当たって、 レジストリは保守的な態度をもって行動することを提案します。 登録が開始された後から「等価」を規定することは (不可能ではないにしても)非常に困難なことです。 "x"というラベルと"y"というラベルが最初は異なるものとされ、 後からレジストリが使うテーブルが変更されて、 "x"と"y"が同じものとして扱われるようになる状況を想像してみてください。 x.example.comとy.example.comが、 すでに違う登録者に対して登録されているとしたら、 2人のうちのどちらが登録を取り下げなければならないのか、また、 それを選ぶプロセスはどのようにして行われるべきかなど明確ではありません。 このようなことがあるため、登録を受け付ける前に、 完全かつ一般に公開されたポリシーを作ることによって、 より安定した登録プロセスへと進むことができると思われます。

 IDNAベースのドメイン名を扱うに際して私達が困難であると考える問題は他にもあります。 例えば、 「表示のための形式」と「通信のための形式」との間の変換をいつ行うべきか、 Unicode 3.2の一部しかサポートしていないシステムで 「表示のための形式」をどのように扱うべきか、 ドメイン名がプロトコルまたはユーザーの期待とは逆の形式で現れた場合の問題をどのように解決すべきか、 などです。 これらの問題は、ほとんどがIDNA標準の範疇の外にあるものです。 しかし、製品にIDNA標準を実装しようとするすべての者にとって、 これらの問題は関心の的です。 さらに多くの事例についてはIDNAの仕様書を見てください。

 IDNAベースのドメイン名の 「表示のための形式」を他のプロトコルで使用することは、 まだいずれの標準にもなっていません。 IDNAベースのドメイン名を実装する人は、 「表示のための形式」すなわちUnicodeベースの国際的な文字/ グリフ(文字の形)の使用が許される形でプロトコルが変更され標準化されるまでは、 「通信のための形式」すなわち ASCII 文字にエンコードされたドメイン名を使うよう注意が促されています。

[IDNA]
"Internationalizing Domain Names in Applications (IDNA)"(draft-ietf-idn-idna)
[NAMEPREP]
"Nameprep: A Stringprep Profile for Internationalized Domain Names" (draft-ietf-idn-nameprep)
[UNICODE]
Unicode コンソーシアム。Unicode Standard, Version 3.2.0 は、『The Unicode Standard, Version 3.0』(書籍。MA, Addison-Wesley, 2000. ISBN 0-201-61633-5)に規定されており、Unicode Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/) および Unicode Standard Annex #28: Unicode 3.2 (http://www.unicode.org/reports/tr28/)による修正を反映。

以上

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

このWebページは役に立ちましたか?
よろしければ回答の理由をご記入ください

それ以外にも、ページの改良点等がございましたら自由にご記入ください。

回答が必要な場合は、お問い合わせ先をご利用ください。

ロゴ:JPNIC

Copyright© 1996-2024 Japan Network Information Center. All Rights Reserved.