[要約] RFC 5891は、アプリケーションにおける国際化ドメイン名（IDNA2008）のプロトコル仕様を規定しています。Unicode文字列をASCII形式のAラベルに変換し、DNSで登録および検索するための具体的な手順を定義します。IDNA2003から改善され、登録と検索のプロセスを明確に分離し、Unicodeバージョンに依存しない仕組みを導入しました。
Internet Engineering Task Force (IETF) J. Klensin
Request for Comments: 5891 August 2010
Obsoletes: 3490, 3491
Updates: 3492
Category: Standards Track
ISSN: 2070-1721
Internationalized Domain Names in Applications (IDNA): Protocol
アプリケーションの国際化ドメイン名（IDNA）：プロトコル
Abstract
概要
This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text.
このドキュメントは、国際化ドメイン名（IDN）の改訂されたプロトコル定義です。変更の理論的根拠、旧仕様との関係、および重要な用語については、他のドキュメントで説明されています。本ドキュメントでは、DNS自体への変更を必要とせずにIDNの登録と検索を行うための、アプリケーション国際化ドメイン名（IDNA）と呼ばれるプロトコルメカニズムを規定します。IDNAはドメイン名の処理のみを目的としており、自由なテキストを対象としたものではありません。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の成果物です。これはIETFコミュニティのコンセンサスを代表するものです。公開レビューを受けており、IESG（Internet Engineering Steering Group）による出版承認を受けています。インターネット標準に関する詳細は、RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5891.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc5891 で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2010 IETF Trust および文書の著者として特定された人物に帰属します。著作権はすべて留保されています。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、本ドキュメントの発行日に有効な BCP 78 および IETF Trust の IETF ドキュメントに関する法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントには、本ドキュメントに関する権利と制限が記載されているため、注意深く確認してください。本ドキュメントから抽出されたコードコンポーネントには、Trust の法的規定のセクション 4.e に記載されている Simplified BSD License のテキストを含める必要があり、同ライセンスに記載されている通り、無保証で提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開された IETF ドキュメントまたは IETF への寄稿資料が含まれている場合があります。これらの資料の一部の著作権を管理する人物が、IETF 標準プロセス外での修正を許可する権利を IETF Trust に付与していない可能性があります。そのような資料の著作権者から適切なライセンスを取得しない限り、RFCとしての出版のためのフォーマット調整や英語以外への翻訳を除き、本ドキュメントを IETF 標準プロセス外で修正したり、派生作品を作成したりすることはできません。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements and Applicability . . . . . . . . . . . . . . . . 5
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. DNS Resource Records . . . . . . . . . . . . . . . . . 6
3.2.2. Non-Domain-Name Data Types Stored in the DNS . . . . . 6
4. Registration Protocol . . . . . . . . . . . . . . . . . . . . 6
4.1. Input to IDNA Registration . . . . . . . . . . . . . . . . 7
4.2. Permitted Character and Label Validation . . . . . . . . . 7
4.2.1. Input Format . . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Rejection of Characters That Are Not Permitted . . . . 8
4.2.3. Label Validation . . . . . . . . . . . . . . . . . . . 8
4.2.4. Registration Validation Requirements . . . . . . . . . 9
4.3. Registry Restrictions . . . . . . . . . . . . . . . . . . 9
4.4. Punycode Conversion . . . . . . . . . . . . . . . . . . . 9
4.5. Insertion in the Zone . . . . . . . . . . . . . . . . . . 10
5. Domain Name Lookup Protocol . . . . . . . . . . . . . . . . . 10
5.1. Label String Input . . . . . . . . . . . . . . . . . . . . 10
5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 10
5.3. A-label Input . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Validation and Character List Testing . . . . . . . . . . 11
5.5. Punycode Conversion . . . . . . . . . . . . . . . . . . . 13
5.6. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Summary of Major Changes from IDNA2003 . . . . . . . 17
This document supplies the protocol definition for Internationalized Domain Names in Applications (IDNA), with the version specified here known as IDNA2008. Essential definitions and terminology for understanding this document and a road map of the collection of documents that make up IDNA2008 appear in a separate Definitions document [RFC5890]. Appendix A discusses the relationship between this specification and the earlier version of IDNA (referred to here as "IDNA2003"). The rationale for these changes, along with considerable explanatory material and advice to zone administrators who support IDNs, is provided in another document, known informally in this series as the "Rationale document" [RFC5894].
このドキュメントは、アプリケーションにおける国際化ドメイン名（IDNA）のプロトコル定義を提供します。ここで規定されるバージョンは IDNA2008 と呼ばれます。本ドキュメントを理解するために不可欠な定義と用語、および IDNA2008 を構成するドキュメント群のロードマップについては、別の定義ドキュメント [RFC5890] に記載されています。付録Aでは、本仕様と以前のバージョンの IDNA（「IDNA2003」と呼びます）との関係について説明します。これらの変更の理論的根拠は、IDN をサポートするゾーン管理者への説明資料やアドバイスとともに、本シリーズで非公式に「Rationaleドキュメント」[RFC5894] と呼ばれる別のドキュメントで提供されています。
IDNA works by allowing applications to use certain ASCII [ASCII] string 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 change any infrastructure. In particular, IDNA does not depend on any changes to DNS servers, resolvers, or DNS protocol elements, because the ASCII name service provided by the existing DNS can be used for IDNA.
IDNAは、アプリケーションが特定の ASCII [ASCII] 文字列ラベル（特別なプレフィックスで始まる）を使用して、非 ASCII の名前ラベルを表現できるようにすることで機能します。下位レイヤーのプロトコルはこれを認識する必要がないため、IDNAはインフラストラクチャを変更しません。特に、既存の DNS が提供する ASCII 名前サービスを IDNA に利用できるため、DNS サーバー、リゾルバー、または DNS プロトコル要素の変更に依存しません。
IDNA applies only to a specific subset of DNS labels. The base DNS standards [RFC1034] [RFC1035] and their various updates specify how to combine labels into fully-qualified domain names and parse labels out of those names.
IDNAは、DNS ラベルの特定のサブセットにのみ適用されます。基本となる DNS 標準 [RFC1034] [RFC1035] およびそれらの各種アップデートでは、ラベルを完全修飾ドメイン名に結合する方法や、それらの名前からラベルを解析する方法が規定されています。
This document describes two separate protocols, one for IDN registration (Section 4) and one for IDN lookup (Section 5). These two protocols share some terminology, reference data, and operations.
本ドキュメントでは、IDN 登録用（セクション4）と IDN 検索用（セクション5）の2つの独立したプロトコルについて説明します。これら2つのプロトコルは、一部の用語、参照データ、および操作を共有しています。
As mentioned above, terminology used as part of the definition of IDNA appears in the Definitions document [RFC5890]. It is worth noting that some of this terminology overlaps with, and is consistent with, that used in Unicode or other character set standards and the DNS. Readers of this document are assumed to be familiar with the associated Definitions document and with the DNS-specific terminology in RFC 1034 [RFC1034].
上述の通り、IDNA の定義の一部として使用される用語は、定義ドキュメント [RFC5890] に記載されています。これらの用語の一部は、Unicode や他の文字セット標準、および DNS で使用されているものと重複しており、それらと整合しています。本ドキュメントの読者は、関連する定義ドキュメントおよび RFC 1034 [RFC1034] の DNS 固有の用語に精通していることを前提としています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
本ドキュメントのキーワード「MUST」（必須）、「MUST NOT」（禁止）、「REQUIRED」（必須）、「SHALL」（しなければならない）、「SHALL NOT」（してはならない）、「SHOULD」（推奨される）、「SHOULD NOT」（推奨されない）、「RECOMMENDED」（推奨される）、「MAY」（してもよい）、「OPTIONAL」（任意）は、BCP 14、RFC 2119 [RFC2119] に記載されている通りに解釈されます。
IDNA makes the following requirements:
IDNAでは、以下の要件が定められています。
1. Whenever a domain name is put into a domain name slot that is not IDNA-aware (see Section 2.3.2.6 of the Definitions document [RFC5890]), it MUST contain only ASCII characters (i.e., its labels must be either A-labels or NR-LDH labels), unless the DNS application is not subject to historical recommendations for "hostname"-style names (see RFC 1034 [RFC1034] and Section 3.2.1).
1. ドメイン名が IDNA に対応していないドメイン名スロット（定義ドキュメント [RFC5890] のセクション 2.3.2.6 を参照）に配置される場合は常に、DNS アプリケーションが「ホスト名」形式の名前に関する従来の推奨事項（RFC 1034 [RFC1034] およびセクション 3.2.1 を参照）の対象外でない限り、ASCII 文字のみを含める必要があります（つまり、ラベルは Aラベルまたは NR-LDH ラベルのいずれかでなければなりません）。
2. Labels MUST be compared using equivalent forms: either both A-label forms or both U-label forms. Because A-labels and U-labels can be transformed into each other without loss of information, these comparisons are equivalent (however, in practice, comparison of U-labels requires first verifying that they actually are U-labels and not just Unicode strings). A pair of A-labels MUST be compared as case-insensitive ASCII (as with all comparisons of ASCII DNS labels). U-labels MUST be compared as-is, without case folding or other intermediate steps. While it is not necessary to validate labels in order to compare them, successful comparison does not imply validity. In many cases, not limited to comparison, validation may be important for other reasons and SHOULD be performed.
2. ラベルは、同等の形式（両方が Aラベル形式、または両方が Uラベル形式）を使用して比較しなければなりません。Aラベルと Uラベルは情報を失うことなく相互に変換できるため、これらの比較は同等です（ただし、実際には、Uラベルの比較には、それらが単なる Unicode 文字列ではなく、実際に Uラベルであることを事前に検証する必要があります）。Aラベルのペアは、ケースを区別しない ASCII として比較しなければなりません（すべての ASCII DNS ラベルの比較と同様です）。Uラベルは、ケースフォールディングや他の中間ステップを行わず、そのまま比較しなければなりません。比較のためにラベルを検証する必要はありませんが、比較に成功したからといって妥当性が保証されるわけではありません。多くの場合、比較に限定されず、他の理由から検証が重要になることがあり、検証を実行すべきです（SHOULD）。
3. Labels being registered MUST conform to the requirements of Section 4. Labels being looked up and the lookup process MUST conform to the requirements of Section 5.
3. 登録されるラベルは、セクション4の要件に準拠しなければなりません。検索されるラベルおよび検索プロセスは、セクション5の要件に準拠しなければなりません。
IDNA applies to all domain names in all domain name slots in protocols except where it is explicitly excluded. It does not apply to domain name slots that do not use the LDH syntax rules as described in the Definitions document [RFC5890].
IDNAは、明示的に除外されている場合を除き、プロトコル内のすべてのドメイン名スロットにおけるすべてのドメイン名に適用されます。定義ドキュメント [RFC5890] で説明されている LDH 構文ルールを使用しないドメイン名スロットには適用されません。
Because it uses the DNS, IDNA applies to many protocols that were specified before it was designed. IDNs occupying domain name slots in those older protocols MUST be in A-label form until and unless those protocols and their implementations are explicitly upgraded to be aware of IDNs and to accept the U-label form. IDNs actually appearing in DNS queries or responses MUST be A-labels.
DNS を使用するため、IDNA は設計前に規定された多くのプロトコルに適用されます。これらの古いプロトコルのドメイン名スロットを占有する IDN は、それらのプロトコルとその実装が IDN を認識し Uラベル形式を受け入れるように明示的にアップグレードされない限り、Aラベル形式でなければなりません。実際に DNS クエリやレスポンスに現れる IDN は、Aラベルでなければなりません。
IDNA-aware protocols and implementations MAY accept U-labels, A-labels, or both as those particular protocols specify. IDNA is not defined for extended label types (see RFC 2671 [RFC2671], Section 3).
IDNA対応のプロトコルおよび実装は、それらの特定のプロトコルが規定する通り、Uラベル、Aラベル、またはその両方を受け入れてもよい（MAY）です。IDNA は拡張ラベルタイプ（RFC 2671 [RFC2671] セクション3を参照）に対しては定義されていません。
IDNA applies only to domain names in the NAME and RDATA fields of DNS resource records whose CLASS is IN. See the DNS specification [RFC1035] for precise definitions of these terms.
IDNAは、クラスが IN である DNS リソースレコードの NAME フィールドおよび RDATA フィールドに含まれるドメイン名にのみ適用されます。これらの用語の正確な定義については、DNS 仕様 [RFC1035] を参照してください。
The application of IDNA to DNS resource records depends entirely on the CLASS of the record, and not on the TYPE except as noted below. This will remain true, even as new TYPEs are defined, unless a new TYPE defines TYPE-specific rules. Special naming conventions for SRV records (and "underscore labels" more generally) are incompatible with IDNA coding as discussed in the Definitions document [RFC5890], especially Section 2.3.2.3. Of course, underscore labels may be part of a domain that uses IDN labels at higher levels in the tree.
IDNA の DNS リソースレコードへの適用は、以下に述べる例外を除き、レコードのクラスにのみ依存し、タイプには依存しません。これは、新しいタイプが特定のルールを定義しない限り、新しいタイプが定義されていても変わりません。SRV レコードの特別な命名規則（およびより一般的な「アンダースコアラベル」）は、定義ドキュメント [RFC5890]（特にセクション 2.3.2.3）で説明されているように IDNA コーディングとは互換性がありません。もちろん、アンダースコアラベルは、ツリーの上位レベルで IDN ラベルを使用するドメインの一部である可能性があります。
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, specifically in the RDATA field for types that have structured RDATA format. For example, an email address local part is stored in a domain name in the RNAME field as part of the RDATA of an SOA record (e.g., hostmaster@example.com would be represented as hostmaster.example.com). IDNA does not update the existing email standards, which allow only ASCII characters in local parts. Even though work is in progress to define internationalization for email addresses [RFC4952], changes to the email address part of the SOA RDATA would require action in, or updates to, other standards, specifically those that specify the format of the SOA RR.
IDNA はドメイン名における非 ASCII 文字の表現を可能にしますが、それは IDNA がドメイン名に格納される他のデータ型（特に、構造化された RDATA 形式を持つタイプの RDATA フィールド）における非 ASCII 文字の表現を可能にすることを意味するものではありません。例えば、メールアドレスのローカル部は、SOA レコードの RDATA の一部として RNAME フィールドのドメイン名に格納されます（例：hostmaster@example.com は hostmaster.example.com として表現されます）。IDNA は、ローカル部で ASCII 文字のみを許可する既存のメール標準を更新しません。メールアドレスの国際化を定義する作業は進行中ですが [RFC4952]、SOA RDATA のメールアドレス部分の変更には、他の標準（特に SOA RR の形式を規定するもの）における対応や更新が必要になります。
This section defines the model for registering an IDN. The model is implementation independent; any sequence of steps that produces exactly the same result for all labels is considered a valid implementation.
このセクションでは、IDN を登録するためのモデルを定義します。このモデルは実装に依存しません。すべてのラベルに対してまったく同じ結果を生成する一連の手順は、有効な実装と見なされます。
Note that, while the registration (this section) and lookup protocols (Section 5) are very similar in most respects, they are not identical, and implementers should carefully follow the steps described in this specification.
登録（本セクション）と検索プロトコル（セクション5）は、ほとんどの点で非常によく似ていますが、同一ではありません。実装者は、本仕様に記載されている手順に慎重に従う必要があります。
Registration processes, especially processing by entities (often called "registrars") who deal with registrants before the request actually reaches the zone manager ("registry") are outside the scope of this definition and may differ significantly depending on local needs. By the time a string enters the IDNA registration process as described in this specification, it MUST be in Unicode and in Normalization Form C (NFC [Unicode-UAX15]). Entities responsible for zone files ("registries") MUST accept only the exact string for which registration is requested, free of any mappings or local adjustments. They MAY accept that input in any of three forms:
登録プロセス、特にリクエストが実際にゾーン管理者（「レジストリ」）に到達する前に登録者を扱うエンティティ（多くの場合「レジストラ」と呼ばれます）による処理は、本定義の範囲外であり、ローカルなニーズに応じて大きく異なる場合があります。本仕様に記載されているように、文字列が IDNA 登録プロセスに入るまでに、その文字列は Unicode かつ正規化形式C（NFC [Unicode-UAX15]）でなければなりません。ゾーンファイルを担当するエンティティ（「レジストリ」）は、マッピングやローカルな調整が行われていない、登録が要求された通りの正確な文字列のみを受け入れなければなりません（MUST）。レジストリは、以下の3つの形式のいずれかで入力を受け取ることができます。
1. As a pair of A-label and U-label.
1. Aラベルと Uラベルのペアとして。
2. As an A-label only.
2. Aラベルのみとして。
3. As a U-label only.
3. Uラベルのみとして。
The first two of these forms are RECOMMENDED because the use of A-labels avoids any possibility of ambiguity. The first is normally preferred over the second because it permits further verification of user intent (see Section 4.2.1).
これら3つの形式のうち、最初の2つが推奨されます（RECOMMENDED）。Aラベルの使用により曖昧さが回避されるためです。1つ目の形式は、ユーザーの意図をさらに検証できるため、通常は2つ目よりも好まれます（セクション 4.2.1 を参照）。
If both the U-label and A-label forms are available, the registry MUST ensure that the A-label form is in lowercase, perform a conversion to a U-label, perform the steps and tests described below on that U-label, and then verify that the A-label produced by the step in Section 4.4 matches the one provided as input. In addition, the U-label that was provided as input and the one obtained by conversion of the A-label MUST match exactly. If, for some reason, these tests fail, the registration MUST be rejected.
Uラベルと Aラベル形式の両方が利用可能な場合、レジストリは Aラベル形式が小文字であることを確認し、Uラベルへの変換を行い、その Uラベルに対して以下で説明する手順とテストを実行した上で、セクション 4.4 のステップで生成された Aラベルが入力されたものと一致することを確認しなければなりません（MUST）。さらに、入力された Uラベルと Aラベルの変換によって得られた Uラベルは、正確に一致しなければなりません（MUST）。何らかの理由でこれらのテストに失敗した場合、登録は拒否されなければなりません（MUST）。
If only an A-label was provided and the conversion to a U-label is not performed, the registry MUST still verify that the A-label is superficially valid, i.e., that it does not violate any of the rules of Punycode encoding [RFC3492] such as the prohibition on trailing hyphen-minus, the requirement that all characters be ASCII, and so on. Strings that appear to be A-labels (e.g., they start with "xn--") and strings that are supplied to the registry in a context reserved for A-labels (such as a field in a form to be filled out), but that are not valid A-labels as described in this paragraph, MUST NOT be placed in DNS zones that support IDNA.
Aラベルのみが提供され、Uラベルへの変換が行われない場合でも、レジストリは Aラベルが表面的に有効であること、すなわち、末尾のハイフンマイナスの禁止や全文字が ASCII であることの要件など、Punycode エンコーディング [RFC3492] の規則に違反していないことを検証しなければなりません（MUST）。Aラベルと思われる文字列（例：「xn--」で始まるもの）や、Aラベル専用のコンテキスト（記入フォームのフィールドなど）でレジストリに提供された文字列であっても、本項で述べる有効な Aラベルではないものは、IDNA をサポートする DNS ゾーンに配置してはなりません（MUST NOT）。
If only an A-label is provided, the conversion to a U-label is not performed, but the superficial tests described in the previous paragraph are performed, registration procedures MAY, and usually will, bypass the tests and actions in the balance of Section 4.2 and in Sections 4.3 and 4.4.
Aラベルのみが提供され、Uラベルへの変換は行われないが、前項で述べた表面的なテストが行われる場合、登録手順は、セクション 4.2 の残りのテストとアクション、およびセクション 4.3 と 4.4 をバイパスしてもよい（MAY）し、通常はバイパスすることになります。
The candidate Unicode string MUST NOT contain characters that appear in the "DISALLOWED" and "UNASSIGNED" lists specified in the Tables document [RFC5892].
候補となる Unicode 文字列には、テーブルドキュメント [RFC5892] で規定されている「DISALLOWED」（許可されない）および「UNASSIGNED」（未割り当て）のリストに含まれる文字を含めてはなりません（MUST NOT）。
The proposed label (in the form of a Unicode string, i.e., a string that at least superficially appears to be a U-label) is then examined using tests that require examination of more than one character. Character order is considered to be the on-the-wire order. That order may not be the same as the display order.
提案されたラベル（Unicode 文字列の形式、すなわち、少なくとも表面的には Uラベルに見える文字列）は、次に、複数の文字の検査を必要とするテストによって検査されます。文字の順序は、ネットワーク上の転送順序（on-the-wire order）であるとみなされます。この順序は表示順序と同じではない場合があります。
The Unicode string MUST NOT contain "--" (two consecutive hyphens) in the third and fourth character positions and MUST NOT start or end with a "-" (hyphen).
Unicode 文字列は、3番目と4番目の文字位置に「--」（2つの連続したハイフン）を含んではならず（MUST NOT）、また「-」（ハイフン）で始まったり終わったりしてはなりません（MUST NOT）。
The Unicode string MUST NOT begin with a combining mark or combining character (see The Unicode Standard, Section 2.11 [Unicode] for an exact definition).
Unicode 文字列は、結合マークまたは結合文字で始まってはなりません（MUST NOT）。正確な定義については、Unicode 標準のセクション 2.11 [Unicode] を参照してください。
The Unicode string MUST NOT contain any characters whose validity is context-dependent, unless the validity is positively confirmed by a contextual rule. To check this, each code point identified as CONTEXTJ or CONTEXTO in the Tables document [RFC5892] MUST have a non-null rule. If such a code point is missing a rule, the label is invalid. If the rule exists but the result of applying the rule is negative or inconclusive, the proposed label is invalid.
Unicode 文字列には、文脈依存（context-dependent）の妥当性を持つ文字を含めてはなりません。ただし、文脈ルールによって妥当性が肯定的に確認された場合は除きます。これを確認するために、テーブルドキュメント [RFC5892] で CONTEXTJ または CONTEXTO と識別される各コードポイントには、NULL ではないルールが設定されていなければなりません（MUST）。そのようなコードポイントにルールがない場合、そのラベルは無効です。ルールは存在するが、ルールを適用した結果が否定的または決定的でない場合、提案されたラベルは無効です。
If the proposed label contains any characters from scripts that are written from right to left, it MUST meet the Bidi criteria [RFC5893].
提案されたラベルに、右から左に書かれるスクリプトの文字が含まれている場合、それは Bidi 基準 [RFC5893] を満たさなければなりません（MUST）。
Strings that contain at least one non-ASCII character, have been produced by the steps above, whose contents pass all of the tests in Section 4.2.3, and are 63 or fewer characters long in ASCII-compatible encoding (ACE) form (see Section 4.4), are U-labels.
少なくとも1つの非 ASCII 文字を含み、上述の手順によって生成され、その内容がセクション 4.2.3 のすべてのテストに合格し、ASCII 互換エンコーディング（ACE）形式（セクション 4.4 を参照）で 63 文字以下である文字列は、Uラベルです。
To summarize, tests are made in Section 4.2 for invalid characters, invalid combinations of characters, for labels that are invalid even if the characters they contain are valid individually, and for labels that do not conform to the restrictions for strings containing right-to-left characters.
要約すると、セクション 4.2 では、無効な文字、無効な文字の組み合わせ、含まれる文字が個別に有効であってもラベルとしては無効なもの、および右から左に書く文字を含む文字列の制限に準拠していないラベルについてのテストが行われます。
In addition to the rules and tests above, there are many reasons why a registry could reject a label. Registries at all levels of the DNS, not just the top level, are expected to establish policies about label registrations. Policies are likely to be informed by the local languages and the scripts that are used to write them and may depend on many factors including what characters are in the label (for example, a label may be rejected based on other labels already registered). See the Rationale document [RFC5894], Section 3.2, for further discussion and recommendations about registry policies.
上記の規則とテストに加えて、レジストリがラベルを拒否する理由は数多く存在します。トップレベルだけでなく、DNS のすべてのレベルのレジストリにおいて、ラベル登録に関するポリシーを確立することが期待されています。ポリシーは、現地の言語やそれらを書くために使用されるスクリプトに基づいて決定される可能性が高く、ラベルに含まれる文字の種類（例えば、既に登録されている他のラベルに基づいて拒否されるなど）を含む多くの要因に依存する場合があります。レジストリポリシーに関するさらなる議論と推奨事項については、Rationale ドキュメント [RFC5894] のセクション 3.2 を参照してください。
The string produced by the steps in Section 4.2 is checked and processed as appropriate to local registry restrictions. Application of those registry restrictions may result in the rejection of some labels or the application of special restrictions to others.
セクション 4.2 の手順で生成された文字列は、現地のレジストリ制限に従って適切にチェックおよび処理されます。これらのレジストリ制限の適用により、一部のラベルが拒否されたり、他のラベルに特別な制限が適用されたりする場合があります。
The resulting U-label is converted to an A-label (defined in Section 2.3.2.1 of the Definitions document [RFC5890]). The A-label is the encoding of the U-label according to the Punycode algorithm [RFC3492] with the ACE prefix "xn--" added at the beginning of the string. The resulting string must, of course, conform to the length limits imposed by the DNS. This document does not update or alter the Punycode algorithm specified in RFC 3492 in any way. RFC 3492 does make a non-normative reference to the information about the value and construction of the ACE prefix that appears in RFC 3490 or Nameprep [RFC3491]. For consistency and reader convenience, IDNA2008 effectively updates that reference to point to this document. That change does not alter the prefix itself. The prefix, "xn--", is the same in both sets of documents.
得られた Uラベルは Aラベル（定義ドキュメント [RFC5890] のセクション 2.3.2.1 で定義）に変換されます。Aラベルは、Punycode アルゴリズム [RFC3492] に従った Uラベルのエンコーディングであり、文字列の先頭に ACE プレフィックス「xn--」が付加されます。生成された文字列は、当然ながら DNS によって課される長さ制限に準拠しなければなりません。本ドキュメントは、RFC 3492 で規定されている Punycode アルゴリズムをいかなる形でも更新または変更するものではありません。RFC 3492 は、RFC 3490 または Nameprep [RFC3491] に記載されている ACE プレフィックスの値と構成に関する情報について、非規範的な参照を行っています。整合性と読者の利便性のために、IDNA2008 はその参照先を本ドキュメントに実質的に更新します。この変更によってプレフィックス自体が変更されることはありません。プレフィックス「xn--」は、両方のドキュメントセットで同じです。
With the exception of the maximum string length test on Punycode output, the failure conditions identified in the Punycode encoding procedure cannot occur if the input is a U-label as determined by the steps in Sections 4.1 through 4.3 above.
Punycode 出力に対する最大文字列長のテストを除き、入力が上記のセクション 4.1 から 4.3 の手順で決定された Uラベルである場合、Punycode エンコーディング手順で特定されている失敗条件が発生することはありません。
The label is registered in the DNS by inserting the A-label into a zone.
ラベルは、Aラベルをゾーンに挿入することによって DNS に登録されます。
Lookup is different from registration and different tests are applied on the client. Although some validity checks are necessary to avoid serious problems with the protocol, the lookup-side tests are more permissive and rely on the assumption that names that are present in the DNS are valid. That assumption is, however, a weak one because the presence of wildcards in the DNS might cause a string that is not actually registered in the DNS to be successfully looked up.
検索（Lookup）は登録とは異なり、クライアント側で異なるテストが適用されます。プロトコルの深刻な問題を回避するためにいくつかの妥当性チェックが必要ですが、検索側のテストはより寛容であり、DNS に存在する名前は有効であるという仮定に基づいています。しかし、その仮定は脆弱なものです。なぜなら、DNS にワイルドカードが存在すると、実際には DNS に登録されていない文字列が正常に検索されてしまう可能性があるからです。
The user supplies a string in the local character set, for example, by typing it, clicking on it, or copying and pasting it from a resource identifier, e.g., a Uniform Resource Identifier (URI) [RFC3986] or an Internationalized Resource Identifier (IRI) [RFC3987], from which the domain name is extracted. Alternately, some process not directly involving the user may read the string from a file or obtain it in some other way. Processing in this step and the one specified in Section 5.2 are local matters, to be accomplished prior to actual invocation of IDNA.
ユーザーは、例えば、ドメイン名を抽出したリソース識別子（一様リソース識別子 (URI) [RFC3986] や国際化リソース識別子 (IRI) [RFC3987] など）から、文字列を入力したり、クリックしたり、コピー＆ペーストしたりすることで、ローカルな文字セットの文字列を提供します。あるいは、ユーザーが直接関与しないプロセスが、ファイルから文字列を読み取ったり、他の方法で取得したりする場合もあります。このステップおよびセクション 5.2 で規定されている処理はローカルな事項であり、IDNA の実際の呼び出し前に完了させる必要があります。
The string is converted from the local character set into Unicode, if it is not already in Unicode. Depending on local needs, this conversion may involve mapping some characters into other characters as well as coding conversions. Those issues are discussed in the mapping-related sections (Sections 4.2, 4.4, 6, and 7.3) of the Rationale document [RFC5894] and in the separate Mapping document [IDNA2008-Mapping]. The result MUST be a Unicode string in NFC form.
文字列がまだ Unicode でない場合は、ローカルな文字セットから Unicode に変換されます。ローカルなニーズに応じて、この変換には、一部の文字を他の文字にマッピングすることや、符号化の変換が含まれる場合があります。これらの問題については、Rationale ドキュメント [RFC5894] のマッピング関連のセクション（セクション 4.2、4.4、6、7.3）および別の Mapping ドキュメント [IDNA2008-Mapping] で議論されています。結果は、NFC 形式の Unicode 文字列でなければなりません（MUST）。
If the input to this procedure appears to be an A-label (i.e., it starts in "xn--", interpreted case-insensitively), the lookup application MAY attempt to convert it to a U-label, first ensuring that the A-label is entirely in lowercase (converting it to lowercase if necessary), and apply the tests of Section 5.4 and the conversion of Section 5.5 to that form. If the label is converted to Unicode (i.e., to U-label form) using the Punycode decoding algorithm, then the processing specified in those two sections MUST be performed, and the label MUST be rejected if the resulting label is not identical to the original. See Section 8.1 of the Rationale document [RFC5894] for additional discussion on this topic.
本手順への入力が Aラベルのように見える（すなわち、大文字小文字を区別せずに解釈して「xn--」で始まる）場合、検索アプリケーションはそれを Uラベルへの変換を試みてもよい（MAY）です。その際、まず Aラベルが完全に小文字であることを確認し（必要に応じて小文字に変換）、セクション 5.4 のテストとセクション 5.5 の変換をその形式に適用します。ラベルが Punycode デコーディングアルゴリズムを使用して Unicode（すなわち Uラベル形式）に変換される場合、これら2つのセクションで規定されている処理を実行しなければならず（MUST）、生成されたラベルが元のラベルと同一でない場合は、そのラベルを拒否しなければなりません（MUST）。このトピックに関する追加の議論については、Rationale ドキュメント [RFC5894] のセクション 8.1 を参照してください。
Conversion from the A-label and testing that the result is a U-label SHOULD be performed if the domain name will later be presented to the user in native character form (this requires that the lookup application be IDNA-aware). If those steps are not performed, the lookup process SHOULD at least test to determine that the string is actually an A-label, examining it for the invalid formats specified in the Punycode decoding specification. Applications that are not IDNA-aware will obviously omit that testing; others MAY treat the string as opaque to avoid the additional processing at the expense of providing less protection and information to users.
ドメイン名が後でネイティブな文字形式でユーザーに提示される場合（これには、検索アプリケーションが IDNA に対応している必要があります）、Aラベルからの変換と、結果が Uラベルであることのテストを実行すべきです（SHOULD）。これらの手順が実行されない場合、検索プロセスは、少なくともその文字列が実際に Aラベルであるかどうかをテストし、Punycode デコーディング仕様で規定されている無効な形式がないか検査すべきです（SHOULD）。IDNA に対応していないアプリケーションは、当然ながらそのテストを省略します。それ以外のアプリケーションは、ユーザーへの保護や情報の提供が不十分になるという代償を払って、追加の処理を避けるために文字列を不透明なものとして扱ってもよい（MAY）です。
As with the registration procedure described in Section 4, the Unicode string is checked to verify that all characters that appear in it are valid as input to IDNA lookup processing. As discussed above and in the Rationale document [RFC5894], the lookup check is more liberal than the registration one. Labels that have not been fully evaluated for conformance to the applicable rules are referred to as "putative" labels as discussed in Section 2.3.2.1 of the Definitions document [RFC5890]. Putative U-labels with any of the following characteristics MUST be rejected prior to DNS lookup:
セクション 4 で説明した登録手順と同様に、Unicode 文字列は、そこに含まれるすべての文字が IDNA 検索処理への入力として有効であることを検証するためにチェックされます。前述のとおり、また Rationale ドキュメント [RFC5894] で議論されているとおり、検索時のチェックは登録時のチェックよりも寛容です。適用される規則への準拠性が完全には評価されていないラベルは、定義ドキュメント [RFC5890] のセクション 2.3.2.1 で議論されているように「推定（putative）」ラベルと呼ばれます。以下の特性のいずれかを持つ推定 Uラベルは、DNS 検索の前に拒否されなければなりません（MUST）。
o Labels that are not in NFC [Unicode-UAX15].
o NFC [Unicode-UAX15] 形式ではないラベル。
o Labels containing "--" (two consecutive hyphens) in the third and fourth character positions.
o 3番目と4番目の文字位置に「--」（2つの連続したハイフン）を含むラベル。
o Labels whose first character is a combining mark (see The Unicode Standard, Section 2.11 [Unicode]).
o 先頭文字が結合マーク（The Unicode Standard セクション 2.11 [Unicode] を参照）であるラベル。
o Labels containing prohibited code points, i.e., those that are assigned to the "DISALLOWED" category of the Tables document [RFC5892].
o 禁止されたコードポイント、すなわちテーブルドキュメント [RFC5892] の「DISALLOWED」カテゴリに割り当てられたコードポイントを含むラベル。
o Labels containing code points that are identified in the Tables document as "CONTEXTJ", i.e., requiring exceptional contextual rule processing on lookup, but that do not conform to those rules. Note that this implies that a rule must be defined, not null: a character that requires a contextual rule but for which the rule is null is treated in this step as having failed to conform to the rule.
o テーブルドキュメントで「CONTEXTJ」として識別されるコードポイントを含むラベル、すなわち検索時に例外的な文脈ルール処理が必要であるが、それらのルールに準拠していないもの。これには、ルールが定義されていなければならず（NULL ではいけない）、文脈ルールを必要とする文字に対してルールが NULL である場合は、このステップでルールに準拠していないとみなされることを意味します。
o Labels containing code points that are identified in the Tables document as "CONTEXTO", but for which no such rule appears in the table of rules. Applications resolving DNS names or carrying out equivalent operations are not required to test contextual rules for "CONTEXTO" characters, only to verify that a rule is defined (although they MAY make such tests to provide better protection or give better information to the user).
o テーブルドキュメントで「CONTEXTO」として識別されるコードポイントを含むラベルであるが、ルールテーブルにそのようなルールが存在しないもの。DNS 名を解決したり、同等の操作を実行したりするアプリケーションは、「CONTEXTO」文字に対する文脈ルールをテストする必要はなく、ルールが定義されていることを確認するだけで十分です（ただし、より良い保護を提供したり、ユーザーにより良い情報を提供したりするために、そのようなテストを行ってもよい (MAY) です）。
o Labels containing code points that are unassigned in the version of Unicode being used by the application, i.e., in the UNASSIGNED category of the Tables document.
o アプリケーションで使用されている Unicode のバージョンにおいて未割り当てであるコードポイント、すなわちテーブルドキュメントの「UNASSIGNED」カテゴリに含まれるコードポイントを含むラベル。
This requirement means that the application must use a list of unassigned characters that is matched to the version of Unicode that is being used for the other requirements in this section. It is not required that the application know which version of Unicode is being used; that information might be part of the operating environment in which the application is running.
この要件は、アプリケーションが、本セクションの他の要件に使用されている Unicode のバージョンに適合した未割り当て文字のリストを使用しなければならないことを意味します。アプリケーションがどのバージョンの Unicode を使用しているかを知っている必要はありません。その情報は、アプリケーションが実行されているオペレーティング環境の一部である場合があります。
In addition, the application SHOULD apply the following test.
さらに、アプリケーションは以下のテストを適用すべきです（SHOULD）。
o Verification that the string is compliant with the requirements for right-to-left characters specified in the Bidi document [RFC5893].
o 文字列が、Bidi ドキュメント [RFC5893] で規定されている右から左に書く文字の要件に準拠していることの検証。
This test may be omitted in special circumstances, such as when the lookup application knows that the conditions are enforced elsewhere, because an attempt to look up and resolve such strings will almost certainly lead to a DNS lookup failure except when wildcards are present in the zone. However, applying the test is likely to give much better information about the reason for a lookup failure -- information that may be usefully passed to the user when that is feasible -- than DNS resolution failure information alone.
このテストは、検索アプリケーションが条件が他で強制されていることを知っている場合などの特別な状況では省略されることがありますが、そのような文字列を検索・解決しようとすると、ゾーン内にワイルドカードが存在する場合を除き、ほぼ確実に DNS 検索に失敗します。しかし、テストを適用することは、単なる DNS 解決の失敗情報よりも、検索に失敗した理由に関するより良い情報（可能であればユーザーに有益に伝えられる情報）を提供する可能性が高いです。
For all other strings, the lookup application MUST rely on the presence or absence of labels in the DNS to determine the validity of those labels and the validity of the characters they contain. If they are registered, they are presumed to be valid; if they are not, their possible validity is not relevant. While a lookup application may reasonably issue warnings about strings it believes may be problematic, applications that decline to process a string that conforms to the rules above (i.e., does not look it up in the DNS) are not in conformance with this protocol.
他のすべての文字列について、検索アプリケーションは、それらのラベルの妥当性および含まれる文字の妥当性を判断するために、DNS におけるラベルの有無に依存しなければなりません（MUST）。それらが登録されている場合は妥当であると推定され、そうでない場合はそれらの妥当性の可能性は無関係です。検索アプリケーションが、問題があると思われる文字列について警告を発することは合理的ですが、上記の規則に準拠している文字列の処理を拒否する（すなわち、DNS で検索しない）アプリケーションは、本プロトコルに準拠していません。
The string that has now been validated for lookup is converted to ACE form by applying the Punycode algorithm to the string and then adding the ACE prefix ("xn--").
検索のために検証された文字列は、Punycode アルゴリズムを適用し、ACE プレフィックス（「xn--」）を付加することによって ACE 形式に変換されます。
The A-label resulting from the conversion in Section 5.5 or supplied directly (see Section 5.3) is combined with other labels as needed to form a fully-qualified domain name that is then looked up in the DNS, using normal DNS resolver procedures. The lookup can obviously either succeed (returning information) or fail.
セクション 5.5 の変換から得られた、あるいは直接提供された（セクション 5.3 を参照） Aラベルは、必要に応じて他のラベルと組み合わされて完全修飾ドメイン名を形成し、通常の DNS リゾルバー手順を使用して DNS で検索されます。検索は当然、成功して情報を返すか、失敗するかのいずれかになります。
Security Considerations for this version of IDNA are described in the Definitions document [RFC5890], except for the special issues associated with right-to-left scripts and characters. The latter are discussed in the Bidi document [RFC5893].
本バージョンの IDNA に関するセキュリティの考慮事項は、右から左に書くスクリプトや文字に関連する特別な問題を除き、定義ドキュメント [RFC5890] に記載されています。後者については Bidi ドキュメント [RFC5893] で議論されています。
In order to avoid intentional or accidental attacks from labels that might be confused with others, special problems in rendering, and so on, the IDNA model requires that registries exercise care and thoughtfulness about what labels they choose to permit. That issue is discussed in Section 4.3 of this document which, in turn, points to a somewhat more extensive discussion in the Rationale document [RFC5894].
他と混同される可能性のあるラベルによる意図的または偶発的な攻撃や、レンダリング上の特別な問題などを回避するために、IDNA モデルでは、レジストリが許可するラベルの選択に際して注意と配慮を払うことが求められます。この問題については、本ドキュメントのセクション 4.3 で議論されており、そこから Rationale ドキュメント [RFC5894] におけるより詳細な議論が参照されています。
IANA actions for this version of IDNA are specified in the Tables document [RFC5892] and discussed informally in the Rationale document [RFC5894]. The components of IDNA described in this document do not require any IANA actions.
本バージョンの IDNA に対する IANA のアクションは、テーブルドキュメント [RFC5892] で規定され、Rationale ドキュメント [RFC5894] で非公式に議論されています。本ドキュメントで説明されている IDNA のコンポーネントは、いかなる IANA アクションも必要としません。
While the listed editor held the pen, the original versions of this document represent the joint work and conclusions of an ad hoc design team consisting of the editor and, in alphabetic order, Harald Alvestrand, Tina Dam, Patrik Faltstrom, and Cary Karp. This document draws significantly on the original version of IDNA [RFC3490] both conceptually and for specific text. This second-generation version would not have been possible without the work that went into that first version and especially the contributions of its authors Patrik Faltstrom, Paul Hoffman, and Adam Costello. While Faltstrom was actively involved in the creation of this version, Hoffman and Costello were not and should not be held responsible for any errors or omissions.
記載されている編集者が執筆を担当しましたが、本ドキュメントのオリジナルバージョンは、編集者およびアルファベット順に Harald Alvestrand、Tina Dam、Patrik Faltstrom、Cary Karp からなるアドホック設計チームの共同作業と結論を代表するものです。本ドキュメントは、概念および特定のテキストの両面で、IDNA [RFC3490] のオリジナルバージョンに大きく依拠しています。この第二世代のバージョンは、第一世代のバージョンにおける多大な労力、特にその著者である Patrik Faltstrom、Paul Hoffman、Adam Costello の貢献なしには不可能でした。Faltstrom は本バージョンの作成に積極的に関与しましたが、Hoffman と Costello は関与しておらず、いかなる誤りや脱落についても責任を負うものではありません。
This revision to IDNA would have been impossible without the accumulated experience since RFC 3490 was published and resulting comments and complaints of many people in the IETF, ICANN, and other communities (too many people to list here). Nor would it have been possible without RFC 3490 itself and the efforts of the Working Group that defined it. Those people whose contributions are acknowledged in RFC 3490, RFC 4690 [RFC4690], and the Rationale document [RFC5894] were particularly important.
IDNA の今回の改訂は、RFC 3490 の公開以来蓄積された経験、および IETF、ICANN、その他のコミュニティの多くの人々（ここにリストするには多すぎます）からのコメントや苦情なしには不可能でした。また、RFC 3490 自体と、それを定義したワーキンググループの努力も不可欠でした。RFC 3490、RFC 4690 [RFC4690]、および Rationale ドキュメント [RFC5894] で貢献が認められている人々は、特に重要な役割を果たしました。
Specific textual changes were incorporated into this document after suggestions from the other contributors, Stephane Bortzmeyer, Vint Cerf, Lisa Dusseault, Paul Hoffman, Kent Karlsson, James Mitchell, Erik van der Poel, Marcos Sanz, Andrew Sullivan, Wil Tan, Ken Whistler, Chris Wright, and other WG participants and reviewers including Martin Duerst, James Mitchell, Subramanian Moonesamy, Peter Saint-Andre, Margaret Wasserman, and Dan Winship who caught specific errors and recommended corrections. Special thanks are due to Paul Hoffman for permission to extract material to form the basis for Appendix A from a draft document that he prepared.
他の貢献者である Stephane Bortzmeyer、Vint Cerf、Lisa Dusseault、Paul Hoffman、Kent Karlsson、James Mitchell、Erik van der Poel、Marcos Sanz、Andrew Sullivan、Wil Tan、Ken Whistler、Chris Wright、および特定の誤りを発見して修正を推奨した Martin Duerst、James Mitchell、Subramanian Moonesamy、Peter Saint-Andre、Margaret Wasserman、Dan Winship を含む他の WG 参加者や査読者からの提案を受けて、特定のテキストの変更が本ドキュメントに組み込まれました。Paul Hoffman 氏が、彼が作成したドラフトドキュメントから付録Aの基礎となる資料を抽出することを許可してくれたことに、特別な感謝を捧げます。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P., 「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P., 「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S., 「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492] Costello、A., 「Punycode：Applications（IDNA）の国際化ドメイン名のUnicodeのブートストリングエンコーディング」、RFC 3492、2003年3月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]クレンシン、J., 「アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク」、RFC 5890、2010年8月。
[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010.
[RFC5892] Faltstrom、P.、ed., 「Unicodeコードポイントとアプリケーションの国際化ドメイン名（IDNA）」、RFC 5892、2010年8月。
[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010.
[RFC5893] Alvestrand、H.、ed。およびC. Karp、「アプリケーションの国際化されたドメイン名（IDNA）の左から左へのスクリプト」、RFC 5893、2010年8月。
[Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", September 2009, <http://www.unicode.org/reports/tr15/>.
[Unicode-uax15] Unicode Consortium、「Unicode Standard Annex＃15：Unicode Normalization Forms」、2009年9月、<http://www.unicode.org/reports/tr15/>。
[ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968. ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet.
[ASCII] American National Standards Institute（以前のアメリカ合衆国標準研究所）、「情報交換の米国コード」、ANSI X3.4-1968、1968。ANSI X3.4-1968は、わずかな修正で新しいバージョンに置き換えられました。しかし、1968年のバージョンはインターネットにとって決定的なままです。
[IDNA2008-Mapping] Resnick, P. and P. Hoffman, "Mapping Characters in Internationalized Domain Names for Applications (IDNA)", Work in Progress, April 2010.
[IDNA2008マッピング] Resnick、P。およびP. Hoffman、「アプリケーションの国際化ドメイン名（IDNA）のマッピング文字」、2010年4月の作業。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P., 「DNSの拡張メカニズム（EDNS0）」、RFC 2671、1999年8月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P., およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3491] Hoffman、P。およびM. Blanchet、「NamePrep：国際化されたドメイン名のStringPrepプロファイル（IDN）」、RFC 3491、2003年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R., およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] Duerst、M。およびM. Suignard、「国際化されたリソース識別子（IRIS）」、RFC 3987、2005年1月。
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006.
[RFC4690] Klensin、J.、Faltstrom、P.、Karp、C., およびIAB、「国際化されたドメイン名（IDN）のレビューと推奨事項」、RFC 4690、2006年9月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952] Klensin、J。およびY. Ko、「国際化された電子メールの概要とフレームワーク」、RFC 4952、2007年7月。
[RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010.
[RFC5894] Klensin、J., 「アプリケーションの国際化ドメイン名（IDNA）：背景、説明、および根拠」、RFC 5894、2010年8月。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 5.0", 2007. Boston, MA, USA: Addison-Wesley. ISBN 0-321-48091-0. This printed reference has now been updated online to reflect additional code points. For code points, the reference at the time this document was published is to Unicode 5.2.
[Unicode] Unicode Consortium、「Unicode Standard、バージョン5.0」、2007年。米国マサチューセッツ州ボストン：Addison-Wesley。ISBN 0-321-48091-0。この印刷された参照は、追加のコードポイントを反映するためにオンラインで更新されました。コードポイントの場合、このドキュメントが公開された時点での参照は、Unicode 5.2へです。
1. Update base character set from Unicode 3.2 to Unicode version agnostic.
1. 基本文字セットを Unicode 3.2 から Unicode バージョンに依存しないものに更新しました。
2. Separate the definitions for the "registration" and "lookup" activities.
2. 「登録」と「検索」のアクティビティに関する定義を分離しました。
3. Disallow symbol and punctuation characters except where special exceptions are necessary.
3. 特別な例外が必要な場合を除き、記号や句読点文字を禁止しました。
4. Remove the mapping and normalization steps from the protocol and have them, instead, done by the applications themselves, possibly in a local fashion, before invoking the protocol.
4. プロトコルからマッピングと正規化のステップを削除し、代わりにプロトコルを呼び出す前にアプリケーション自体が（おそらくローカルな方法で）実行するようにしました。
5. Change the way that the protocol specifies which characters are allowed in labels from "humans decide what the table of code points contains" to "decision about code points are based on Unicode properties plus a small exclusion list created by humans".
5. ラベルで許可される文字を指定する方法を、「人間がコードポイントのテーブルの内容を決定する」方式から、「Unicode プロパティに基づいた決定に、人間が作成した小さな除外リストを加える」方式に変更しました。
6. Introduce the new concept of characters that can be used only in specific contexts.
6. 特定のコンテキストでのみ使用できる文字という新しい概念を導入しました。
7. Allow typical words and names in languages such as Dhivehi and Yiddish to be expressed.
7. ディベヒ語やイディッシュ語などの言語における典型的な単語や名前を表現できるようにしました。
8. Make bidirectional domain names (delimited strings of labels, not just labels standing on their own) display in a less surprising fashion, whether they appear in obvious domain name contexts or as part of running text in paragraphs.
8. 双方向ドメイン名（単独のラベルだけでなく、区切られたラベルの文字列）が、明らかなドメイン名の文脈でも段落内の文章の一部としても、混乱の少ない方法で表示されるようにしました。
9. Remove the dot separator from the mandatory part of the protocol.
9. プロトコルの必須部分からドットセパレーターを削除しました。
10. Make some currently valid labels that are not actually IDNA labels invalid.
10. 現在有効であっても、実際には IDNA ラベルではない一部のラベルを無効にしました。
Author's Address
著者の連絡先
John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA
ジョンCクレンシン1770マサチューセッツアベニュー、STE 322ケンブリッジ、マサチューセッツ州02140 USA
Phone: +1 617 245 1457
EMail: john+ietf@jck.com