この文書はRFC3490の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group P. Faltstrom
Request for Comments: 3490 Cisco
Category: Standards Track P. Hoffman
IMC & VPNC
A. Costello
UC Berkeley
March 2003
Internationalizing Domain Names in Applications (IDNA)
アプリケーションのドメイン名国際化（ＩＤＮＡ）
Status of this Memo
この文書の状態
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
概要
Until now, there has been no standard method for domain names to use
characters outside the ASCII repertoire. This document defines
internationalized domain names (IDNs) and a mechanism called
Internationalizing Domain Names in Applications (IDNA) for handling
them in a standard fashion. IDNs use characters drawn from a large
repertoire (Unicode), but IDNA allows the non-ASCII characters to be
represented using only the ASCII characters already allowed in so-
called host names today. This backward-compatible representation is
required in existing protocols like DNS, so that IDNs can be
introduced with no changes to the existing infrastructure. IDNA is
only meant for processing domain names, not free text.
今まで、ドメイン名でＡＳＣＩＩ範囲外の文字を使う標準方法がありません
でした。この文書は、国際化ドメイン名（ＩＤＮ）と、標準的な方法でそれ
らの文字を扱うアプリケーションの国際化ドメイン名（ＩＤＮＡ）と呼ばれ
るメカニズムを定義します。ＩＤＮは広範囲の文字（ユニコード）の文字を
使いますが、ＩＤＮＡは、いわゆるホスト名で許されるＡＳＣＩＩ文字、だ
けを使って、非ＡＳＣＩＩ文字を表現するすることを許します。この逆方向
互換性がある表現はＤＮＳのような既存のプロトコルで必要とされ、ＩＤＮ
は既存のインフラの変更なしで導入できます。ＩＤＮＡは、テキストではな
く、ドメイン名を処理することに対してだけ意味があります。
Table of Contents
目次
1. Introduction
1. はじめに
1.1 Problem Statement
1.1 問題主張
1.2 Limitations of IDNA
1.2 ＩＤＮＡの限界
1.3 Brief overview for application developers
1.3 アプリケーション開発者のための短い概要
2. Terminology
2. 用語
3. Requirements and applicability
3. 必要条件と適用性
3.1 Requirements
3.1 必要条件
3.2 Applicability
3.2 適用性
3.2.1. DNS resource records
3.2.1. DNS 資源レコード
3.2.2. Non-domain-name data types stored in domain names
3.2.2. ドメイン名に登録される非ドメイン名のデータタイプ
4. Conversion operations
4. 変換オペレーション
4.1 ToASCII
4.1 ToASCII
4.2 ToUnicode
4.2 ToUnicode
5. ACE prefix
5. ＡＣＥプレフィックス
6. Implications for typical applications using DNS
6. DNSを使う典型的なアプリケーションのための意味
6.1 Entry and display in applications
6.1 アプリケーションへの入力と表示
6.2 Applications and resolver libraries
6.2 アプリケーションとリゾルバライブラリ
6.3 DNS servers
6.3 ＤＮＳサーバ
6.4 Avoiding exposing users to the raw ACE encoding
6.4 生のＡＣＥコーディングをユーザに曝すのを避ける
6.5 DNSSEC authentication of IDN domain names
6.5 ＩＤＮドメイン名のＤＮＳＳＥＣ認証
7. Name server considerations
7. ネームサーバの考慮
8. Root server considerations
8. ルートサーバの考察
9. References
9. 参考文献
9.1 Normative References
9.1 参照する参考文献
9.2 Informative References
9.2 有益な参考文献
10. Security Considerations
10. セキュリティの考察
11. IANA Considerations
11. ＩＡＮＡの考慮
12. Authors' Addresses
12. 著者のアドレス
13. Full Copyright Statement
13. 著作権表示全文
1. Introduction
1. はじめに
IDNA works by allowing applications to use certain ASCII name labels
(beginning with a special prefix) to represent non-ASCII name labels.
Lower-layer protocols need not be aware of this; therefore IDNA does
not depend on changes to any infrastructure. In particular, IDNA
does not depend on any changes to DNS servers, resolvers, or protocol
elements, because the ASCII name service provided by the existing DNS
is entirely sufficient for IDNA.
ＩＤＮＡは非ＡＳＣＩＩ名ラベルを表すために、アプリケーションに（特別
なプレフィックスから始まる）ある特定のＡＳＣＩＩ名前ラベルを使うこと
を許すことによって働きます。より低い層のプロトコルがこれに気付く必要
がありません；それ故にＩＤＮＡはどんなもインフラに対する変更にも依存
しません。特に、既存のＤＮＳが供給するＡＳＣＩＩネームサービスがＩＤ
ＮＡに十分であるため、ＩＤＮＡはＤＮＳサーバとリゾルバとプロトコル要
素に対する変更を必要としません。
This document does not require any applications to conform to IDNA,
but applications can elect to use IDNA in order to support IDN while
maintaining interoperability with existing infrastructure. If an
application wants to use non-ASCII characters in domain names, IDNA
is the only currently-defined option. Adding IDNA support to an
existing application entails changes to the application only, and
leaves room for flexibility in the user interface.
この文書はアプリケーションがＩＤＮＡに準拠するように要求しませんが、
アプリケーションが既存のインフラと互換性を保ったまま、ＩＤＮをサポー
トするためにＩＤＮＡを使うことを選ぶことができます。もしアプリケーショ
ンがドメイン名で非ＡＳＣＩＩ文字を使うことを望むなら、ＩＤＮＡが唯一
の現在定義されたオプションです。既存のアプリケーションにＩＤＮＡサポー
トを加えることはアプリケーションのみに対する変更を必要として、そして
ユーザ・インタフェースで柔軟性の余地を残します。
A great deal of the discussion of IDN solutions has focused on
transition issues and how IDN will work in a world where not all of
the components have been updated. Proposals that were not chosen by
the IDN Working Group would depend on user applications, resolvers,
and DNS servers being updated in order for a user to use an
internationalized domain name. Rather than rely on widespread
updating of all components, IDNA depends on updates to user
applications only; no changes are needed to the DNS protocol or any
DNS servers or the resolvers on user's computers.
多くのＩＤＮ解決の論議は、移行問題と、更新さていない構成要素がある世
界でＩＤＮが働く方法、に焦点を合わせました。ＩＤＮワーキンググループ
によって選択されなかった提案は、ユーザが国際化ドメイン名を使うために、
ユーザーアプリケーションかリゾルバかＤＮＳサーバが、更新されることに
依存するためです。ＩＤＮＡはすべての要素を広範囲に更新するより、ユー
ザアプリケーションのみの更新に依存します；変更がユーザのコンピュータ
の上のＤＮＳプロトコルやＤＮＳサーバーやリゾルバに必要とされません。
1.1 Problem Statement
1.1 問題主張
The IDNA specification solves the problem of extending the repertoire
of characters that can be used in domain names to include the Unicode
repertoire (with some restrictions).
ＩＤＮＡ指定はドメイン名で使われることができる文字の範囲を、ユニコー
ド（若干の制限で）を含む範囲に拡張する問題を解きます。
IDNA does not extend the service offered by DNS to the applications.
Instead, the applications (and, by implication, the users) continue
to see an exact-match lookup service. Either there is a single
exactly-matching name or there is no match. This model has served
the existing applications well, but it requires, with or without
internationalized domain names, that users know the exact spelling of
the domain names that the users type into applications such as web
browsers and mail user agents. The introduction of the larger
repertoire of characters potentially makes the set of misspellings
larger, especially given that in some cases the same appearance, for
example on a business card, might visually match several Unicode code
points or several sequences of code points.
ＩＤＮＡはＤＮＳがアプリケーションに提供するサービスを拡張しません。
その代わりに、アプリケーション（そして、暗にユーザ）が正確な一致検索
サービスを続けます。正確に一致するひとつの名前があるか、一致しないか
のどちらかが常に真です。このモデルはうまく既存のアプリケーションをサ
ポートしましたが、これは国際化ドメイン名の有無にかかわらず、ユーザが
Ｗｅｂブラウザとメールユーザーエージェントのようなアプリケーションで
タイプするドメイン名について、ユーザが厳密に正確なつづりを知っている
ことを要求します。文字のより大きい範囲の導入は潜在的につづり誤りの可
能性を大きくします、特に、例えば名刺上で、外見が同じ文字、視覚的にい
くつかのユニコードコードポイントや、コードポイント列に一致する場合に
問題です。
IDNA allows the graceful introduction of IDNs not only by avoiding
upgrades to existing infrastructure (such as DNS servers and mail
transport agents), but also by allowing some rudimentary use of IDNs
in applications by using the ASCII representation of the non-ASCII
name labels. While such names are very user-unfriendly to read and
type, and hence are not suitable for user input, they allow (for
instance) replying to email and clicking on URLs even though the
domain name displayed is incomprehensible to the user. In order to
allow user-friendly input and output of the IDNs, the applications
need to be modified to conform to this specification.
ＩＤＮＡは（ＤＮＳサーバーとメール転送エージェントのような）既存のイ
ンフラの更新を避けるだけでなく、非ＡＳＣＩＩ名前ラベルのＡＳＣＩＩ表
現を使うアプリケーションであるＩＤＮの原始的な使い方を許すことによっ
てＩＤＮの優美な導入を許します。このような名前が読み書きに関して非常
にユーザに非友好的であり、それ故、ユーザ入力にに適していないが、それ
らは（例えば）電子メールで応答することを許し、ドメイン名の表示が不可
解でも、ユーザがＵＲＬをクリックすることはできます。ユーザに友好的な
入力とＩＤＮ出力を許すために、アプリケーションはこの仕様書に従う修正
が必要です。
IDNA uses the Unicode character repertoire, which avoids the
significant delays that would be inherent in waiting for a different
and specific character set be defined for IDN purposes by some other
standards developing organization.
ＩＤＮＡはユニコードの文字範囲を使います、これは他の標準開発組織の作っ
た異なる特定文字が定義されてからＩＤＮを定義するのを待つ重大な遅れを
避けます。
1.2 Limitations of IDNA
1.2 ＩＤＮＡの限界
The IDNA protocol does not solve all linguistic issues with users
inputting names in different scripts. Many important language-based
and script-based mappings are not covered in IDNA and need to be
handled outside the protocol. For example, names that are entered in
a mix of traditional and simplified Chinese characters will not be
mapped to a single canonical name. Another example is Scandinavian
names that are entered with U+00F6 (LATIN SMALL LETTER O WITH
DIAERESIS) will not be mapped to U+00F8 (LATIN SMALL LETTER O WITH
STROKE).
ＩＤＮＡプロトコルはユーザが異なる状況で名前を入力する時のすべての言
語の問題を解くわけではありません。多くの重要な言語と状況に基づく翻訳
はＩＤＮＡでは対応してなくて、プロトコル外で処理される必要があります。
例えば、伝統的漢字（旧字体）と、単純化された漢字（新字体）の混合入力
の名前をひとつの正規名に変換しないでしょう。他の例がスカンジナビアの
名前で、U+00F6(LATIN SMALL LETTER O WITH DIAERESIS)が、U+00F8(LATIN
SMALL LETTER O WITH STROKE)に変換されないであろうということです。
An example of an important issue that is not considered in detail in
IDNA is how to provide a high probability that a user who is entering
a domain name based on visual information (such as from a business
card or billboard) or aural information (such as from a telephone or
radio) would correctly enter the IDN. Similar issues exist for ASCII
domain names, for example the possible visual confusion between the
letter 'O' and the digit zero, but the introduction of the larger
repertoire of characters creates more opportunities of similar
looking and similar sounding names. Note that this is a complex
issue relating to languages, input methods on computers, and so on.
Furthermore, the kind of matching and searching necessary for a high
probability of success would not fit the role of the DNS and its
exact matching function.
ＩＤＮＡで細部を考慮していない重要な問題の例は、視覚情報に基づいて
（名刺あるいは広告板から）、あるいは、聴覚の情報に基づいて（電話ある
いはラジオから）、ドメイン名を入力するユーザが正確にＩＤＮを入力する
確率を高くする方法です。類似の問題がＡＳＣＩＩドメイン名で存在します、
例えば文字「Ｏ」と数字ゼロの間の可能な視覚の混乱です、より多くの文字
の導入は見かけの類似の名前をより多くします。これが言語や入力方法など
に関連している複雑な問題であることに注意して下さい。さらに、検索と一
致の成功確率の高い要求は、ＤＮＳとその厳密な一致機能の役割に適してい
ないでしょう。
1.3 Brief overview for application developers
1.3 アプリケーション開発者のための短い概要
Applications can use IDNA to support internationalized domain names
anywhere that ASCII domain names are already supported, including DNS
master files and resolver interfaces. (Applications can also define
protocols and interfaces that support IDNs directly using non-ASCII
representations. IDNA does not prescribe any particular
representation for new protocols, but it still defines which names
are valid and how they are compared.)
ＤＮＳマスターファイルとリゾルバインタフェースを含めて、アプリケーショ
ンは、ＡＳＣＩＩドメイン名がすでにサポートされているところでは、国際
化ドメイン名をサポートするために、ＩＤＮＡを使うことができます。（ア
プリケーションが同じく非ＡＳＣＩＩ表現を直接使ってＩＤＮをサポートす
るプロトコルとインタフェースを定義することができます。ＩＤＮＡは新し
いプロトコルのための特定の表現を定めませんが、どの名前が正当で、どの
ようにそれらが比較されるか定義します）。
The IDNA protocol is contained completely within applications. It is
not a client-server or peer-to-peer protocol: everything is done
inside the application itself. When used with a DNS resolver
library, IDNA is inserted as a "shim" between the application and the
resolver library. When used for writing names into a DNS zone, IDNA
is used just before the name is committed to the zone.
ＩＤＮＡプロトコルは完全にアプリケーションの中にあります。これはクラ
イアント・サーバや、ピア対ピアのプロトコルではありません：すべてがア
プリケーション自身の中にあります。ＤＮＳリゾルバライブラリで使われる
時、ＩＤＮＡは「くさび」としてアプリケーションとリゾルバライブラリの
間に挿入されます。ＤＮＳゾーンに名前を書き込むために使われる時、ＩＤ
ＮＡは名前がゾーンに委ねられる直前に使われます。
There are two operations described in section 4 of this document:
この文書の４章に記述された２つのオペレーションがあります：
- The ToASCII operation is used before sending an IDN to something
that expects ASCII names (such as a resolver) or writing an IDN
into a place that expects ASCII names (such as a DNS master file).
- ToASCIIオペレーションは、ＩＤＮを（リゾルバのような）ＡＳＣＩＩ名
を予想する所に送る前や、（ＤＮＳマスターファイルのような）ＡＳＣＩ
Ｉ名を予想する場所の中にＩＤＮを書く前に使われます。
- The ToUnicode operation is used when displaying names to users,
for example names obtained from a DNS zone.
- ToUnicodeオペレーションはユーザーへの名前を見せるとき、例えばＤＮ
Ｓゾーンから得られる名前を見せる時に、使われます。
It is important to note that the ToASCII operation can fail. If it
fails when processing a domain name, that domain name cannot be used
as an internationalized domain name and the application has to have
some method of dealing with this failure.
ToASCIIオペレーションが失敗しうることを指摘することは重要です。もしド
メイン名を処理する時に失敗するなら、そのドメイン名は国際化ドメイン名
として用いることができません、そしてアプリケーションはこの失敗を扱う
いずれかの方法を持たなければなりません。
IDNA requires that implementations process input strings with
Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP],
and then with Punycode [PUNYCODE]. Implementations of IDNA MUST
fully implement Nameprep and Punycode; neither Nameprep nor Punycode
are optional.
ＩＤＮＡは、入力文字列を、文字列前処理[STRINGPREP]のプロフィールであ
る名前前処理[NAMEPREP]と、次にプニコード[PUNYCODE]の処理の実装を要求
します。ＩＤＮＡの実行が完全に名前準備とプニコードを実装しなくてはな
りません(MUST)；名前前処理とプニコードのいずれもオプションではありま
せん。
2. Terminology
2. 用語
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
and "MAY" in this document are to be interpreted as described in BCP
14, RFC 2119 [RFC2119].
この文書のキーワードは"MUST"と"SHALL"と"REQUIRED"と"SHOULD"と
"RECOMMENDED"と"MAY"は、ＢＣＰ１４、ＲＦＣ２１１９[RFC2119]で記述さ
れたよう、解釈れるはずです。
A code point is an integer value associated with a character in a
coded character set.
コードポイントがコード化文字セットで１文字と結び付けられる整数値です。
Unicode [UNICODE] is a coded character set containing tens of
thousands of characters. A single Unicode code point is denoted by
"U+" followed by four to six hexadecimal digits, while a range of
Unicode code points is denoted by two hexadecimal numbers separated
by "..", with no prefixes.
ユニコード[UNICODE]は何万という文字を含んでいるコードされた文字セット
です。ひとつのユニコードコードポイントが"U+"に続く４又は６桁の１６進
数で、ユニコードポイントの範囲は、プレフィックスなしで".."で分割され
た２つの１６進数です。
ASCII means US-ASCII [USASCII], a coded character set containing 128
characters associated with code points in the range 0..7F. Unicode
is an extension of ASCII: it includes all the ASCII characters and
associates them with the same code points.
ＡＳＣＩＩは合衆国ＡＳＣＩＩ[USASCII]で、０から７Fの範囲のコードポイ
ントの１２８の文字を含んでいるコード化文字セットを意味します。ユニコー
ドはＡＳＣＩＩの拡張です：これはすべてのＡＳＣＩＩ文字を含み、そして
同じコードポイントでそれらを提携させます。
The term "LDH code points" is defined in this document to mean the
code points associated with ASCII letters, digits, and the hyphen-
minus; that is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an
abbreviation for "letters, digits, hyphen".
用語「ＬＤＨコードポイント」はＡＳＣＩＩ文字と数字とハイフンのコード
ポイントとこの文書で定義されます；これはU+002Dと30..39と41..5Aと
61..7Aです。「ＬＤＨ」は「文字、数値、ハイフン」の頭文字です。
[STD13] talks about "domain names" and "host names", but many people
use the terms interchangeably. Further, because [STD13] was not
terribly clear, many people who are sure they know the exact
definitions of each of these terms disagree on the definitions. In
this document the term "domain name" is used in general. This
document explicitly cites [STD3] whenever referring to the host name
syntax restrictions defined therein.
[STD13]が「ドメイン名」と「ホスト名」の話をしますが、多くの人々が同じ
ものとしてこの用語を使います。さらに、[STD13]が明確ではなかったため、
これらの用語のそれぞれの正確な定義を知っていることが確かな多くの人々
の間でも、定義の意見が異なります。この文書で用語「ドメイン名」は一般
に使われます。この文書は、ホスト名文法制限を参照する時はいつでも、明
示的に[STD3]で定義したものを引合いに出します。
A label is an individual part of a domain name. Labels are usually
shown separated by dots; for example, the domain name
"www.example.com" is composed of three labels: "www", "example", and
"com". (The zero-length root label described in [STD13], which can
be explicit as in "www.example.com." or implicit as in
"www.example.com", is not considered a label in this specification.)
IDNA extends the set of usable characters in labels that are text.
For the rest of this document, the term "label" is shorthand for
"text label", and "every label" means "every text label".
ラベルはドメイン名の個別の部分です。ラベルが通常点で分割されます；例
えば、ドメイン名「www.example.com」は３枚のラベルで構成されています：
「www」と「example」と「com」。（[STD13]で定義された長さゼロのルート
ラベル、"www.example.com."では明示的で、"www.example.com"では暗黙のも
のは、この仕様書ではラベルと考えません。）ＩＤＮＡがテキストのラベル
で使える文字のセットを拡張します。この文書の残りで、用語「ラベル」は
「テキストラベル」の速記で、「すべてのラベル」が「すべてのテキストラ
ベル」を意味します。
An "internationalized label" is a label to which the ToASCII
operation (see section 4) can be applied without failing (with the
UseSTD3ASCIIRules flag unset). This implies that every ASCII label
that satisfies the [STD13] length restriction is an internationalized
label. Therefore the term "internationalized label" is a
generalization, embracing both old ASCII labels and new non-ASCII
labels. Although most Unicode characters can appear in
internationalized labels, ToASCII will fail for some input strings,
and such strings are not valid internationalized labels.
「国際化ラベル」はToASCIIオペレーションが（セクション４を見てくださ
い）（UseSTD13ASCIIRulesフラグを設定しない状態で）失敗しないで適用で
きるラベルです。これは[STD13]の長さ制限を満足させるすべてのＡＳＣＩ
Ｉラベルが国際化ラベルであることを意味します。それ故に用語「国際化ラ
ベル」は、古いＡＳＣＩＩラベルと新しい非ＡＳＣＩＩラベルの両方を受け
入れて、一般論です。たいていのユニコード文字が国際化ラベルに現われる
ことができるが、ToASCIIはある入力文字列で失敗するでしょう、そしてこ
のような文字列は正当な国際化ラベルではありません。
An "internationalized domain name" (IDN) is a domain name in which
every label is an internationalized label. This implies that every
ASCII domain name is an IDN (which implies that it is possible for a
name to be an IDN without it containing any non-ASCII characters).
This document does not attempt to define an "internationalized host
name". Just as has been the case with ASCII names, some DNS zone
administrators may impose restrictions, beyond those imposed by DNS
or IDNA, on the characters or strings that may be registered as
labels in their zones. Such restrictions have no impact on the
syntax or semantics of DNS protocol messages; a query for a name that
matches no records will yield the same response regardless of the
reason why it is not in the zone. Clients issuing queries or
interpreting responses cannot be assumed to have any knowledge of
zone-specific restrictions or conventions.
「国際化ドメイン名」（ＩＤＮ）はすべてのラベルが国際化ラベルであるド
メイン名です。これはすべてのＡＳＣＩＩドメイン名がＩＤＮであることを
意味します（非ＡＳＣＩＩ文字を含んでいないＩＤＮ名が可能なことを意味
します）。この文書は「国際化ホスト名」を定義しようと試みません。ちょ
うどＡＳＣＩＩ名でそうであるように、あるＤＮＳゾーン管理者がそのゾー
ンのラベルとして登録されるかもしれない文字や文字列に、ＤＮＳやＩＤＮ
Ａで課されたのを越えて、制限を課してもよいです。このような制限はＤＮ
Ｓプロトコルメッセージの構文あるいは語義に影響を持ちません；レコード
と一致しない名前の問合せは、それがなぜそのゾーンにないかの理由にかか
わらず、同じ回答をもたらすでしょう。質問や回答を解釈するクライアント
がゾーン特有の制限や慣習の知識を持つと考えられません。
In IDNA, equivalence of labels is defined in terms of the ToASCII
operation, which constructs an ASCII form for a given label, whether
or not the label was already an ASCII label. Labels are defined to
be equivalent if and only if their ASCII forms produced by ToASCII
match using a case-insensitive ASCII comparison. ASCII labels
already have a notion of equivalence: upper case and lower case are
considered equivalent. The IDNA notion of equivalence is an
extension of that older notion. Equivalent labels in IDNA are
treated as alternate forms of the same label, just as "foo" and "Foo"
are treated as alternate forms of the same label.
ＩＤＮＡで、ラベルの等価がToASCII演算に関して定義され、そしてそれは、
ラベルがすでにＡＳＣＩＩラベルであったか否かにかかわらず、所定のラベ
ルのＡＳＣＩＩの書式を組み立てます。ラベルは、ToASCIIの生成したＡＳＣ
ＩＩ形式が、大文字小文字の違いを無視するＡＳＣＩＩ比較で一致する場合
に、等しと定義されます。ＡＳＣＩＩラベルがすでに等しいという考えを持っ
ています：大文字と小文字が等しいと思われます。ＩＤＮＡの等しいの考え
は、その古い考えの拡張です。ＩＤＮＡでの等しいラベルは、ちょうど
「foo」と「Foo」が同じラベルの他の形式と取り扱われるように、同じラベ
ルの他の形式と扱われます。
To allow internationalized labels to be handled by existing
applications, IDNA uses an "ACE label" (ACE stands for ASCII
Compatible Encoding). An ACE label is an internationalized label
that can be rendered in ASCII and is equivalent to an
internationalized label that cannot be rendered in ASCII. Given any
internationalized label that cannot be rendered in ASCII, the ToASCII
operation will convert it to an equivalent ACE label (whereas an
ASCII label will be left unaltered by ToASCII). ACE labels are
unsuitable for display to users. The ToUnicode operation will
convert any label to an equivalent non-ACE label. In fact, an ACE
label is formally defined to be any label that the ToUnicode
operation would alter (whereas non-ACE labels are left unaltered by
ToUnicode). Every ACE label begins with the ACE prefix specified in
section 5. The ToASCII and ToUnicode operations are specified in
section 4.
国際化ラベルを既存のアプリケーションが処理できることを許すために、Ｉ
ＤＮＡは「ＡＣＥラベル」を使います（ＡＣＥはＡＳＣＩＩ共存エンコーディ
ングの意味です）。ＡＣＥラベルはＡＳＣＩＩで書かくことができる国際化
ラベルであり、ＡＳＣＩＩで書けない国際化ラベルと等しいです。（ＡＳＣ
ＩＩラベルがToASCIIによって変わらないのに対し）、ＡＳＣＩＩで書けない
国際化ラベルに対して、ToASCII 操作はそれを等しいＡＣＥラベルに変換す
るでしょう。ＡＣＥラベルはユーザに表示するには不適当です。ToUnicode操
作はラベルを等しい非ＡＣＥラベルに変換するでしょう。実際、ＡＣＥラベ
ルは公式にはToUnicode操作で変換される全てのラベルと定義されます（非Ａ
ＣＥラベルがToUnicodeで変更されません）。すべてのＡＣＥラベルが５章で
指定されたＡＣＥプレフィックスから始まります。ToASCIIとToUnicode操作
は４章で指定されます。
The "ACE prefix" is defined in this document to be a string of ASCII
characters that appears at the beginning of every ACE label. It is
specified in section 5.
「ＡＣＥプレフィックス」はすべてのＡＣＥラベルの始めに現われるＡＳＣ
ＩＩ文字列でこの文書で定義されます。これは５章で指定されます。
A "domain name slot" is defined in this document to be a protocol
element or a function argument or a return value (and so on)
explicitly designated for carrying a domain name. Examples of domain
name slots include: the QNAME field of a DNS query; the name argument
of the gethostbyname() library function; the part of an email address
following the at-sign (@) in the From: field of an email message
header; and the host portion of the URI in the src attribute of an
HTML <IMG> tag. General text that just happens to contain a domain
name is not a domain name slot; for example, a domain name appearing
in the plain text body of an email message is not occupying a domain
name slot.
「ドメイン名スロット」がプロトコル要素や関数引数や返り値（など）で扱っ
ているドメイン名を明示的に示すためにこの文書で定義されるます。ドメイ
ン名スロットの例が以下を含みます：ＤＮＳ問合せのQNAMEフィールド；
gethostbyname()ライブラリ関数のname引数；Ｅメールメッセージヘッダの
From:フィールドの電子メールアドレスのアットマーク(@)以降の部分；HTML
の<IMG>タグのsrc属性のＵＲＩのホスト部。たまたまちょうどドメイン名を
含んでいる一般的なテキストはドメイン名スロットではありません；例えば、
電子メールメッセージのテキストの本体に現われるドメイン名がドメイン名
スロットでありません。
An "IDN-aware domain name slot" is defined in this document to be a
domain name slot explicitly designated for carrying an
internationalized domain name as defined in this document. The
designation may be static (for example, in the specification of the
protocol or interface) or dynamic (for example, as a result of
negotiation in an interactive session).
「ＩＤＮ対応のドメイン名スロット」がこの文書で定義され、文書で定義さ
れる国際化ドメイン名を運ぶことと明示的に指名されるドメイン名スロット
です。指定は静的（例えば、プロトコルやインタフェースの仕様書で）かも
しれないし、動的（例えば、対話型のセッションでの交渉の結果として）か
もしれません。
An "IDN-unaware domain name slot" is defined in this document to be
any domain name slot that is not an IDN-aware domain name slot.
Obviously, this includes any domain name slot whose specification
predates IDNA.
「ＩＤＮ非対応のドメイン名スロット」がＩＤＮ対応のドメイン名スロット
でないドメイン名スロットとこの文書で定義されます。明らかに、これはＩ
ＤＮＡより前の全ての仕様書のドメイン名スロットを含みます。
3. Requirements and applicability
3. 必要条件と適用性
3.1 Requirements
3.1 必要条件
IDNA conformance means adherence to the following four requirements:
ＩＤＮＡ適合が次の４つの必要条件を守る事を意味します：
1) Whenever dots are used as label separators, the following
characters MUST be recognized as dots: U+002E (full stop), U+3002
(ideographic full stop), U+FF0E (fullwidth full stop), U+FF61
(halfwidth ideographic full stop).
1) 点がラベル分離記号として用いられる時はいつでも、次の文字は点として
認知されなくてはなりません(MUST)：U+002E(完全停止), U+3002(概念的
完全停止), U+FF0E(全角完全停止), U+FF61(半角完全停止)。
2) Whenever a domain name is put into an IDN-unaware domain name slot
(see section 2), it MUST contain only ASCII characters. Given an
internationalized domain name (IDN), an equivalent domain name
satisfying this requirement can be obtained by applying the
ToASCII operation (see section 4) to each label and, if dots are
used as label separators, changing all the label separators to
U+002E.
2) ドメイン名がＩＤＮ非対応のドメイン名スロットに入力される時は（２章
参照）、ＡＳＣＩＩ文字だけを含んでいなくてはなりません(MUST)。国際
化ドメイン名（ＩＤＮ）が与えられた場合、この必要条件を満たしている
等価なドメイン名は、各ラベルにToASCII演算を行い、もし点がラベル分
離記号に使われているならば、ラベル分離記号をU+002Eに変えることで、
得られます（４章参照）。
3) ACE labels obtained from domain name slots SHOULD be hidden from
users when it is known that the environment can handle the non-ACE
form, except when the ACE form is explicitly requested. When it
is not known whether or not the environment can handle the non-ACE
form, the application MAY use the non-ACE form (which might fail,
such as by not being displayed properly), or it MAY use the ACE
form (which will look unintelligle to the user). Given an
internationalized domain name, an equivalent domain name
containing no ACE labels can be obtained by applying the ToUnicode
operation (see section 4) to each label. When requirements 2 and
3 both apply, requirement 2 takes precedence.
3) ドメイン名スロットから得られたＡＣＥラベルは、ＡＣＥ形式が明示的に
求められる時を除いて、環境が、非エース形式を処理することができるこ
とが既知の場合、ユーザーから隠されるべきです(SHOULD)。環境が非エー
スの形式を処理することができるかどうかは既知ではない時、アプリケー
ションは非ＡＣＥ形式を使うかもしれないし(MAY)（これは適切に表示さ
れないので失敗するかもしれません）、ＡＣＥ形式を使うかもしれません
(MAY)（ユーザーに頭が悪いように見えるだろう）。与えられた国際化ド
メイン名に対し、ＡＣＥラベルを含まない等価なドメイン名はToUnicode
演算をする事で得られます。必要条件２と３が共に適用される時、必要条
件２が優先です。
4) Whenever two labels are compared, they MUST be considered to match
if and only if they are equivalent, that is, their ASCII forms
(obtained by applying ToASCII) match using a case-insensitive
ASCII comparison. Whenever two names are compared, they MUST be
considered to match if and only if their corresponding labels
match, regardless of whether the names use the same forms of label
separators.
4) ２つのラベルが比較される時はそれらが等しい場合に限りそしてその場合
には必ず、すなわち、それらの（ToASCIIを適用することによって得られ
た）ＡＳＣＩＩ形式を大文字小文字の違いを無視するＡＳＣＩＩ比較で一
致した場合、一致すると考えられなくてはなりません(MUST)。２つの名前
が比較される時は、各名前が同じラベル分離記号形式を使うかどうかにか
かわらず、それらの対応するラベルが一致する場合に限りそしてその場合
には必ず一致すると考えなくてはなりません(MUST)。
3.2 Applicability
3.2 適用性
IDNA is applicable to all domain names in all domain name slots
except where it is explicitly excluded.
ＩＤＮＡはそれが明示的に除去される所以外すべてのドメイン名スロットで
すべてのドメイン名に適用できます。
This implies that IDNA is applicable to many protocols that predate
IDNA. Note that IDNs occupying domain name slots in those protocols
MUST be in ASCII form (see section 3.1, requirement 2).
これはＩＤＮＡがＩＤＮＡに先行する多くのプロトコルに適用できることを
意味します。それらのプロトコルでドメイン名スロットのＩＤＮがＡＳＣＩ
Ｉ形式でいるに違いない(MUST)ことに注意してください（３.１章、必要条
件２参照）。
3.2.1. DNS resource records
3.2.1. DNS 資源レコード
IDNA does not apply to domain names in the NAME and RDATA fields of
DNS resource records whose CLASS is not IN. This exclusion applies
to every non-IN class, present and future, except where future
standards override this exclusion by explicitly inviting the use of
IDNA.
ＩＤＮＡはクラスがＩＮでないＤＮＳ資源レコードのＮＡＭＥとＲＤＡＴＡ
フィールドのドメイン名に当てはまりません。この除外は将来の標準が明示
的にＩＤＮＡの使用を招くことによってこの除外を取り去らない限り、すべ
ての非ＩＮクラス、現在と未来、に当てはまります。
There are currently no other exclusions on the applicability of IDNA
to DNS resource records; it depends entirely on the CLASS, and not on
the TYPE. This will remain true, even as new types are defined,
unless there is a compelling reason for a new type to complicate
matters by imposing type-specific rules.
ＤＮＳ資源レコードにＩＤＮＡの適用性について現在他のどのような除外も
ありません；それは完全にタイプではなく、クラスに頼ります。これは、新
しいタイプがタイプ特定の規則を課すことによって問題を複雑にする説得的
な理由がないなら、新しいタイプが定義される時でも真実のままでいるで
しょう。
3.2.2. Non-domain-name data types stored in domain names
3.2.2. ドメイン名に登録される非ドメイン名のデータタイプ
Although IDNA enables the representation of non-ASCII characters in
domain names, that does not imply that IDNA enables the
representation of non-ASCII characters in other data types that are
stored in domain names. For example, an email address local part is
sometimes stored in a domain label (hostmaster@example.com would be
represented as hostmaster.example.com in the RDATA field of an SOA
record). IDNA does not update the existing email standards, which
allow only ASCII characters in local parts. Therefore, unless the
email standards are revised to invite the use of IDNA for local
parts, a domain label that holds the local part of an email address
SHOULD NOT begin with the ACE prefix, and even if it does, it is to
be interpreted literally as a local part that happens to begin with
the ACE prefix.
ＩＤＮＡがドメイン名で非ＡＳＣＩＩ文字表現を可能にするが、これはＩＤ
ＮＡがドメイン名に登録される他のデータタイプで非ＡＳＣＩＩ文字の表現
を可能にすることを意味しません。例えば、電子メールアドレスローカル部
が時々ドメインラベルに登録されます (hostmaster@example.comは
hostmaster.example.comの表現で、ＳＯＡレコードのＲＤＡＴＡフィールド
に登録されます）。ＩＤＮＡは既存の電子メール標準を更新せず、そしてロー
カル部ではＡＳＣＩＩ文字だけを許します。従って、電子メール標準がロー
カル部のＩＤＮＡの使用のために修正されないなら、電子メールアドレスの
ローカル部を持つドメインラベルがＡＣＥプレフィックスで始まるべきでは
なく(SHOULD NOT)、そしてＡＣＥプレフィックスで始まったとしても、それ
はたまたまＡＣＥプレフィックスから始まるローカル部として解釈されるは
ずです。
4. Conversion operations
4. 変換オペレーション
An application converts a domain name put into an IDN-unaware slot or
displayed to a user. This section specifies the steps to perform in
the conversion, and the ToASCII and ToUnicode operations.
アプリケーションがＩＤＮ非対応のスロットに入っているか、あるいはユー
ザーに表示するドメイン名を変換します。この章は変換とToASCIIと
ToUnicodeオペレーションが機能する手順を指定します。
The input to ToASCII or ToUnicode is a single label that is a
sequence of Unicode code points (remember that all ASCII code points
are also Unicode code points). If a domain name is represented using
a character set other than Unicode or US-ASCII, it will first need to
be transcoded to Unicode.
ToASCIIあるいはToUnicodeへの入力は（すべてのＡＳＣＩＩコードポイント
が同じくユニコードコードポイントであることを覚えていてください）ユニ
コードコードポイントの列であるひとつのラベルです。もしドメイン名がユ
ニコードあるいは合衆国ＡＳＣＩＩ以外の文字セットを使って表されるなら、
それは最初にユニコードに変換する必要があるでしょう。
Starting from a whole domain name, the steps that an application
takes to do the conversions are:
ドメイン名全体からスタートして、アプリケーションが変換をするためにと
る手順は以下です：
1) Decide whether the domain name is a "stored string" or a "query
string" as described in [STRINGPREP]. If this conversion follows
the "queries" rule from [STRINGPREP], set the flag called
"AllowUnassigned".
1) ドメイン名が、[STRINGPREP]で記述される、「登録される文字列」かある
いは「問合せ文字列」か決定します。もしこの変換が[STRINGPREP]の「質
問」規則に従うなら、「AllowUnassigned」と呼ばれるフラグを設定して
ください。
2) Split the domain name into individual labels as described in
section 3.1. The labels do not include the separator.
2) ３.１章で記述されるように、ドメイン名を個別のラベルに分けてくださ
い。ラベルは分離記号を含みません。
3) For each label, decide whether or not to enforce the restrictions
on ASCII characters in host names [STD3]. (Applications already
faced this choice before the introduction of IDNA, and can
continue to make the decision the same way they always have; IDNA
makes no new recommendations regarding this choice.) If the
restrictions are to be enforced, set the flag called
"UseSTD3ASCIIRules" for that label.
3) 各ラベルについて、ホスト名[STD3]でＡＳＣＩＩ文字に制限を強制するべ
きかどうか決めてください。（アプリケーションがＩＤＮＡの導入の前に
すでにこの選択に直面していて、そしてその同じ方法でけっていできます；
ＩＤＮＡはこの選択に関して新しい推薦をしません。）もし制限が実施さ
れるなら、「UseSTD3ASCIIRules」と呼ばれるフラグをラベルに設定して
ください。
4) Process each label with either the ToASCII or the ToUnicode
operation as appropriate. Typically, you use the ToASCII
operation if you are about to put the name into an IDN-unaware
slot, and you use the ToUnicode operation if you are displaying
the name to a user; section 3.1 gives greater detail on the
applicable requirements.
4) 各ラベルに、ToASCIIかToUnicodeオペレーションのどちらか適切な処理を
してください。典型的に、あなたは、もしあなたがＩＤＮ非対応スロット
に名前を入れようとしているならToASCIIオペレーションを使い、そして
もしあなたがユーザーに名前を示すならToUnicodeオペレーションを使い
ます；３.１章が適用可能な条件の詳細を与えます。
5) If ToASCII was applied in step 4 and dots are used as label
separators, change all the label separators to U+002E (full stop).
5) もしToASCII がステップ４で適用され、そして点がラベル分離記号に用い
られるなら、すべてのラベル分離記号をU+002E (full stop)に変えてくだ
さい。
The following two subsections define the ToASCII and ToUnicode
operations that are used in step 4.
次の２つの章はステップ４で使われるToASCIIとToUnicodeオペレーションを
定義します。
This description of the protocol uses specific procedure names, names
of flags, and so on, in order to facilitate the specification of the
protocol. These names, as well as the actual steps of the
procedures, are not required of an implementation. In fact, any
implementation which has the same external behavior as specified in
this document conforms to this specification.
このプロトコルの記述は、プロトコルの指定を容易にするために特定の手順
名、フラグなどの名前を使います。手順の実際のステップと同様、これらの
名前は実装に要求されません。実際、この文書で指定されると同じ外部動作
の実装はこの仕様書に従てると言えます。
4.1 ToASCII
4.1 ToASCII
The ToASCII operation takes a sequence of Unicode code points that
make up one label and transforms it into a sequence of code points in
the ASCII range (0..7F). If ToASCII succeeds, the original sequence
and the resulting sequence are equivalent labels.
ToASCII演算は１枚のラベルを作るユニコードコードポイント列を入力とし、
そしてそれをＡＳＣＩＩ範囲(0..7F)のコードポイント列に変換します。もし
ToASCIIが成功するなら、元の連続と結果として生じている連続は等価なラベ
ルです。
It is important to note that the ToASCII operation can fail. ToASCII
fails if any step of it fails. If any step of the ToASCII operation
fails on any label in a domain name, that domain name MUST NOT be
used as an internationalized domain name. The method for dealing
with this failure is application-specific.
ToASCII演算が失敗することがあることを指摘することは重要です。ToASCII
は、ステップのどれかが失敗するなら、失敗します。もしToASCII演算のス
テップがドメイン名ラベル上で失敗するなら、そのドメイン名は国際化ドメ
イン名として用いられてはなりません(MUST NOT)。この失敗の扱いはアプリ
ケーション特有です。
The inputs to ToASCII are a sequence of code points, the
AllowUnassigned flag, and the UseSTD3ASCIIRules flag. The output of
ToASCII is either a sequence of ASCII code points or a failure
condition.
ToASCIIへの入力はコードポイント、AllowUnassignedフラグと
UseSTD3ASCIIRulesフラグの連続です。ToASCIIの出力はASCIIコードポイン
ト列あるいは失敗条件です。
ToASCII never alters a sequence of code points that are all in the
ASCII range to begin with (although it could fail). Applying the
ToASCII operation multiple times has exactly the same effect as
applying it just once.
ToASCIIは（失敗することがあるが）決して、初めからすべてASCII範囲にあ
るコードポイント列を変えません。何度もToASCII演算を適用することは正確
に１度適用するのと同じ効果を持っています。
ToASCII consists of the following steps:
ToASCIIは次のステップから成り立ちます：
1. If the sequence contains any code points outside the ASCII range
(0..7F) then proceed to step 2, otherwise skip to step 3.
1. もし連続がＡＳＣＩＩ範囲（0〜7Ｆ）の外のコードポイントを含んでいる
なら、ステップ２に進み、さもなければステップ３にスキップします。
2. Perform the steps specified in [NAMEPREP] and fail if there is an
error. The AllowUnassigned flag is used in [NAMEPREP].
2. [NAMEPREP]で指定されたステップを行い、もしエラーがあるなら、失敗
してください。AllowUnassignedフラグは[NAMEPREP]で使われます。
3. If the UseSTD3ASCIIRules flag is set, then perform these checks:
3. もしUseSTD３ASCIIRulesフラグが設定されるなら、これらの点検を行って
ください：
(a) Verify the absence of non-LDH ASCII code points; that is, the
absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
(a) 非ＬＤＨのASCIIコードポイントがない事を実証してください；すなわ
ち、０..２Ｃ、２Ｅ..２Ｆ、３Ａ..４０、７Ｂ..７Ｆ。
(b) Verify the absence of leading and trailing hyphen-minus; that
is, the absence of U+002D at the beginning and end of the
sequence.
(b) 先頭と最後のハイフン−マイナスがないこと実証してください；すな
わち、文字列の最初と最後のU+002Dの欠如。
4. If the sequence contains any code points outside the ASCII range
(0..7F) then proceed to step 5, otherwise skip to step 8.
4. もし連続がＡＳＣＩＩ範囲（0〜7Ｆ）の外のコードポイントを含んでいる
なら、ステップ５に進み、さもなければステップ８にスキップします。
5. Verify that the sequence does NOT begin with the ACE prefix.
5. 連続がＡＣＥプレフィックスから始まらないことを確かめてください(NOT)。
6. Encode the sequence using the encoding algorithm in [PUNYCODE] and
fail if there is an error.
6. [PUNYCODE]でコーディングアルゴリズムを使って列をコード化して、もし
エラーがあるなら、失敗してください。
7. Prepend the ACE prefix.
7. ＡＣＥプレフィックスを前接続してください。
8. Verify that the number of code points is in the range 1 to 63
inclusive.
8. コードポイント数が１から６３の範囲にあることを確かめてください。
4.2 ToUnicode
4.2 ToUnicode
The ToUnicode operation takes a sequence of Unicode code points that
make up one label and returns a sequence of Unicode code points. If
the input sequence is a label in ACE form, then the result is an
equivalent internationalized label that is not in ACE form, otherwise
the original sequence is returned unaltered.
ToUnicodeオペレーションは１枚のラベルを作り上げるユニコードコードポイ
ント列を入力とし、ユニコードコードポイント列を返します。もし入力列が
ＡＣＥ形式でラベルであるなら、結果はＡＣＥ形式でない等価な国際化ラベ
ルです、さもなければ元の列は変更されずに返されます。
ToUnicode never fails. If any step fails, then the original input
sequence is returned immediately in that step.
ToUnicode は決して失敗しません。もしステップが失敗するなら、元の入力
列はそのステップですぐに返されます。
The ToUnicode output never contains more code points than its input.
Note that the number of octets needed to represent a sequence of code
points depends on the particular character encoding used.
訳注：RFC誤植情報によると上記の"The ToUnicode output never contains
more code points than its input."は誤りで"The Punycode decoder can
never output more code points than it inputs, but Nameprep can,
and therefore ToUnicode can."が正解だそうです。
プニコード解読機は入力より多くのコードポイントを出力しませんが、
Nameprepは出す事があるので、それゆえToUnicode出力は入力より多くのコー
ドポイントを出力する事があります。コードポイント列を表すために必要な
オクテット数は使用してる特定の文字列コーディングに依存することに注意
してください。
The inputs to ToUnicode are a sequence of code points, the
AllowUnassigned flag, and the UseSTD3ASCIIRules flag. The output of
ToUnicode is always a sequence of Unicode code points.
ToUnicodeへの入力はコードポイント列、AllowUnassignedフラグと
UseSTD３ASCIIRulesフラグです。ToUnicodeの出力は常にユニコードコードポ
イント列です。
1. If all code points in the sequence are in the ASCII range (0..7F)
then skip to step 3.
1. もし列のすべてのコードポイントがＡＳＣＩＩ範囲（０．．７ Ｆ)なら、
ステップ３にスキップします。
2. Perform the steps specified in [NAMEPREP] and fail if there is an
error. (If step 3 of ToASCII is also performed here, it will not
affect the overall behavior of ToUnicode, but it is not
necessary.) The AllowUnassigned flag is used in [NAMEPREP].
2. [NAMEPREP]で指定された手順を行い、もしエラーがあるなら、失敗してく
ださい。（もしToASCIIのステップ３がここで同じく行われるなら、それ
はToUnicodeの全体的な行動に影響を与えないでしょう、しかしそれは必
要ではありません。）AllowUnassignedフラグは[NAMEPREP]で使われる。
3. Verify that the sequence begins with the ACE prefix, and save a
copy of the sequence.
3. 列がＡＣＥプレフィックスから始まることを確かめて、列のコピーを保存
します。
4. Remove the ACE prefix.
4. ＡＣＥプレフィックスを取り去ります。
5. Decode the sequence using the decoding algorithm in [PUNYCODE] and
fail if there is an error. Save a copy of the result of this
step.
5. [PUNYCODE]の解読アルゴリズムを使って列を解読し、もしエラーがあるな
ら、失敗してください。このステップの結果のコピーを保存します。
6. Apply ToASCII.
6. ToASCIIを適用します。
7. Verify that the result of step 6 matches the saved copy from step
3, using a case-insensitive ASCII comparison.
7. 大文字小文字の違いを無視するＡＳＣＩＩ比較を使って、ステップ６の結
果がステップ３で保存されたコピーと一致することを確かめてください。
8. Return the saved copy from step 5.
8. ステップ５で保存されたコピーを返してください。
5. ACE prefix
5. ＡＣＥプレフィックス
The ACE prefix, used in the conversion operations (section 4), is two
alphanumeric ASCII characters followed by two hyphen-minuses. It
cannot be any of the prefixes already used in earlier documents,
which includes the following: "bl--", "bq--", "dq--", "lq--", "mq--",
"ra--", "wq--" and "zq--". The ToASCII and ToUnicode operations MUST
recognize the ACE prefix in a case-insensitive manner.
ＡＣＥプレフィックスは、変換演算（４章）で使われ、２つの英数字ＡＳＣ
ＩＩ文字に続く２つのハイフン−マイナス文字です。これは次を含むすでに
以前の文書で使われたプレフィックスのどれもありません："bl--"、"bq--"、
"dq--"、"lq--"、"mq--"、"ra--"、"wq--"、"zq--"。ToASCIIとToUnicode演
算は大文字小文字の違いを無視する方法でＡＣＥプレフィックスを認識しな
くてはなりません(MUST)。
The ACE prefix for IDNA is "xn--" or any capitalization thereof.
ＩＤＮＡのためのＡＣＥプレフィックスは"xn--"かその大文字です。
This means that an ACE label might be "xn--de-jg4avhby1noc0d", where
"de-jg4avhby1noc0d" is the part of the ACE label that is generated by
the encoding steps in [PUNYCODE].
これはＡＣＥラベルが"xn--de-jg4avhby1noc0d"かもしれないことを意味し、
そして"de-jg4avhby1noc0d"が[PUNYCODE]のコード化ステップで生成されるＡ
ＣＥラベル部分です。
While all ACE labels begin with the ACE prefix, not all labels
beginning with the ACE prefix are necessarily ACE labels. Non-ACE
labels that begin with the ACE prefix will confuse users and SHOULD
NOT be allowed in DNS zones.
すべてのＡＣＥラベルがＡＣＥプレフィックスから始まるが、すべてのＡＣ
Ｅプレフィックスから始まっているラベルが必ずＡＣＥラベルであるわけで
はありません。ＡＣＥプレフィックスから始まる非ＡＣＥラベルがユーザを
混乱させるでしょう、そしてＤＮＳゾーンで割り当てられるべきではありま
せん(SHOULD NOT)。
6. Implications for typical applications using DNS
6. DNSを使う典型的なアプリケーションのための意味
In IDNA, applications perform the processing needed to input
internationalized domain names from users, display internationalized
domain names to users, and process the inputs and outputs from DNS
and other protocols that carry domain names.
ＩＤＮＡで、アプリケーションがユーザーから国際化ドメイン名を入力し、
ユーザーに国際化ドメイン名を表示し、ＤＮＳとドメイン名を運ぶ他のプロ
トコルからの入力と出力を処理するために、必要な処理を行います。
The components and interfaces between them can be represented
pictorially as:
構成要素とそれらの間のインタフェースは以下の絵で表せます：
+------+
| User |
|ユーザ|
+------+
^
| Input and display: local interface methods
| (pen, keyboard, glowing phosphorus, ...)
| 入力と表示装置：ローカルなインタフェース方法
| （ペン、キーボード、燃えるようなリン、・・・）
+-------------------|-------------------------------+
| v |
| +-----------------------------+ |
| | Application | |
| | (ToASCII and ToUnicode | |
| | operations may be | |
| | called here) | |
| | アプリケーション | |
| | （ToASCIIとToUnicode演算 | |
| | がここで呼ばれる） | |
| +-----------------------------+ |
| ^ ^ | End system
| | | | エンドシステム
| Call to resolver: | | Application-specific |
| リゾルバ呼出: | | protocol: |
| ACE | | ACE unless the |
| v | protocol is updated |
| +----------+ | to handle other |
| | Resolver | | encodings |
| | リゾルバ | | アプリケーション特有 |
| +----------+ | プロトコル： |
| ^ | ＡＣＥプロトコルが更 |
| | | 新されないなら他のエ |
| | | ンコードを処理 |
+-----------------|----------|----------------------+
DNS protocol: | |
ＤＮＳプロトコル: | |
ACE | |
v v
+-------------+ +----------------------+
| DNS servers | | Application servers |
| ＤＮＳサーバ| |アプリケーションサーバ|
+-------------+ +----------------------+
The box labeled "Application" is where the application splits a
domain name into labels, sets the appropriate flags, and performs the
ToASCII and ToUnicode operations. This is described in section 4.
「アプリケーション」というラベルがはられているボックスは、アプリケー
ションがドメイン名をラベルに分けて、適切なフラグを設定し、そして
ToASCIIとToUnicode演算を行う所です。これは４章で記述されます。
6.1 Entry and display in applications
6.1 アプリケーションへの入力と表示
Applications can accept domain names using any character set or sets
desired by the application developer, and can display domain names in
any charset. That is, the IDNA protocol does not affect the
interface between users and applications.
アプリケーションはアプリケーション開発者が望む任意の文字セットを使っ
たドメイン名を受け入れることができ、そしてどんな文字セットのドメイン
名でも表示できます。すなわち、ＩＤＮＡプロトコルはユーザとアプリケー
ションの間のインタフェースに影響を与えません。
An IDNA-aware application can accept and display internationalized
domain names in two formats: the internationalized character set(s)
supported by the application, and as an ACE label. ACE labels that
are displayed or input MUST always include the ACE prefix.
Applications MAY allow input and display of ACE labels, but are not
encouraged to do so except as an interface for special purposes,
possibly for debugging, or to cope with display limitations as
described in section 6.4.. ACE encoding is opaque and ugly, and
should thus only be exposed to users who absolutely need it. Because
name labels encoded as ACE name labels can be rendered either as the
encoded ASCII characters or the proper decoded characters, the
application MAY have an option for the user to select the preferred
method of display; if it does, rendering the ACE SHOULD NOT be the
default.
ＩＤＮＡ対応アプリケーションが２つのフォーマットで国際化ドメイン名を
受け入れ、そして表示できます：アプリケーションによってサポートされる
国際化文字集合として、そしてＡＣＥラベルとして。表示か入力されるＡＣ
Ｅラベルは常にＡＣＥプレフィックスを含まなくてはなりません(MUST)。ア
プリケーションがＡＣＥラベルの入力と表示を許かもしれません(MAY)、しか
し多分デバッグや６.４で記述されるようにディスプレイの限界にうまく対処
するような特別な目的のインターフェースを除き、推奨されません。ＡＣＥ
コーディングはわかりにくく醜くいので、絶対的に必要とする場合にだけユー
ザに露出されるべきです。ＡＣＥでコード化された名前ラベルが、コード化
ＡＳＣＩＩ文字としても、適切な解読文字列としても、記述できできます、
アプリケーションはユーザが表示の望ましい方法を選ぶオプションを持って
いるかもしれません；もしそうなら、ＡＣＥを記述することはデフォルトで
あるべきではありません(SHOULD NOT)。
Domain names are often stored and transported in many places. For
example, they are part of documents such as mail messages and web
pages. They are transported in many parts of many protocols, such as
both the control commands and the RFC 2822 body parts of SMTP, and
the headers and the body content in HTTP. It is important to
remember that domain names appear both in domain name slots and in
the content that is passed over protocols.
ドメイン名がしばしば保管されて、そして多くの場所に送られます。例えば、
メールメッセージとＷｅｂページのような文書の一部です。ドメイン名、Ｓ
ＭＴＰの制御コマンドとＲＦＣ２８２２本体の両方や、ＨＴＴＰのヘッダや
本体のコンテンツなど、多くのプロトコルの多くの部分で送られます。ドメ
イン名が、ドメイン名スロットと、プロトコル上で渡される内容の、両方で
現われることを覚えていることは重要です。
In protocols and document formats that define how to handle
specification or negotiation of charsets, labels can be encoded in
any charset allowed by the protocol or document format. If a
protocol or document format only allows one charset, the labels MUST
be given in that charset.
どのように仕様を扱うか、又は、文字セットを交渉するかのプロトコルや文
書フォーマットで、プロトコルや文書フォーマットが許す任意の文字セット
でラベルをコーディングできます。もしプロトコルあるいは文書フォーマッ
トがただ１つの文字セットを許すだけであるなら、ラベルはその文字セット
で与えられなくてはなりません(MUST)。
In any place where a protocol or document format allows transmission
of the characters in internationalized labels, internationalized
labels SHOULD be transmitted using whatever character encoding and
escape mechanism that the protocol or document format uses at that
place.
プロトコルあるいは文書フォーマットが国際化ラベルの文字の送信を許す所
では、国際化ラベルは、プロトコルや文書フォーマットがその場所で許す文
字コーディングとエスケープ機構を何でも使って伝達されるべきです(SHOULD)。
All protocols that use domain name slots already have the capacity
for handling domain names in the ASCII charset. Thus, ACE labels
(internationalized labels that have been processed with the ToASCII
operation) can inherently be handled by those protocols.
すでにドメイン名スロットを使っているすべてのプロトコルは、ＡＳＣＩＩ
文字セットのドメイン名を処理する能力を持っています。それで、ＡＣＥラ
ベル（ToASCII演算で処理された国際化ラベル）が本質的にそれらのプロト
コルで処理できます。
6.2 Applications and resolver libraries
6.2 アプリケーションとリゾルバライブラリ
Applications normally use functions in the operating system when they
resolve DNS queries. Those functions in the operating system are
often called "the resolver library", and the applications communicate
with the resolver libraries through a programming interface (API).
アプリケーションがＤＮＳの質問を解決する時、通常オペレーティング・シ
ステム機能を使います。それらのオペレーティング・システム機能はしばし
ば「リゾルバライブラリ」と呼ばれます、そしてアプリケーションはプログ
ラムインタフェース（ＡＰＩ）を通してリゾルバライブラリと通信します。
Because these resolver libraries today expect only domain names in
ASCII, applications MUST prepare labels that are passed to the
resolver library using the ToASCII operation. Labels received from
the resolver library contain only ASCII characters; internationalized
labels that cannot be represented directly in ASCII use the ACE form.
ACE labels always include the ACE prefix.
これらのリゾルバライブラリは今日ＡＳＣＩＩドメイン名だけを予想するか
ら、アプリケーションがToASCII演算を使ってリゾルバライブラリに渡される
ラベルの前処理をしなくてはなりません(MUST)。リゾルバライブラリから受
け取られたラベルがＡＳＣＩＩ文字だけを含んでいます；ＡＥＣＩＩで直接
表現できない国際化ラベルがＡＣＥ形式を使います。ＡＣＥラベルが常にＡ
ＣＥプレフィックスを含みます。
An operating system might have a set of libraries for performing the
ToASCII operation. The input to such a library might be in one or
more charsets that are used in applications (UTF-8 and UTF-16 are
likely candidates for almost any operating system, and script-
specific charsets are likely for localized operating systems).
オペレーティング・システムがToASCII演算を行うライブラリを持っているか
もしれません。このようなライブラリへの入力はアプリケーションで使用す
る１つ以上の文字セットかもしれません（ＵＴＦ−８とＵＴＦ−１６がほと
んどのオペレーティング・システムでの有望な候補で、スクリプト特有の文
字セットがローカライズしたオペレーティング・システムで有望です）。
IDNA-aware applications MUST be able to work with both non-
internationalized labels (those that conform to [STD13] and [STD3])
and internationalized labels.
ＩＤＮＡ対応アプリケーションは、国際化されないラベル（[STD13]と[STD3]
に従う）と国際化ラベルの両方で働くことができなければなりません(MUST)。
It is expected that new versions of the resolver libraries in the
future will be able to accept domain names in other charsets than
ASCII, and application developers might one day pass not only domain
names in Unicode, but also in local script to a new API for the
resolver libraries in the operating system. Thus the ToASCII and
ToUnicode operations might be performed inside these new versions of
the resolver libraries.
将来のリゾルバライブラリの新しい版がＡＳＣＩＩ以外の文字セットのドメ
イン名を受け入れることが可能であろうと思われ、そしてアプリケーション
開発者がオペレーティング・システムのリゾルバライブラリの新しいＡＰＩ
で、いつの日かユニコードのドメイン名だけでなく、ローカルスクリプトも
渡すかもしれません。それでToASCIIとToUnicode演算はこれらのリゾルバラ
イブラリの新しい版の中で行われるかもしれません。
Domain names passed to resolvers or put into the question section of
DNS requests follow the rules for "queries" from [STRINGPREP].
リゾルバに渡されたか、あるいはＤＮＳ要求の質問部に設定されたドメイン
名が[STRINGPREP]の「問合せ」のための規則に従います。
6.3 DNS servers
6.3 ＤＮＳサーバ
Domain names stored in zones follow the rules for "stored strings"
from [STRINGPREP].
ゾーンに保管されたドメイン名が[STRINGPREP]の「保管文字列」のための規
則に従います。
For internationalized labels that cannot be represented directly in
ASCII, DNS servers MUST use the ACE form produced by the ToASCII
operation. All IDNs served by DNS servers MUST contain only ASCII
characters.
ＡＳＣＩＩで直接表現できない国際化ラベルのために、ＤＮＳサーバが
ToASCII演算で生成されたＡＣＥ形式を使わなければなりません(MUST)。すべ
てのＤＮＳサーバによってサポートされたＩＤＮはＡＳＣＩＩ文字だけを含
まなくてはなりません(MUST)。
If a signaling system which makes negotiation possible between old
and new DNS clients and servers is standardized in the future, the
encoding of the query in the DNS protocol itself can be changed from
ACE to something else, such as UTF-8. The question whether or not
this should be used is, however, a separate problem and is not
discussed in this memo.
もし旧式と新規のＤＮＳクライアントとサーバ間の交渉を可能にする信号シ
ステムが将来標準化されるなら、ＤＮＳプロトコル自身の問合せのコーディ
ングはＡＣＥから、ＵＴＦ−８のような、他の何かに変えることができます。
これが使われるべきかどうかの質問は、しかしながら、別の問題で、この文
書で論じられません。
6.4 Avoiding exposing users to the raw ACE encoding
6.4 生のＡＣＥコーディングをユーザに曝すのを避ける
Any application that might show the user a domain name obtained from
a domain name slot, such as from gethostbyaddr or part of a mail
header, will need to be updated if it is to prevent users from seeing
the ACE.
gethostbyaddrやメールヘッダの一部などの、ドメイン名スロットから得たド
メイン名をユーザに見せるアプリケーションは、もしユーザがＡＣＥを見る
のを阻止するなら、更新される必要があるでしょう。
If an application decodes an ACE name using ToUnicode but cannot show
all of the characters in the decoded name, such as if the name
contains characters that the output system cannot display, the
application SHOULD show the name in ACE format (which always includes
the ACE prefix) instead of displaying the name with the replacement
character (U+FFFD). This is to make it easier for the user to
transfer the name correctly to other programs. Programs that by
default show the ACE form when they cannot show all the characters in
a name label SHOULD also have a mechanism to show the name that is
produced by the ToUnicode operation with as many characters as
possible and replacement characters in the positions where characters
cannot be displayed.
もしToUnicodeを使ってＡＣＥ名を解読するアプリケーションが 、名前に出
力システムが表示できない文字を含んでいるなど、解読された名前の全ての
文字の表示が可能でないなら、アプリケーションは置き換え文字(U+FFFD)で
名前を示すのではなく、（常にＡＣＥプレフィックスを含む）ＡＣＥフォー
マットで名前を示すべきです(SHOULD)。これはユーザが他のプログラムに正
確に名前を転送することをより容易にするはずです。デフォルトで、名前ラ
ベルのすべての文字を表示できない場合にＡＣＥ形式で表示するプログラム
が、ToUnicode演算によって作り出される名前を表示するために、できるかぎ
りの文字を表示し、表示できない文字を置き換え文字で表示するメカニズム
も持つべきです(SHOULD)。
The ToUnicode operation does not alter labels that are not valid ACE
labels, even if they begin with the ACE prefix. After ToUnicode has
been applied, if a label still begins with the ACE prefix, then it is
not a valid ACE label, and is not equivalent to any of the
intermediate Unicode strings constructed by ToUnicode.
ToUnicode演算は、たとえそれらがＡＣＥプレフィックスから始まるとしても、
正当でないＡＣＥラベルを変更しません。ToUnicodeが適用された後に、もし
ラベルがまだＡＣＥプレフィックスから始まるなら、それは正当なＡＣＥラ
ベルでなく、そしてToUnicodeによって生成された中間ユニコード文字列のど
れとも等しくありません。
6.5 DNSSEC authentication of IDN domain names
6.5 ＩＤＮドメイン名のＤＮＳＳＥＣ認証
DNS Security [RFC2535] is a method for supplying cryptographic
verification information along with DNS messages. Public Key
Cryptography is used in conjunction with digital signatures to
provide a means for a requester of domain information to authenticate
the source of the data. This ensures that it can be traced back to a
trusted source, either directly, or via a chain of trust linking the
source of the information to the top of the DNS hierarchy.
ＤＮＳセキュリティ[RFC2535]はＤＮＳメッセージとともに暗号証明情報を供
給する方法です。ドメイン情報の要求者がデータ源認証をする手段を供給す
るために、公開鍵暗号がディジタル署名と関連して使われます。これは直接
あるいは情報源をＤＮＳ階層の頂上にリンクする信頼鎖によって、信頼でき
る情報源への追跡を保証します。
IDNA specifies that all internationalized domain names served by DNS
servers that cannot be represented directly in ASCII must use the ACE
form produced by the ToASCII operation. This operation must be
performed prior to a zone being signed by the private key for that
zone. Because of this ordering, it is important to recognize that
DNSSEC authenticates the ASCII domain name, not the Unicode form or
the mapping between the Unicode form and the ASCII form. In the
presence of DNSSEC, this is the name that MUST be signed in the zone
and MUST be validated against.
ＤＮＳサーバでサポートされた、すべてのＡＳＣＩＩで直接表現できない、
国際化ドメイン名について、ＩＤＮＡは、ToASCII演算によって生成したＡＣ
Ｅ形式を使わなくてはならないことを明示します。この演算はそのゾーンの
秘密鍵によってゾーンが署名される前に行われなくてはなりません。この順
序により、ＤＮＳＳＥＣがＡＳＣＩＩドメイン名を認証し、ユニコード形式
やユニコード形式からＡＳＣＩＩ形式への変更を認証しないことを認識する
ことは重要です。ＤＮＳＳＥＣで、ゾーンで署名されなくてはならなくて
(MUST)、そして逆検証されなくてはならない(MUST)名前があります。
One consequence of this for sites deploying IDNA in the presence of
DNSSEC is that any special purpose proxies or forwarders used to
transform user input into IDNs must be earlier in the resolution flow
than DNSSEC authenticating nameservers for DNSSEC to work.
ＩＤＮＡを実装しているサイトでＤＮＳＳＥＣの１つの重大性は、ユーザ入
力をＩＤＮに変換するために使ったプロキシやフォワーダは、ＤＮＳＳＥＣ
の仕事としてＤＮＳＳＥＣがネームサーバを認証するより、フロー上前にな
ければならなということです。
7. Name server considerations
7. ネームサーバの考慮
Existing DNS servers do not know the IDNA rules for handling non-
ASCII forms of IDNs, and therefore need to be shielded from them.
All existing channels through which names can enter a DNS server
database (for example, master files [STD13] and DNS update messages
[RFC2136]) are IDN-unaware because they predate IDNA, and therefore
requirement 2 of section 3.1 of this document provides the needed
shielding, by ensuring that internationalized domain names entering
DNS server databases through such channels have already been
converted to their equivalent ASCII forms.
既存のＤＮＳサーバがＩＤＮの非ＡＳＣＩＩ形式を処理するＩＤＮＡ規則を
知る必要がなく、従ってそれらから保護される必要がありません。ＤＮＳサー
バデータベースへ名前を入力する既存のチャネル（例えば、マスターファイ
ル[STD13]やＤＮＳ更新メッセージ[RFC2136]）がＩＤＮＡより前にあったた
めＩＤＮ非対応です、それゆえこの文書の３.１章の必要条件２が、このよう
なチャネルを通してＤＮＳサーバデータベースへ入力している国際化ドメイ
ン名がすでに等価なＡＳＣＩＩ形式に変換されたことを保証することで、必
要な保護を供給します。
It is imperative that there be only one ASCII encoding for a
particular domain name. Because of the design of the ToASCII and
ToUnicode operations, there are no ACE labels that decode to ASCII
labels, and therefore name servers cannot contain multiple ASCII
encodings of the same domain name.
それが特定のドメイン名でＡＳＣＩＩコーディングだけであることは必須で
す。ToASCIIとToUnicode演算のデザインのために、解読するとＡＳＣＩＩラ
ベルになるＡＣＥラベルがありません、それ故にネームサーバが同じドメイ
ン名に対して多数のＡＳＣＩＩコーディングを含むことができません。
[RFC2181] explicitly allows domain labels to contain octets beyond
the ASCII range (0..7F), and this document does not change that.
Note, however, that there is no defined interpretation of octets
80..FF as characters. If labels containing these octets are returned
to applications, unpredictable behavior could result. The ASCII form
defined by ToASCII is the only standard representation for
internationalized labels in the current DNS protocol.
[RFC2181]が明示的にドメインラベルでＡＳＣＩＩ範囲(0..7F)を超えたオク
テットを含んでいることを許し、この文書それを変えません。しかしながら、
80..FFのオクテットを文字として解釈する定義がないことに注意してくださ
い。もしこれらのオクテットを含むラベルがアプリケーションに返されるな
ら、予想できない行動が結果として生じます。ToASCIIで定義されたＡＳＣ
ＩＩ形式は現在のＤＮＳプロトコルで国際化ラベルのための唯一の標準表現
です。
8. Root server considerations
8. ルートサーバの考察
IDNs are likely to be somewhat longer than current domain names, so
the bandwidth needed by the root servers is likely to go up by a
small amount. Also, queries and responses for IDNs will probably be
somewhat longer than typical queries today, so more queries and
responses may be forced to go to TCP instead of UDP.
ＩＤＮは幾分現在のドメイン名より長い可能性が高いです、それでルートサー
バに必要とされる帯域幅は少々上昇する可能性が高いです。同じく、ＩＤＮ
のための問合せと回答は、恐らく、今日の典型的な問合せより長いでしょう、
それでより多くの問合せと回答がＵＤＰの代わりにＴＣＰで行われることを
強いられるかもしれません。
9. References
9. 参考文献
9.1 Normative References
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 Informative References
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,
<http://www.unicode.org/unicode/reports/tr9/>.
[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/).
[USASCII] Cerf, V., "ASCII format for Network Interchange", RFC
20, October 1969.
10. Security Considerations
10. セキュリティの考察
Security on the Internet partly relies on the DNS. Thus, any change
to the characteristics of the DNS can change the security of much of
the Internet.
インターネット上のセキュリティが部分的にＤＮＳに頼ります。それで、Ｄ
ＮＳ機能に対するどんな変更でもインターネットの多くのセキュリティを変
えることができます。
This memo describes an algorithm which encodes characters that are
not valid according to STD3 and STD13 into octet values that are
valid. No security issues such as string length increases or new
allowed values are introduced by the encoding process or the use of
these encoded values, apart from those introduced by the ACE encoding
itself.
この文書は、ＳＴＤ３とＳＴＤ３に従わない文字を、従うオクテット値にコー
ド化するアルゴリズムを記述します。ＡＣＥコード自身により導入されたも
のを除き、文字列長の増加や新しい許された値のようなセキュリティ問題が
コーディング処理やこれらのコード化値の使用によってもたらされません。
Domain names are used by users to identify and connect to Internet
servers. The security of the Internet is compromised if a user
entering a single internationalized name is connected to different
servers based on different interpretations of the internationalized
domain name.
ドメイン名がインターネットサーバを識別し、接続するためにユーザによっ
て使われます。インターネットのセキュリティは、もしひとつの国際化名を
入力しているユーザが、国際化ドメイン名の異なる解釈に基づく異なるサー
バに接続しているなら、危うくされます。
When systems use local character sets other than ASCII and Unicode,
this specification leaves the the problem of transcoding between the
local character set and Unicode up to the application. If different
applications (or different versions of one application) implement
different transcoding rules, they could interpret the same name
differently and contact different servers. This problem is not
solved by security protocols like TLS that do not take local
character sets into account.
システムがＡＳＣＩＩとユニコード以外のローカル文字セットを使う時、こ
の仕様書はアプリケーションでのローカル文字セットとユニコード間の変換
問題を扱いません。もし異なるアプリケーション（あるいは１つのアプリケー
ションの異なったバージョン）が異なる変換規則を実行するなら、それらは
同じ名前を違って解釈し、そして異なったサーバと連絡を取りえます。この
問題はローカル文字セットを考慮に入れないＴＬＳのようなセキュリティプ
ロトコルでは解かれません。
Because this document normatively refers to [NAMEPREP], [PUNYCODE],
and [STRINGPREP], it includes the security considerations from those
documents as well.
このこの文書が標準的に[NAMEPREP]と[PUNYCODE]と[STRINGPREP]を参照する
ので、同様にそれらの文書のセキュリティ考慮を含みます。
If or when this specification is updated to use a more recent Unicode
normalization table, the new normalization table will need to be
compared with the old to spot backwards incompatible changes. If
there are such changes, they will need to be handled somehow, or
there will be security as well as operational implications. Methods
to handle the conflicts could include keeping the old normalization,
or taking care of the conflicting characters by operational means, or
some other method.
もしこの仕様書がより最新のユニコード正規化表を使用するために更新され
る時、正規化表が古いのと比較して、後方互換性がない変更を必要とするで
しょう。もしこのような変更があるなら、それらをどうにかして処理する必
要があるか、あるいは運用上の意味でセキュリティでしょう。矛盾を処理す
る方法は、古い正常化を保持するか、あるいは運用上の手段や何か他の方法
で、矛盾する文字の面倒を見ることを含みます。
Implementations MUST NOT use more recent normalization tables than
the one referenced from this document, even though more recent tables
may be provided by operating systems. If an application is unsure of
which version of the normalization tables are in the operating
system, the application needs to include the normalization tables
itself. Using normalization tables other than the one referenced
from this specification could have security and operational
implications.
より最近の表がオペレーティング・システムによって供給されるかもしれな
いが、実装はこの文書で参照したより最新の正規化表を使ってはなりません
(MSUT NOT)。もしアプリケーションがオペレーティング・システムの正規化
表のバージョンがいずれであるか不確かであるなら、アプリケーションはそ
れ自身正規化表を含む必要があります。この仕様書で参照された以外の正規
化表を使う事は、セキュリティと運用上の意味を持ちます。
To help prevent confusion between characters that are visually
similar, it is suggested that implementations provide visual
indications where a domain name contains multiple scripts. Such
mechanisms can also be used to show when a name contains a mixture of
simplified and traditional Chinese characters, or to distinguish zero
and one from O and l. DNS zone adminstrators may impose restrictions
(subject to the limitations in section 2) that try to minimize
homographs.
視覚的に類似の文字の間に混乱を妨げるのを手伝うために、実装が多数の文
字を含むドメイン名の視覚の表示を供給することが提案されます。このよう
なメカニズムは名前が単純化中国文字と伝統的中国文字の混合を含む場合は、
あるいは零と壱をオーとエルから区別するためにも、使うことができます。
ＤＮＳゾーン管理者が、同形異義語を最小にするための制限を課すかもしれ
ません（２章の限界の適用）。
Domain names (or portions of them) are sometimes compared against a
set of privileged or anti-privileged domains. In such situations it
is especially important that the comparisons be done properly, as
specified in section 3.1 requirement 4. For labels already in ASCII
form, the proper comparison reduces to the same case-insensitive
ASCII comparison that has always been used for ASCII labels.
ドメイン名（あるいはその一部）が時々特権や非特権ドメイン集合を基準に
判断されます。このような状態で、比較が、３.１章の必要条件４で指定され
るように、正確にされることは特に重要です。すでにＡＳＣＩＩ形式のラベ
ルで、適切な比較は既にＡＳＣＩＩラベルで使われている大文字小文字の違
いを無視するＡＳＣＩＩ比較に縮退されます。
The introduction of IDNA means that any existing labels that start
with the ACE prefix and would be altered by ToUnicode will
automatically be ACE labels, and will be considered equivalent to
non-ASCII labels, whether or not that was the intent of the zone
adminstrator or registrant.
ＩＤＮＡの導入はＡＣＥプレフィックスで始まり、そしてToUnicodeにで変更
できるどんな既存のラベルでも自動的にＡＣＥラベルにします、そして、そ
れがゾーン管理者や登録人の意志であるか否かにかかわらず、非ＡＳＣＩＩ
ラベルと等価と思われるであろうことを意味します。
11. IANA Considerations
11. ＩＡＮＡの考慮
IANA has assigned the ACE prefix in consultation with the IESG.
ＩＡＮＡはＩＥＳＧと相談しＡＣＥプレフィックスを割り当てました。
12. Authors' Addresses
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/
13. Full Copyright Statement
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.
この文書とここに含む情報は無保証で供給され、そしてインターネット学会
とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、すべての保証を拒否します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。