ネットワークワーキンググループ                              P. Faltstrom
Request for Comments: 3490                                         Cisco
分類: 標準化過程(Standards Track)                             P. Hoffman
                                                              IMC & VPNC
                                                             A. Costello
                                                             UC Berkeley
                                                               2003年3月


               アプリケーションにおけるドメイン名の国際化
         (IDNA: Internationalizing Domain Names in Applications)

本文書の位置づけ

   本文書はインターネットコミュニティーのためにインターネット標準化過程に
   あるプロトコルを規定し、その向上のために議論と提案を求めるものである。
   このプロトコルの標準化の状況については"Internet Official Protocol 
   Standards"(STD 1)の最新版を参照のこと。本文書の配布は制限されない。

著作権表示

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

要旨

   ASCIIの範囲外の文字をドメイン名で使用するための標準化された方法は、
   これまでのところ存在しなかった。本文書は国際化ドメイン名(IDN)と、
   それを標準化された方法で処理するIDNA(Internationalizing Domain Names
   in Applications)と呼ばれる仕組みを定義する。IDNは広大な範囲(Unicode)
   から得られる文字を使用するが、IDNAはいわゆるホスト名で現在既に使用が
   認められているASCII文字だけを使用して、これらの非ASCII文字
   (non-ASCII characters)を表現することを可能にするものである。
   この後方互換な表現は既存のDNSのようなプロトコルが必要とするもので、
   これを使用することにより、既存のインフラを変更することなく、IDNを
   導入可能となる。IDNAはドメイン名を処理するためだけのものであり、
   一般的な文章を処理するものではない。

目次

    1. はじめに......................................................  2
       1.1 問題の記述................................................  3
       1.2 IDNAの制限................................................  3
       1.3 アプリケーション開発者向けの簡潔な概要....................  4
    2. 用語..........................................................  5
    3. IDNAの要件と適用可能な範囲....................................  7
       3.1 IDNAの要件................................................  7
       3.2 IDNAが適用可能な範囲......................................  8
          3.2.1. DNSリソースレコード.................................  8



Faltstrom, et al.           Standards Track                     [Page 1]

RFC 3490                          IDNA                        March 2003


          3.2.2. ドメイン名内に保存される、ドメイン名以外の
                 データタイプ........................................  9
    4. 変換処理......................................................  9
       4.1 ToASCII処理............................................... 10
       4.2 ToUnicode処理............................................. 11
    5. ACEプレフィックス............................................. 12
    6. DNSを使用する典型的なアプリケーションへの影響................. 13
       6.1 アプリケーションへの入力と表示............................ 14
       6.2 アプリケーションとリゾルバーライブラリー.................. 15
       6.3 DNSサーバー............................................... 15
       6.4 ユーザーへの素(raw)のACEエンコーディング表示の回避........ 16
       6.5  IDNドメイン名のDNSSEC認証................................ 16
    7. ネームサーバーに関する考察.................................... 17
    8. ルートサーバーに関する考察.................................... 17
    9. 参考文献...................................................... 18
       9.1 必須の参考文献............................................ 18
       9.2 有用な参考文献............................................ 18
   10. セキュリティーに関する考察.................................... 19
   11. IANAに関する考察.............................................. 20
   12. 著者の連絡先.................................................. 21
   13. 完全な著作権表示.............................................. 22

1. はじめに

   IDNAは、アプリケーションが非ASCIIラベルを表現するために、
   (特別なプレフィックス(prefix)で始まる)ASCIIラベル(name label)を使用
   できるようにすることによって動作する。下位層のプロトコルはこれを
   意識しなくてもよい。したがって、IDNAはどのようなインフラの変更も
   必要としない。特に、IDNAはDNSサーバー、リゾルバー、プロトコルを構成する
   要素等の変更を一切必要としない。既存のDNSが提供するASCIIの名前サービスは
   IDNAにとって充分なものだからである。

   本文書はアプリケーションに対してIDNAに準拠することを要求しない。
   しかし、アプリケーションはIDNをサポートするために、既存のインフラとの
   相互運用性を維持する間、IDNAの使用を選択することができる。
   アプリケーションがドメイン名に非ASCII文字を使用したいと望む場合、
   IDNAが現在定義されている唯一の選択肢である。既存のアプリケーションに
   IDNAサポートを追加するためには、そのアプリケーションだけを変更すれば
   よい。また、ユーザーインターフェースについては自由度が残される。

   IDNという問題解決法に関する膨大な量の議論は、移行の問題と、全ての
   構成要素が更新されていない状況で、IDNが全世界でどのように動作するのか
   ということに焦点が絞られていた。ユーザーが国際化ドメイン名を使用できる
   ようにするために、ユーザーアプリケーション、リゾルバー、DNSサーバーの
   更新を必要とするという提案を、IDNワーキンググループは採択しなかった。
   IDNAは広範囲で使用されている全構成要素の更新を必要とするよりは、
   ユーザーアプリケーションの更新だけを必要とする形態を選択した。
   したがって、DNSプロトコルやユーザーの使用するコンピューター上で動作する
   DNSサーバーやリゾルバーは一切の変更を必要としない。



Faltstrom, et al.           Standards Track                     [Page 2]

RFC 3490                          IDNA                        March 2003


1.1 問題の記述

   IDNA仕様は、ドメイン名で使用できる文字の範囲をUnicodeの範囲を含むように
   拡張するという問題を(若干の制限付きで)解決する。

   IDNAはDNSがアプリケーションに提供するサービスを拡張しない。
   代わりに、アプリケーション(つまりユーザー)がこれまでどおり完全一致
   (exact-match)の検索サービスに対応する。この場合、得られる結果は
   完全一致した単一の名前が存在したか、一致する名前が存在しなかったかの
   どちらかとなる。このモデルは既存のアプリケーションに役立ってきたが、
   このモデルは国際化ドメイン名の有無にかかわらず、ユーザーがドメイン名の
   完全な綴りを知っており、それをWebブラウザーやメールユーザーエージェントに
   入力することを必要とする。より広い範囲の文字を導入することにより、
   綴り間違いが発生する可能性が大きくなる。特に、幾つかの事例では同じように
   見えても違うものがあるかもしれない。例えば、名刺に書かれた文字は、
   幾つかのUnicodeコードポイントや幾つかのコードポイントの並びと見かけは
   一致するかもしれない。

   IDNAはIDNの円滑な導入を可能にする。それは単に既存のインフラ(DNSサーバーや
   メール転送エージェントのような)の更新を回避するだけではなく、非ASCII
   ラベルをASCII文字で表現することにより、アプリケーションでIDNを
   原始的に使用(*1)することを可能にしている。そのような名前はユーザーには
   非常に読みにくく、また入力もしにくいものである。したがって、ユーザー
   自らが入力するには適していない。しかし、この仕組みにより、(例えば)
   表示されたドメイン名がユーザーに理解できないものであるとしても、
   電子メールに返信したり、URLをクリックしたりすることを可能とする。
   親和性の高いIDNの入力、出力を可能にするために、アプリケーションは
   この仕様に準拠するような修正を必要とする。


《脚注》
   *1: 「IDNの原始的な使用」
      あるアプリケーションがIDNに対応していないとしても、例えば本来
      "http://日本語ドメイン名協会.jp/"と入力すべきところを
      "http://xn--eckwd4c7cz44rqkf8kb898fdocu19k.jp"と入力すれば、
      同じ結果が得られることを指している。


   IDNAはUnicodeの文字範囲を使用する。これは他の標準化組織によって
   Unicodeとは別にIDN用の特別な文字集合が定義されるのを待つという
   大きな遅れを回避するためのものである。

1.2 IDNAの制限

   IDNAプロトコルは、ユーザーがそれぞれ異なる用字(言語を表現するために
   用いられる文字)を使用して名前を入力するという語学上の問題を全て
   解決するわけではない。IDNAは重要な多くの言語または用字に基づいた
   変換を行わないため、それらの処理はプロトコル外で行われる必要がある。
   例えば、中国語の繁体字と簡体字が混在したものは単一の正規名には
   変換されない。他の例として、U+00F6(ö)を含むスカンジナビア語の名前は
   U+00F8(ø)には変換されない。




Faltstrom, et al.           Standards Track                     [Page 3]

RFC 3490                          IDNA                        March 2003


   IDNAで細かく考慮されていない重要な問題の例として、視覚的な情報
   (名刺や掲示板から得られた情報のようなもの)や聴覚的な情報(電話や
   ラジオから得られた情報のようなもの)に基づいてドメイン名を入力する
   ユーザーが、正しくIDNを入力する確率をどのように高めるかということが
   挙げられる。同様の問題はASCII文字のドメイン名でも存在する。例えば、
   アルファベットのオー(O)と数字のゼロ(0)を視覚的に混同するというものが
   ある。しかし、より広い範囲の文字を導入することにより、同じように
   見えたり同じように聞こえたりすることによる混同の機会が増える。
   この問題は、言語や、コンピュータ上での文字入力方法(imput method)に
   関係する複雑な問題であることに注意してもらいたい。更に、ユーザーが期待する
   検索結果が得られる確率を上げるために必要な一致処理と検索処理の性質は、
   DNSの役割とDNSが使用する完全一致機能には適合しないだろう。

1.3 アプリケーション開発者向けの簡潔な概要

   アプリケーションは、DNSマスターファイルとリゾルバーインターフェースを
   初めとして、ASCIIドメイン名が既にサポートされているものなら何でも、
   IDNAを使用して国際化ドメイン名をサポートすることができる。
   (アプリケーションは非ASCII表現を直接使用してIDNをサポートする
   プロトコルとインターフェースを定義することもできる。IDNAは新しい
   プロトコル用の固有の表現を何も規定しないが、有効(valid)な名前とは
   どのようなものかということと、その名前がどのように比較されるのかに
   ついては定義している)。

   IDNAプロトコルは、その全てがアプリケーションに含まれる。このプロトコルは
   クライアント-サーバー型やピアーツーピアー型のプロトコルではない。
   全ての処理はアプリケーションそのものの中で行われる。
   DNSリゾルバーライブラリーと共に使用される場合、IDNAはアプリケーションと
   リゾルバーライブラリーの間に"shim(*2)"として挿入される。DNSゾーンへの
   名前の書き込みに使用される場合、IDNAは名前をゾーンに書き込む直前に
   使用される。


《脚注》
  *2: 「shim」
      隙間に入れられる詰め木の意味。ここでは、アプリケーションの処理と
      リゾルバーの処理の間にIDNA関連処理が挿入されることを意味する。

   本文書のセクション4で、以下の2つの処理を述する。

   -  ToASCII処理は、ASCII名を期待する何か(例えばリゾルバー)にIDNを
      送信する前またはASCII名を期待する場所(例えばDNSマスターファイル)に
      IDNを書き込む前に使用される。

   -  ToUnicode処理は名前をユーザーに表示する前、例えばDNSゾーンから
      得られた名前を表示する前に使用される。

   ToASCII処理が失敗する可能性に注意することは重要である。ドメイン名処理中に
   処理が失敗した場合、そのドメイン名は国際化ドメイン名としては使用できない
   ため、アプリケーションはこの失敗を処理する何らかの方法を持たなければ
   ならない。

   IDNAは、実装に対し入力された文字列を、Nameprep[NAMEPREP]というStringprep
   [STRINGPREP]の具体的な適用法の定義(profile)で処理し、その後Punycode
   [PUNYCODE]で処理することを要求する。


Faltstrom, et al.           Standards Track                     [Page 4]

RFC 3490                          IDNA                        March 2003


   IDNA実装はNameprepとPunycodeを両方とも完全に実装しなければならない(MUST)。
   NameprepまたはPunycodeどちらかの実装が任意というわけではない。

2. 用語

   本文書におけるキーワード"しなければならない(MUST)"、"するものとする
   (SHALL)"、"要求される(REQUIRED)"、"推奨される(RECOMMENDED)"、
   "してもよい(MAY)"は、BCP14、RFC2119[RFC2119]に記述されているとおりに
   解釈される。

   コードポイントは符号化文字集合(coded character set)において、
   文字に関連付けられる整数の値である。

   Unicode[UNICODE]は数万の文字を含む符号化文字集合である。一つのUnicode
   コードポイントは、"U+"に4桁の16進数が続く形式で記述される。一方で
   Unicodeコードポイントの範囲を記述する場合は、プレフィックス無しで
   2桁の16進数を".."で分割した表現形式を使用する。

   ASCIIはUS-ASCII[USASCII]を意味する。128文字を含む符号化文字集合で、
   関連するコードポイントは0..7Fの範囲に収まる。UnicodeはASCIIを拡張した
   ものである。Unicodeは全てのASCII文字を含み、同じコードポイントを関連
   付けている。

   "LDHコードポイント"という用語は本文書で定義されるもので、ASCII英字、
   数字、ハイフン(マイナス)記号に関連づけられたコードポイントを意味する。
   これらはU+002D、30..39、41..5A、61..7Aに相当する。"LDH"は、
   "英字(letter)、数字(digit)、ハイフン(hyphen)"を短縮したものである。

   [STD13]は"ドメイン名"と"ホスト名"について論じているが、多くの人々は
   この2つの用語を等価なものとして使用している。更に、[STD13]が大変曖昧な
   ものであったため、これらの用語の正確な定義を知っていると信じている
   多くの人々の間でも、定義についての意見が一致しない。本文書では、
   "ドメイン名"という用語は一般的な意味として使用する。一方で、本文書に
   おいてホスト名の文法制限について言及する際には、その制限を定義している
   [STD3]を常に明示的に引用する。

   ラベルはドメイン名を構成する個々の部分である。ラベルは通常、ドットに
   よって分割されて示される。例えば、ドメイン名"www.example.com"は
   3つのラベル"www"、"example"、"com"から構成される。([STD13]では、長さ0の
   rootラベルについての記載がある。これは明示的に"www.example.com."と記述
   することもできるし、"www.example.com"のように暗に示すこともできるもの
   だが、本仕様ではこれをラベルとしては扱わない)。IDNAは文字列である
   ラベルの中で、使用可能な文字のセットを拡張する。以下、本文書において
   "ラベル"という用語は"文字列ラベル"の簡略化表記であり、"各ラベル"は
   "各文字列ラベル"を意味するものとする。






Faltstrom, et al.           Standards Track                     [Page 5]

RFC 3490                          IDNA                        March 2003


   "国際化ラベル"はToASCII処理(セクション4参照)を(UseSTD3ASCIIRulesフラグを
   設定しない状態で)失敗せずに適用可能なラベルである。これは、[STD13]の
   長さに関する制限を満たす全てのASCIIラベルは国際化ラベルであることを
   意味する。したがって、"国際化ラベル"という用語は、旧来のASCIIラベルと
   新しい非ASCIIラベル両方を包括し、一般化したものであると言える。
   ほとんどのUnicode文字を国際化ラベルで使用することができるものの、
   ToASCII処理は幾つかの入力文字列に対しては失敗する。そのような文字列は
   有効な国際化ラベルではない。

   "国際化ドメイン名(IDN)"は、各ラベルが国際化ラベルで構成されたドメイン名
   である。これは、全てのASCIIドメイン名はIDNであることを意味する。
   (そして、ある名前が非ASCII文字を含んでいなくてもIDNになり得ることも
   意味している)。本文書は"国際化ホスト名"を定義しようと試みるものではない。
   ちょうどASCII名の事例がそうであるように、DNS管理者は、彼らが管理する
   ゾーンに登録可能な文字または文字列について、DNSまたはIDNAで課せられる
   制約に加えて、付加的な制約を課してもよい。そのような制約は、DNSプロトコル
   メッセージの文法または意味に何も影響を及ぼさない。ある問い合わせに対して
   一致するレコードが存在しない場合、ゾーン内に一致するレコードが存在しない
   理由に関わらず、同じ応答が生成されるからである。問い合わせを発行したり
   応答を解釈したりするクライアントが、ゾーン固有の制限や仕様について
   何らかの知識を持つと想定することはできない。

   IDNAでは、ToASCII処理の観点からラベルが等価であるということが定義される。
   ToASCII処理は、与えられたラベルに対して、そのラベルが既にASCIIラベルか
   どうかに関わらず、ASCII形式の出力を構成する。ラベルは、ToASCII処理が
   生成したASCII形式の出力が、大文字と小文字を区別しないASCII比較で
   一致する場合に等価であると定義される。ASCIIラベルは既に等価という概念を
   持っている。大文字と小文字は等価であると考えられる。IDNAにおける
   等価という概念は、この旧来の概念を拡張したものである。IDNAにおける
   等価なラベルは、同じラベルが二つの形式を持つものとして処理される。
   ちょうど"foo"と"Foo"が同じラベルの二つの形式として処理されるのと
   同じである。

   国際化ラベルを既存のアプリケーションで処理することができるように、
   IDNAは"ACEラベル"を使用する(ACEはASCII Compatible Encoding(ASCII互換の
   エンコーディング)を略したものである)。ACEラベルはASCII文字で表現可能な
   国際化ラベルであり、ASCII文字では表現できない国際化ラベルと等価なもの
   である。ToASCII処理は任意のASCII文字で表現できない国際化ラベルを
   等価なACEラベルに変換する(ASCIIラベルはToASCII処理によって
   変換されないまま残される)。ACEラベルはユーザーに表示するには不向き
   である。ToUnicode処理は、ラベルを等価な非ACEラベル(non-ACE label)に
   変換する。実際、正式なACEラベルの定義は、ToUnicode処理によって
   変換可能なラベル(ただし非ACEラベルはToUnicode処理によって変換されないまま
   残される)となる。


Faltstrom, et al.           Standards Track                     [Page 6]

RFC 3490                          IDNA                        March 2003


   全てのACEラベルは、セクション5で規定されるACEプレフィックスから
   開始される。ToASCII処理とToUnicode処理は、セクション4で規定される。

   本文書における"ACEプレフィックス"の定義は、全ACEラベルの先頭に存在する
   ASCII文字列である。これはセクション5で規定される。

   本文書における"ドメイン名スロット"の定義は、明示的にドメイン名を
   運ぶために指定されたプロトコル要素、関数の引数、返り値等である。
   ドメイン名スロットの例として、DNSの問い合わせのQNAMEフィールド、
   gethostbyname()ライブラリー関数の引数name、電子メールメッセージ
   ヘッダーのFrom:フィールドに含まれる電子メールアドレスの一部で、
   アットマーク(@)以降の部分、HTMLの<IMG>タグのsrc属性に含まれる
   URIのホスト部分等が挙げられる。ドメイン名をたまたま含んでいる
   一般的な文章はドメイン名スロットではない。例えば、電子メール
   メッセージの平常文(plain text)で書かれた本文の中にドメイン名が
   あったとしても、それはドメイン名スロットではない。

   本文書における"IDN対応ドメイン名スロット"の定義は、本文書で定義される
   国際化ドメイン名を運ぶと明示的に指定されたドメイン名スロットである。
   この指定は静的な場合(例えばプロトコルまたはインターフェースの仕様に
   よって指定される)または動的な場合(例えば対話型セッションにおける
   交渉(negotiation)の結果指定される)がある。

   本文書における"IDN非対応ドメイン名スロット"の定義は、IDN対応ドメイン名
   スロットではない全てのドメイン名スロットである。この定義は明らかに
   IDNA以前に規定されたドメイン名スロット全てを含む。

3. IDNAの要件と適用可能な範囲

3.1 IDNAの要件

   IDNA準拠であるとは、以下の4つの要件に忠実にしたがうことを意味する。

   1) ラベルの区切り文字としてドットを使用する場合、U+002E(ピリオド".")、
      U+3002(句点"。")、U+FF0E(全角ピリオド".")、U+FF61(半角句点"。")は
      ドットとして扱わなければならない(MUST)。

   2) ドメイン名がIDN非対応のドメイン名スロットに入れられる場合(セクション2
      参照)、ドメイン名はASCII文字だけで構成されなければならない(MUST)。
      任意の国際化ドメイン名(IDN)に対して、等価でかつこの用件を満たす
      ドメイン名は、各ラベルに対してToASCII処理(セクション4参照)を適用し、
      またドットがラベルの区切り文字として使用されている場合には、
      それをU+002Eに変換することによって得られる。


Faltstrom, et al.           Standards Track                     [Page 7]

RFC 3490                          IDNA                        March 2003


   3) ユーザーの環境が非ACE形式のラベルを処理できることがわかっている場合、
      明示的にACE形式のラベルが要求された場合を除き、ドメイン名スロットから
      得られたACEラベルはユーザーから隠されるべきである(SHOULD)。
      ユーザーの環境が非ACE形式のラベルを処理できるかどうかが不明な場合、
      アプリケーションは非ACE形式を使用してもよい(MAY)(ただし、正しく
      表示されないなど、失敗するかもしれない)。あるいは、ACE形式を
      使用してもよい(ユーザーはその文字列が何を意味するのか理解できない
      だろうけれども)。任意の国際化ドメイン名に対して、等価でかつ非ACEラベルを
      含むドメイン名は、各ラベルに対してToUnicode処理(セクション4参照)を
      適用することによって得られる。要件2と要件3が共に適用される場合は
      要件2が優先される。

   4) 2つのラベルが比較される場合、2つのラベルが等価な場合にだけ一致したと
      みなされなければならない(MUST)。すなわち、(それぞれのラベルにToASCII
      処理を適用することによって得られた)ASCII形式のラベルが大文字と小文字を
      区別しないASCII比較で一致するということである。2つの名前が比較される
      場合、それぞれが使用しているラベルの区切り文字が同じかどうかに
      関わらず、対応するラベルが一致した場合にだけ一致したとみなされなければ
      ならない(MUST)。

3.2 IDNAが適用可能な範囲

   IDNAは明示的にIDNAを除外している場合を除き、全てのドメイン名スロットに
   含まれる全てのドメイン名に適用可能である。

   これは、IDNA開発以前から存在する多くのプロトコルに対しても、IDNAは
   適用可能であることを意味する。これらのプロトコルのドメイン名スロットに
   入れられるIDNはASCII形式でなければならない(MUST)ことに注意して
   もらいたい(セクション3.1の要件2参照)。

3.2.1. DNSリソースレコード

   IDNAは、クラスがINでないDNSリソースレコードのNAMEフィールドとRDATA
   フィールドに含まれるドメイン名に対しては適用されない。この除外規則は、
   現在および未来における全ての非INクラスに適用される。ただし、将来の
   標準がIDNAの使用を明示的に促すことにより、この除外規則を無効にする
   場合はその限りではない。

   IDNAをDNSリソースレコードに適用する対象範囲に関して、これ以外の除外規則は
   現在存在しない。これは完全にクラスに依存するものであり、タイプに依存する
   ものではない。将来において新しいタイプが定義されるとしても、その新しい
   タイプに固有のルールを付加して問題を複雑にせざるを得ない理由が無い限りは、
   IDNAの適用対象範囲がタイプに依存しないということは将来においても変わらず
   正しい。





Faltstrom, et al.           Standards Track                     [Page 8]

RFC 3490                          IDNA                        March 2003


3.2.2. ドメイン名内に保存される、ドメイン名以外のデータタイプ

   IDNAはドメイン名を非ASCII文字で表現可能にするが、これはIDNAが
   ドメイン名内に保存される他のデータタイプで非ASCII表現を可能にすることを
   意味するものではない。例えば、電子メールアドレスのローカル部分(*3)は
   時々ドメインラベル内に保存される(hostmaster@example.comは、SOAレコードの
   RDATAフィールドではhostmaster.example.comと表現される)。IDNAは、
   ローカル部分ではASCII文字だけしか使用を認めていない既存の電子メール
   標準を更新しない。したがって、電子メール標準が改訂され、ローカル部分で
   IDNAの使用が促されない限り、電子メールアドレスのローカル部分を持つ
   ドメインラベルはACEプレフィックスから開始されるべきではない(SHOULD NOT)。
   仮にACEプレフィックスから開始されたとしても、それはたまたまACE
   プレフィックスと同じ文字列で開始されたローカル部分であるとして
   そのままの文字として解釈される。


《脚注》
  *3: 「電子メールアドレスのローカル部分」
      メールアドレスの"@"の左側部分。hostmaster@example.comの場合は
      hostmasterがローカル部分となる。

4. 変換処理

   アプリケーションは、IDN非対応スロットにドメイン名を入れる場合あるいは
   ユーザーにドメイン名を表示する場合、ドメイン名を変換する。本セクションは
   変換を行うために実行されるべき処理段階と、ToASCII処理とToUnicode処理に
   ついて規定する。

   ToASCII処理またはToUnicode処理への入力は単一のラベルであり、これは
   Unicodeコードポイントの並びである(全てのASCIIコードポイントは
   同時にUnicodeコードポイントでもあることを思い出してもらいたい)。
   ドメイン名がUnicodeまたはUS-ASCII以外の文字集合で表現されている場合、
   まずUnicodeにコード変換(transcode)する必要がある。

   ドメイン名全体から処理を開始する。アプリケーションが変換を行う処理手順は
   以下の通りである。

   1) [STRINGPREP]で記述されているように、ドメイン名が"保存文字列
      (stored string)"か"問い合わせ文字列(query string)"であるかを
      判定する。この変換が"問い合わせ(queries)"ルールにしたがう場合、
      "AllowUnassigned"と呼ばれるフラグを設定する。

   2) セクション3.1に記述されているように、ドメイン名を個々のラベルへと
      分割する。ラベルは区切り文字を含まない。

   3) 各ラベルについて、ホスト名で使用可能なASCII文字に関する制限[STD3]を
      適用するかどうかを決定する。(アプリケーションはIDNAの導入以前に
      この選択に直面しているので、これまでと同じ決定方法を使い続けることも
      できる。IDNAはこの選択に関して何も推奨しない)。制約を適用する場合、
      ラベルに対して"UseSTD3ASCIIRules"と呼ばれるフラグが設定される。





Faltstrom, et al.           Standards Track                     [Page 9]

RFC 3490                          IDNA                        March 2003


   4) 各ラベルを必要に応じてToASCIIかToUnicodeで処理する。典型的には
      IDN非対応スロットに名前を入れようとする場合にはToASCII処理を
      使用し、ユーザーに名前を表示する場合にはToUnicode処理を使用する。
      セクション3.1は適用可能な要件のより詳細な情報を与える。

   5) 処理段階4でToASCII処理が適用されており、ドットがラベルの区切り文字
      として使用されている場合、全てのラベル区切り文字をU+002E(ピリオド)
      に変換する。

   続くサブセクションは、処理段階4で使用されるToASCII処理とToUnicode処理を
   定義する。

   このプロトコルの記述では、プロトコルの規定を円滑に行うために、プロトコル
   固有の手続き名、フラグ名等を使用する。実装は、これらの手続き名を
   使用することも手続きの処理段階を実際に実行することも要求されない。
   事実上、この文書で規定される振る舞いを外部で実行させる実装は全て
   本仕様に適合していると言える。

4.1 ToASCII処理

   ToASCII処理は、1つのラベルを形成するUnicodeコードポイントの並びを
   取り込み、それをASCIIの範囲(0..7F)に収まるコードポイントの並びに
   変換する。ToASCII処理が成功すると、オリジナルのコードポイントの並びと
   結果として得られるコードポイントの並びは等価なラベルとなる。

   ToASCII処理は失敗する可能性があることに注意することは重要である。
   ToASCII処理は、処理段階のどれか1つでも失敗した場合には失敗する。
   ドメイン名に含まれるラベルに対してToASCII処理を適用し、その処理段階の
   どれか1つでも失敗した場合、そのドメイン名は国際化ドメイン名として
   使用されてはならない(MUST NOT)。この失敗を処理する方式はアプリケーション
   固有である。

   ToASCII処理への入力は、コードポイントの並び、AllowUnassignedフラグ、
   UseSTD3ASCIIRulesフラグである。ToASCII処理の出力は、ASCIIコード
   ポイントの並びか、失敗条件のどちらかである。

   ToASCII処理は、コードポイントの並びが全てASCIIの範囲に収まるものを
   決して変更しない(失敗することはあるが)。ToASCII処理を複数回適用しても
   一度だけ適用した場合と効果は全く同じである。

   ToASCII処理は、以下の処理段階から構成される。

   1. コードポイントの並びがASCIIの範囲(0..7F)外にあるものを含む場合、
      処理段階2に進む。そうでない場合は処理段階3にスキップする。




Faltstrom, et al.           Standards Track                    [Page 10]

RFC 3490                          IDNA                        March 2003


   2. [NAMEPREP]で規定される処理段階を実行し、エラーが発生した場合は失敗と
      する。AllowUnassignedフラグは[NAMEPREP]で使用される。

   3. UseSTDASCIIRulesフラグが設定されている場合、以下の検査を行う。

     (a) 非LDH ASCIIコードポイントが存在しないことを確認する。これはすなわち、
         0..2C、2E..2F、3A..40、5B..60、7B..7Fが存在しないことを確認する作業
         である。

     (b) 入力されたコードポイントの並びの先頭と末尾にハイフン(マイナス)
         記号が存在しないことを確認する。これはすなわち、コードポイントの
         並びの開始部分と終了部分にU+002Dが存在しないことを確認する
         作業である。

   4. コードポイントの並びがASCIIの範囲(0..7F)外のものを含む場合、
      処理段階5に進む。そうでない場合は処理段階8にスキップする。

   5. 入力されたコードポイントの並びがACEプレフィックスで開始されて
      "いない"ことを確認する。

   6. 入力されたコードポイントの並びを、[PUNYCODE]で規定される
      エンコーディングアルゴリズムによってエンコードする。エラーが発生した
      場合は失敗とする。

   7. 先頭にACEプレフィックスを追加する。

   8. 変換して得られたコードポイントの数が1〜63の範囲内に収まっていることを
      確認する。

4.2 ToUnicode処理

   ToUnicode処理は、1つのラベルを形成するUnicodeコードポイントの並びを
   取り込み、Unicodeコードポイントの並びを返す。入力されたコードポイントの
   並びがACE形式のラベルである場合、処理結果はACE形式でない等価な
   国際化ラベルになる。入力形式がACE形式でない場合、オリジナルの
   コードポイントの並びは変更されずに返される。

   ToUnicode処理は決して失敗しない。どの処理段階であろうと失敗した場合は
   その処理段階の途中でオリジナルのコードポイントの並びが返される。

   ToUnicode処理の出力は、入力された以上の数のコードポイントを含まない。
   コードポイントを表現するために必要なオクテット数は、使用される特定の
   文字エンコーディング依存であることに注意してもらいたい。

   ToUnicode処理への入力はコードポイントの並び、AllowUnassignedフラグ、
   UseSTD3ASCIIRulesフラグである。ToUnicode処理の出力は、常にUnicode
   コードポイントの並びである。

   1. 入力されたコードポイントの並び全てがASCIIの範囲(0..7F)に収まる場合、
      処理段階3にスキップする。





Faltstrom, et al.           Standards Track                    [Page 11]

RFC 3490                          IDNA                        March 2003


   2. [NAMEPREP]で規定される処理段階を実行し、エラーが発生した場合は失敗と
      する。(ここでToASCII処理の処理段階3も実行したとしても、その処理は
      ToUnicode処理全体の振る舞いに影響を与えるものではなく、また実行は
      必須でもない)。AllowUnassignedフラグは[NAMEPREP]で使用される。

   3. 入力されたコードポイントの並びがACEプレフィックスで開始されて
      いるかどうか確認し、コードポイントの並びのコピーを保存する。

   4. ACEプレフィックスを取り除く

   5. [PUNYCODE]で規定されるデコーディングアルゴリズムによってコードポイント
      の並びをデコードする。エラーが発生した場合は失敗とする。この処理段階の
      結果のコピーを保存する。

   6. ToASCII処理を適用する。

   7. 処理段階6の結果が処理段階3の保存されたコピーと大文字と小文字を
      区別しないASCII比較で一致するかを確認する。

   8. 処理段階5の保存されたコピーを返す。

5. ACEプレフィックス

   変換処理(セクション4)内で使用されたACEプレフィックスとは、2文字の
   ASCII英数字に2つのハイフン(マイナス)が続けられたものである。本文書以前に
   使用されていた"bl--"、"bq--"、"dq--"、"lq--"、"mq--"、"ra--"、"wq--"、
   "zq--"等のプレフィックスはどれも使用できない。ToASCII処理とToUnicode
   処理は、どちらもACEプレフィックスを大文字小文字問わず認識できなければ
   ならない(MUST)。

   IDNA用のACEプレフィックスは"xn--"または"xn"のどれかが大文字になったもの
   である。

   これは、ACEラベルが"xn--de-jg4avhby1noc0d"のようなものであり、そのうち
   "de-jg4avhby1noc0d"部分は[PUNYCODE]のエンコーディングの処理段階で生成
   されたことを意味する。

   全てのACEラベルはACEプレフィックスから開始されるが、ACEプレフィックスから
   開始される全てのラベルがACEラベルである必要はない。ACEプレフィックスから
   開始される非ACEラベルはユーザーを混乱させるので、DNSゾーン内での使用は
   認められるべきではない(SHOULD NOT)。











Faltstrom, et al.           Standards Track                    [Page 12]

RFC 3490                          IDNA                        March 2003


6. DNSを使用する典型的なアプリケーションへの影響

   IDNAでは、ユーザーの国際化ドメイン名入力や、国際化ドメイン名のユーザー向け
   表示に必要な処理はアプリケーションが実行する。また、ドメイン名を運ぶ
   DNSや他のプロトコルからの入出力の処理もアプリケーションが行う。

   これら一連の処理の構成要素と各処理間のインターフェースは、以下の
   ように図示できる。

                  +----------+
                  | ユーザー |
                  +----------+
                       ^
                       | 入力と表示: 局所的なインターフェース方式
                       | (ペン、キーボード、ディスプレイの表示等)
   +-------------------|-------------------------------+
   |                   v                               |
   |          +-----------------------------+          |
   |          |     アプリケーション        |          |
   |          | (ToASCII処理とToUnicode処理 |          |
   |          |  はここから呼ばれる)        |          |
   |          +-----------------------------+          |
   |                   ^        ^                      | エンドシステム
   |                   |        |                      |
   | リゾルバー呼び出し|        | アプリケーション固有 |
   |    (ACEラベル)    |        | のプロトコル         |
   |                   v        | (他のエンコーディング|
   |          +------------+    | を処理するために     |
   |          | リゾルバー |    | プロトコルが更新     |
   |          +------------+    | されない限り、ACE    |
   |                 ^          | ラベルが使用される)  |
   |                 |          |                      |
   +-----------------|----------|----------------------+
       DNSプロトコル |          |
         (ACEラベル) |          |
                     v          v
          +-------------+    +---------------------+
          | DNSサーバー |    | アプリケーション    |
          +-------------+    | サーバー            |
                             +---------------------+

   "アプリケーション"とラベル付けされた箱は、アプリケーションがドメイン名を
   ラベルに分割し、適切なフラグを設定し、ToASCII処理とToUniode処理を実行する
   場所である。これらについてはセクション4に記述される。







Faltstrom, et al.           Standards Track                    [Page 13]

RFC 3490                          IDNA                        March 2003


6.1 アプリケーションへの入力と表示

   アプリケーションは、アプリケーション開発者が望む任意の文字集合
   または複数の文字集合を受理することができる。また、任意の文字集合で
   ドメイン名を表示することができる。すなわち、IDNAプロトコルは、
   ユーザーとアプリケーション間のインターフェースには影響を与えない。

   IDNA対応アプリケーションは、二種類の形式で国際化ドメイン名を受理、表示
   することができる。利用可能な形式は、アプリケーションがサポートする
   国際化された文字集合とACEラベルである。表示されるACEラベルまたは
   入力されるACEラベルは、常にACEプレフィックスを含まなければならない(MUST)。
   アプリケーションはACEラベルの入力と表示を許容してもよい(MAY)。しかし、
   デバッグやセクション6.4で記述した表示制限への対応など、特別な目的の
   インターフェース以外への使用は推奨されない。ACEエンコーディングは
   わかりにくく醜いので、どうしても必要とするユーザーにだけ提示されるべき
   である。ACEラベルとしてエンコードされたラベルは、エンコードされた
   ASCII文字か適切にデコードされた文字のどちらかの形式で表現されるため、
   アプリケーションはユーザー向けに希望する表示形式を選択するオプションを
   持っていてもよい(MAY)。オプションを用意する場合、ACE形式の表示を
   デフォルトにすべきではない(SHOULD NOT)。

   ドメイン名はしばしば多くの場所に保存され、転送される。例えば、
   ドメイン名はメールメッセージやWebページのような文書の一部である。
   ドメイン名は多くのプロトコルの様々な部分で転送される。例えば、
   SMTPの制御コマンドとRFC2822形式のボディー部分、HTTPのヘッダーと
   ボディー部分等が挙げられる。ドメイン名がドメイン名スロットと
   プロトコル上で転送される内容物の両方に現れることを記憶にとどめる
   ことは重要である。

   仕様の扱い方や文字集合の交渉(negotiation)方法を定義したプロトコル
   または文書形式の範囲内で、ラベルは許容された任意の文字集合に
   エンコードすることができる。プロトコルまたは文書形式が1つの文字集合しか
   許容しない場合、ラベルはその文字集合でなければならない(MUST)。

   プロトコルまたは文書形式が国際化ラベル内の文字の転送を許容している
   場所では、それが何であれ、その場所でプロトコルまたは文書形式が使用する
   文字エンコーディングとエスケープの仕組みを使用して国際化ラベルを転送すべき
   である(SHOULD)。

   ドメイン名スロットを使用する全てのプロトコルは、ASCII文字集合で構成
   されたドメイン名を処理する能力を既に持っている。したがって、ACEラベル
   (ToASCII処理が適用された国際化ラベル)は本質的にこれらのプロトコルでも
   処理可能である。





Faltstrom, et al.           Standards Track                    [Page 14]

RFC 3490                          IDNA                        March 2003


6.2 アプリケーションとリゾルバーライブラリー

   DNSの問い合わせを解決する際に、アプリケーションは通常オペレーティング
   システムの機能を使用する。オペレーティングシステムに含まれるこれらの
   機能はしばしば"リゾルバーライブラリー"と呼ばれ、アプリケーションはこの
   リゾルバーライブラリーとプログラミングインターフェース(API)を通して
   通信する。

   今日のこれらリゾルバーライブラリーは、その入力としてASCIIで記述された
   ドメイン名だけしか期待しないため、アプリケーションはリゾルバーライブラリーに
   渡すラベルをToASCII処理を使用して前処理しなければならない(MUST)。
   リゾルバーライブラリーから受信するラベルはASCII文字しか含まない。
   直接ASCIIでは表現できない国際化ラベルに対しては、ACE形式が使用される。
   ACEラベルは常にACEプレフィックスを含む。

   オペレーティングシステムは、ToASCII処理を実行するためのライブラリーセットを
   持っているかもしれない。そのようなライブラリーへの入力は、アプリケーションで
   使用される1つ以上の文字集合である(ほとんどのオペレーティングシステムで
   UTF-8とUTF-16は候補となる可能性がある。また地域化(localized)された
   オペレーティングシステムではその地域の用字固有の文字集合が候補となり得る)。

   IDNA対応アプリケーションは、([STD13]と[STD3]に準拠する)非国際化ラベルと
   国際化ラベルの両方で動作できなければならない(MUST)。

   将来登場するであろう新しいバージョンのリゾルバーライブラリーは、
   ASCII以外の他の文字集合で記述されたドメイン名を受理できるように
   なることが期待される。また、アプリケーション開発者は、ある日Unicodeの
   ドメイン名だけでなく、地域の用字固有の文字集合をオペレーティング
   システム内のリゾルバーライブラリー向けの新しいAPIに渡すようになるかも
   しれない。その場合、ToASCII処理とToUnicode処理は、これら新しい
   バージョンのリゾルバーライブラリー内部で実行されることになるかもしれない。

   リゾルバーに渡されるドメイン名や、DNS問い合わせメッセージの問い合わせ部
   (question section)に入れられるドメイン名は、[STRINGPREP]で規定された
   "問い合わせ(queries)"用のルールに従う。

6.3 DNSサーバー

   ゾーン内に保存されるドメイン名は、[STRINGPREP]で規定された"保存文字列
   (stored strings)"用のルールに従う。

   DNSは、直接ASCIIで表現できない国際化ラベルを表現するために、ToASCII処理に
   よって生成されたACE形式を使用しなければならない(MUST)。DNSによって提供
   される全てのIDNは、ASCII文字だけで構成されなければならない(MUST)。

   将来において、それぞれ旧式と新式のDNSクライアントとサーバー間で
   交渉を可能にするようなシグナリングの仕組みが標準化されたならば、
   DNSプロトコル自身の問い合わせで使用するエンコーディングをACEから
   UTF-8のような他のものに変更できるかもしれない。


Faltstrom, et al.           Standards Track                    [Page 15]

RFC 3490                          IDNA                        March 2003


   しかしかながら、DNSの問い合わせで新しいエンコーディングを使用すべきか
   どうかは独立した問題であり、本文書では議論されない。

6.4 ユーザーへの素(raw)のACEエンコーディング表示の回避

   ユーザーがACEを見ることを回避するのであれば、gethostbyaddrやメール
   ヘッダーの一部といったドメイン名スロットから得られたドメイン名を
   ユーザーに示す可能性があるアプリケーションは、全て更新される必要がある。

   アプリケーションがACE名をToUnicodeでデコードし、そのデコードした名前を
   構成する文字全てを表示できない場合、例えば名前に含まれる文字を
   出力システムが表示できないような場合には、アプリケーションは表示できない
   文字を(U+FFFDに)置換して名前を表示するのではなく、(ACEプレフィックスを
   含む)ACE形式で表示すべきである(SHOULD)。こうすることにより、ユーザーは
   容易に名前を正しく他のプログラムに転送することができるようになる。
   また、ラベルに含まれる文字全てを表示できない場合にデフォルトで
   ACE形式を表示するプログラムは、表示できない文字の部分だけ置換した文字を
   使用するなど、表示できる限りの文字を使用してToUnicode処理が生成した
   名前を表示する仕組みも持つべきである(SHOULD)。

   ToUnicode処理は、たとえACEプレフィックスから開始されていたとしても、
   無効な(not valid)ACEラベルを変換しない。ToUnicode処理の適用後に
   依然としてラベルがACEプレフィックスから開始されている場合、それは
   無効なACEラベルであり、ToUnicode処理によって生成された中間的な
   Unicode文字列のどれとも等価ではない。

6.5  IDNドメイン名のDNSSEC認証

   DNSセキュリティー拡張[RFC2535]はDNSメッセージのやり取りに暗号技術を
   使用した検証情報を提供するための方法である。公開鍵暗号と電子署名を
   併せて使用することにより、ドメイン情報の問い合わせを行った人または
   プログラムに対し、データの起源を認証する手段を提供する。これにより、
   直接かあるいはDNS階層の頂点へと連なる情報の起源をリンクした信頼の連鎖を
   たどることにより、信頼できる起源までさかのぼることが可能なことを
   保証する。

   IDNAでは、DNSによって提供される国際化ドメイン名全てについて、
   直接ASCII文字で表現できない場合には、ToASCII処理によって生成される
   ACE形式を使用しなければならないと規定している。この処理は、ゾーンの
   秘密鍵によってゾーンに署名される前に実行されなければならない。


Faltstrom, et al.           Standards Track                    [Page 16]

RFC 3490                          IDNA                        March 2003


   この処理の順序付けがあるため、DNSSECはASCIIドメイン名を認証するので
   あって、Unicode形式やUnicode形式とASCII形式の間の変換部分を認証するのでは
   ないことを認識することは重要である。DNSSECが運用されている状況では、
   ASCII形式の名前がゾーン内で署名されなければならない(MUST)名前であり、
   また検証されなければならない(MUST)名前である。

   DNSSECを運用しつつIDNAを展開しているサイトにおける影響の一つとして、
   ユーザーからの入力をIDNに変換する特殊用途のプロキシーやフォワーダー
   (forwarder)は、その処理をDNSSECが動作してネームサーバーを認証する前に
   行わなければならないということが挙げられる。

7. ネームサーバーに関する考察

   既存のDNSサーバーは、IDNの非ASCII形式を処理するIDNAルールについての
   知識を持たないので、それらの処理はDNSサーバーから遮断されなければならない。
   DNSサーバーのデータベースに名前を入力可能な既存の全チャネル(例えば
   マスターファイル[STD13]やDNS更新メッセージ[RFC2136])は、IDNA以前から
   存在するため、IDN非対応である。したがって、本文書のセクション3.1に
   記述した要件2が提示するように、これらのチャネルはIDNA関連の処理から
   遮断されなければならない。この要件は、チャネルを通してDNSサーバー
   データベースに入力される国際化ドメイン名が等価なASCII形式のものに
   変換済みであることを保証することによって満たされる。

   1つの特定のドメイン名に対して、ASCIIエンコーディングされたものは
   1つだけであることは必須である。ToASCII処理とToUnicode処理の設計により、
   ASCIIラベルにデコードされるACEラベルは存在しないので、ネームサーバーは
   同じドメイン名に対する複数のASCIIエンコーディングを持つことができない。

   [RFC2181]はドメインラベルがASCIIの範囲(0..7F)外にあるオクテットを含む
   ことを明示的に許しており、本文書はそれを変更しない。しかし、80..FFの
   範囲のオクテットを文字であると解釈する定義は存在しないことに注意して
   もらいたい。これらのオクテットを含むラベルがアプリケーションに返された
   場合、その結果は予測できないものとなる。ToASCII処理によって定義された
   ASCII形式は、現在のDNSプロトコルにおける国際化ラベルの唯一の標準的な
   表現形式である。

8. ルートサーバーに関する考察

   IDNは、現在のドメイン名よりも幾らか長くなる可能性があるため、ルート
   サーバーが必要とする帯域も現在より少々増える可能性がある。
   また、IDNへの問い合わせと応答は今日の典型的な問い合わせ処理よりも
   長いものになる可能性があるため、より多くの問い合わせがUDPではなく
   TCPでの処理を余儀なくされるかもしれない。









Faltstrom, et al.           Standards Track                    [Page 17]

RFC 3490                          IDNA                        March 2003


9. 参考文献

9.1 必須の参考文献

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
                Internationalized Strings ("stringprep")", RFC 3454,
                December 2002.

   [NAMEPREP]   Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
                Profile for Internationalized Domain Names (IDN)", RFC
                3491, March 2003.

   [PUNYCODE]   Costello, A., "Punycode: A Bootstring encoding of
                Unicode for use with Internationalized Domain Names in
                Applications (IDNA)", RFC 3492, March 2003.

   [STD3]       Braden, R., "Requirements for Internet Hosts --
                Communication Layers", STD 3, RFC 1122, and
                "Requirements for Internet Hosts -- Application and
                Support", STD 3, RFC 1123, October 1989.

   [STD13]      Mockapetris, P., "Domain names - concepts and
                facilities", STD 13, RFC 1034 and "Domain names -
                implementation and specification", STD 13, RFC 1035,
                November 1987.

9.2 有用な参考文献

   [RFC2535]    Eastlake, D., "Domain Name System Security Extensions",
                RFC 2535, March 1999.

   [RFC2181]    Elz, R. and R. Bush, "Clarifications to the DNS
                Specification", RFC 2181, July 1997.

   [UAX9]       Unicode Standard Annex #9, The Bidirectional Algorithm,
                .

   [UNICODE]    The Unicode Consortium. The Unicode Standard, Version
                3.2.0 is defined by The Unicode Standard, Version 3.0
                (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
                as amended by the Unicode Standard Annex #27: Unicode
                3.1 (http://www.unicode.org/reports/tr27/) and by the
                Unicode Standard Annex #28: Unicode 3.2
                (http://www.unicode.org/reports/tr28/).




Faltstrom, et al.           Standards Track                    [Page 18]

RFC 3490                          IDNA                        March 2003


   [USASCII]    Cerf, V., "ASCII format for Network Interchange", RFC
                20, October 1969.

10. セキュリティーに関する考察

   インターネット上のセキュリティーは、その一部をDNSに依存する。したがって、
   DNSの特性に関わるどのような変更であっても、インターネットの大部分に
   おけるセキュリティーを変更し得る。

   本文書は、STD3とSTD13に照らして有効ではない文字を、有効なオクテット値に
   エンコードするアルゴリズムを記述している。ACEエンコーディング処理
   そのもののためにもたらされるセキュリティー問題を除けば、例えば文字列の
   長さの増加や新たに許容される値といったセキュリティー上の問題は、
   エンコーディング処理やエンコードされた値の使用によってもたらされない

   ドメイン名はユーザーがインターネットサーバーを識別し、接続するために
   使用される。ユーザーが単一の国際化ドメイン名を入力した後、その国際化
   ドメイン名の異なる解釈に基づいて異なるサーバーに接続されるのであれば、
   インターネットのセキュリティーは侵害される。

   システムがASCIIやUnicodeではなく、地域の用字固有の文字集合を使用して
   いる場合、アプリケーションが処理できるように用字固有の文字集合から
   Unicodeにコード変換する処理に関して、本仕様は問題を積み残している。
   異なるアプリケーション(またはアプリケーションの異なるバージョン)が
   異なるコード変換ルールを実装している場合、それぞれが同じ名前を
   別なものとして解釈し、異なるサーバーに接続しようとする可能性がある。
   この問題は、TLSのような地域の用字固有の文字集合を考慮しない
   セキュリティープロトコルでは解決されない。

   本文書は必須の参考文献として[NAMEPREP]、[PUNYCODE]、[STRINGPREP]を
   参照しているため、これら一連の文書で記述されるセキュリティーに関する
   考察を同様に含む。

   より新しいUnicode正規化(normalization)テーブルを使用するために
   本仕様が更新された場合、後方互換のない変更がなされていないかを見極める
   ために、新しい正規化テーブルを古いものと比較しなければならない。
   後方互換のない変更がなされた場合、その部分を何らかの方法で処理する
   必要がある。また運用上の影響だけでなくセキュリティーの問題も発生する
   だろう。矛盾を処理する方法として、古い正規化テーブルを維持し続けるか、
   運用上の手段によって矛盾の生じた文字を扱わないように注意するか、
   または他の何らかの方法が考えられる。

   実装は、たとえオペレーティングシステムによってより新しい正規化テーブルが
   提供されたとしても、本文書で参照したものよりも新しい正規化テーブルを
   使用してはならない(MUST NOT)。


Faltstrom, et al.           Standards Track                    [Page 19]

RFC 3490                          IDNA                        March 2003


   オペレーティングシステム内にある正規化テーブルのバージョンについて
   アプリケーションが確かな情報を持たない場合、アプリケーションは自前で
   正規化テーブルを持つ必要がある。本仕様が参照するもの以外の正規化
   テーブルの使用により、セキュリティー上の問題と運用上の影響を発生させる
   可能性がある。

   見かけ上似ている文字の間で生じる混乱の抑制を補助するために、ドメイン名が
   複数の用字に属する文字を含んでいることを視覚的に示すものを実装が提供する
   ことが提案されている。そのような仕組みは、名前が中国語の繁体字と簡体字を
   混在して含むような場合にも、それを示すために使用できる。あるいは、
   数字のゼロ(0)とイチ(1)と英字のオー(O)とエル(l)を識別する際にも使用
   できる。DNSのゾーン管理者は、同型異義語(homograph)を最小にしようと
   試みる制限(セクション2の制限にしたがう)を課してもよい。

   ドメイン名(またはその一部)は、しばしば何らかの特権を持つドメイン
   (privileged domain)または特権から排除されたドメイン(anti-privileded 
   domain)(*4)と比較されることがある。そのような状況では、比較は
   セクション3.1の要件4の規定にしたがって適正に行うことが極めて重要である。
   既にASCII形式になっているラベルに関する適正な比較は、ASCIIラベルの
   比較で常に使用されてきた、大文字と小文字を区別しないASCII比較に帰着する。


《脚注》
  *4: 「特権を持つドメイン、特権から排除されたドメイン」
      例えば、Webサーバーへのアクセスを考える場合、"example.jpからの
      アクセスだけを認める"ような場合はexample.jpは特権を持つドメインである。
      逆に"example.jpからのアクセスを拒否する"ような場合、example.jpは
      特権から排除されたドメインとなる。

   IDNAの導入により、ACEプレフィックスで開始され、ToUnicode処理によって
   変換されることになるラベルは全て自動的にACEラベルとして扱われるように
   なる。また、ゾーン管理者やドメイン名登録者の意図に関わらず、これらの
   ラベルは非ASCIIラベルと等価であるとみなされるようになる。

11. IANAに関する考察

   IANAはIESGと協議してACEプレフィックスを割り当てた。





















Faltstrom, et al.           Standards Track                    [Page 20]

RFC 3490                          IDNA                        March 2003


12. 著者の連絡先

   Patrik Faltstrom
   Cisco Systems
   Arstaangsvagen 31 J
   S-117 43 Stockholm  Sweden

   EMail: paf@cisco.com


   Paul Hoffman
   Internet Mail Consortium and VPN Consortium
   127 Segre Place
   Santa Cruz, CA  95060  USA

   EMail: phoffman@imc.org


   Adam M. Costello
   University of California, Berkeley

   URL: http://www.nicemice.net/amc/





























Faltstrom, et al.           Standards Track                    [Page 21]

RFC 3490                          IDNA                        March 2003


13. 完全な著作権表示

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

謝辞

   RFCエディターの活動に対する資金は現在Internet Societyによって
   提供されている。



















Faltstrom, et al.           Standards Track                    [Page 22]