[要約] RFC 5890は、国際化ドメイン名(IDNA)に関する定義と文書フレームワークを提供します。この標準は、ASCII以外の文字を使用する国際的な文字セットを含むドメイン名をサポートすることを目的としています。これにより、非英語圏のユーザーが自国語の文字でインターネットドメイン名を使用できるようになります。RFC 5890は、IDNAの基本的な概念と用語を定義し、関連するRFCとしてRFC 5891（IDNAのプロトコル）、RFC 5892（IDNAの文字のプロパティ）、RFC 5893（右から左に書かれるスクリプトのためのIDNAの要件）などがあります。これらの文書は、IDNAの実装と理解を支援するために一緒に作用します。
Internet Engineering Task Force (IETF) J. Klensin
Request for Comments: 5890 August 2010
Obsoletes: 3490
Category: Standards Track
ISSN: 2070-1721
Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク
Abstract
概要
This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set.
このドキュメントは、以前のバージョンに取って代わるアプリケーションの国際化ドメイン名（IDNA）の改訂のプロトコルと使用状況のコンテキストを一緒に説明するコレクションの1つです。ドキュメントコレクションについて説明し、セットに共通する定義やその他の資料を提供します。
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）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、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/rfc5890.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5890で取得できます。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. IDNA2008 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Audiences . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2. Normative Language . . . . . . . . . . . . . . . . . . 5
1.2. Road Map of IDNA2008 Documents . . . . . . . . . . . . . . 5
2. Definitions and Terminology . . . . . . . . . . . . . . . . . 6
2.1. Characters and Character Sets . . . . . . . . . . . . . . 6
2.2. DNS-Related Terminology . . . . . . . . . . . . . . . . . 6
2.3. Terminology Specific to IDNA . . . . . . . . . . . . . . . 7
2.3.1. LDH Label . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2. Terms for IDN Label Codings . . . . . . . . . . . . . 11
2.3.2.1. IDNA-valid strings, A-label, and U-label . . . . . 11
2.3.2.2. NR-LDH Label . . . . . . . . . . . . . . . . . . . 13
2.3.2.3. Internationalized Domain Name and
Internationalized Label . . . . . . . . . . . . . 13
2.3.2.4. Label Equivalence . . . . . . . . . . . . . . . . 14
2.3.2.5. ACE Prefix . . . . . . . . . . . . . . . . . . . . 14
2.3.2.6. Domain Name Slot . . . . . . . . . . . . . . . . . 14
2.3.3. Order of Characters in Labels . . . . . . . . . . . . 15
2.3.4. Punycode is an Algorithm, Not a Name or Adjective . . 15
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
4.1. General Issues . . . . . . . . . . . . . . . . . . . . . . 16
4.2. U-label Lengths . . . . . . . . . . . . . . . . . . . . . 16
4.3. Local Character Set Issues . . . . . . . . . . . . . . . . 17
4.4. Visually Similar Characters . . . . . . . . . . . . . . . 17
4.5. IDNA Lookup, Registration, and the Base DNS
Specifications . . . . . . . . . . . . . . . . . . . . . . 18
4.6. Legacy IDN Label Strings . . . . . . . . . . . . . . . . . 18
4.7. Security Differences from IDNA2003 . . . . . . . . . . . . 19
4.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . . 20
6.2. Informative References . . . . . . . . . . . . . . . . . . 21
This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA) that was largely completed in 2008, known within the series and elsewhere as "IDNA2008". The series replaces an earlier version of IDNA [RFC3490] [RFC3491]. For convenience, that version of IDNA is referred to in these documents as "IDNA2003". The newer version continues to use the Punycode algorithm [RFC3492] and ACE (ASCII-compatible encoding) prefix from that earlier version. The document collection is described in Section 1.2. As indicated there, this document provides definitions and other material that are common to the set.
このドキュメントは、2008年および他の場所で「IDNA2008」として知られている2008年に主に完成したアプリケーションの国際化ドメイン名（IDNA）の改訂のプロトコルと使用状況のコンテキストを一緒に説明するコレクションの1つです。このシリーズは、IDNA [RFC3490] [RFC3491]の以前のバージョンに置き換えられます。便利なため、IDNAのそのバージョンはこれらのドキュメントで「IDNA2003」と呼ばれます。新しいバージョンは、その以前のバージョンからのPunycodeアルゴリズム[RFC3492]およびACE（ASCII互換エンコード）プレフィックスを引き続き使用しています。ドキュメントコレクションについては、セクション1.2で説明しています。そこに示されているように、このドキュメントは、セットに共通する定義とその他の資料を提供します。
While many IETF specifications are directed exclusively to protocol implementers, the character of IDNA requires that it be understood and properly used by those whose responsibilities include making decisions about:
多くのIETF仕様はプロトコル実装者のみに向けられていますが、IDNAの特性は、以下についての決定を行うことを含む責任を含む人々によって理解され、適切に使用されることを要求します。
o what names are permitted in DNS zone files,
o DNSゾーンファイルで許可されている名前、
o policies related to names and naming, and
o 名前と命名に関連するポリシー、および
o the handling of domain name strings in files and systems, even with no immediate intention of looking them up.
o ファイルとシステムのドメイン名文字列の処理は、それらを調べるつもりはありませんでした。
This document and those documents concerned with the protocol definition, rules for handling strings that include characters written right to left, and the actual list of characters and categories will be of primary interest to protocol implementers. This document and the one containing explanatory material will be of primary interest to others, although they may have to fill in some details by reference to other documents in the set.
このドキュメントと、プロトコル定義に関係するドキュメント、左から左に書かれた文字を含む文字列を処理するためのルール、および文字とカテゴリの実際のリストは、プロトコル実装者にとって主要な関心事です。このドキュメントと説明資料を含む文書は、他の文書には主に興味深いものになりますが、セット内の他のドキュメントを参照して詳細を記入する必要がある場合があります。
This document and the associated ones are written from the perspective of an IDNA-aware user, application, or implementation. While they may reiterate fundamental DNS rules and requirements for the convenience of the reader, they make no attempt to be comprehensive about DNS principles and should not be considered as a substitute for a thorough understanding of the DNS protocols and specifications.
このドキュメントと関連するドキュメントは、IDNA認識ユーザー、アプリケーション、または実装の観点から書かれています。彼らは読者の利便性に関する基本的なDNSの規則と要件を繰り返し繰り返すかもしれませんが、彼らはDNSの原則について包括的になることを試みることはできず、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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
IDNA2008 consists of the following documents:
IDNA2008は、次のドキュメントで構成されています。
o This document, containing definitions and other material that are needed for understanding other documents in the set. It is referred to informally in other documents in the set as "Defs" or "Definitions".
o このドキュメントには、セット内の他のドキュメントを理解するために必要な定義やその他の資料が含まれています。セットの他のドキュメントでは、「defs」または「定義」と非公式に呼ばれます。
o A document, RFC 5894 [RFC5894], that provides an overview of the protocol and associated tables together with explanatory material and some rationale for the decisions that led to IDNA2008. That document also contains advice for registry operations and those who use Internationalized Domain Names (IDNs). It is referred to informally in other documents in the set as "Rationale". It is not normative.
o プロトコルと関連するテーブルの概要を説明し、IDNA2008につながった決定のいくつかの理論的根拠を提供するドキュメントRFC 5894 [RFC5894]。このドキュメントには、レジストリ操作と国際化されたドメイン名（IDN）を使用する人に関するアドバイスも含まれています。セットの他の文書で非公式に「理論的根拠」と呼ばれます。それは規範ではありません。
o A document, RFC 5891 [RFC5891], that describes the core IDNA2008 protocol and its operations. In combination with the Bidi document, described immediately below, it explicitly updates and replaces RFC 3490. It is referred to informally in other documents in the set as "Protocol".
o Core IDNA2008プロトコルとその操作を説明するドキュメントRFC 5891 [RFC5891]。すぐに説明するBIDIドキュメントと組み合わせて、RFC 3490を明示的に更新および置き換えます。セットの他のドキュメントで非公式に「プロトコル」と呼ばれます。
o A document, RFC 5893 [RFC5893], that specifies special rules (Bidi) for labels that contain characters that are written from right to left.
o 右から左に書かれた文字を含むラベルに特別なルール（BIDI）を指定するドキュメントRFC 5893 [RFC5893]。
o A specification, RFC 5892 [RFC5892], of the categories and rules that identify the code points allowed in a label written in native character form (defined more specifically as a "U-label" in Section 2.3.2.1 below), based on Unicode 5.2 [Unicode52] code point assignments and additional rules unique to IDNA2008. The Unicode-based rules are expected to be stable across Unicode updates and hence independent of Unicode versions. That specification obsoletes RFC 3941 and IDN use of the tables to which it refers. It is referred to informally in other documents in the set as "Tables".
o Unicodeに基づいて、ネイティブ文字形式で記述されたラベル（より具体的には「Uラベル」として定義されている）で許可されているコードポイントを識別するカテゴリとルールの仕様、RFC 5892 [RFC5892]5.2 [Unicode52]コードポイントの割り当てとIDNA2008に固有の追加のルール。Unicodeベースのルールは、Unicodeの更新全体で安定しているため、Unicodeバージョンに依存しないと予想されます。その仕様は、RFC 3941とそれが参照するテーブルのIDN使用を使用します。セット内の他のドキュメントで非公式に「テーブル」と呼ばれます。
o A document [IDNA2008-Mapping] that discusses the issue of mapping characters into other characters and that provides guidance for doing so when that is appropriate. That document, referred to informally as "Mapping", provides advice; it is not a required part of IDNA.
o 文字を他の文字にマッピングする問題を議論し、それが適切な場合にガイダンスを提供するドキュメント[IDNA2008マッピング]。非公式に「マッピング」と呼ばれるその文書は、アドバイスを提供します。IDNAの必要な部分ではありません。
A code point is an integer value in the codespace of a coded character set. In Unicode, these are integers from 0 to 0x10FFFF.
コードポイントは、コード化された文字セットのコードスペースの整数値です。Unicodeでは、これらは0〜0x10ffffの整数です。
Unicode [Unicode52] is a coded character set containing somewhat over 100,000 characters assigned to code points as of version 5.2. A single Unicode code point is denoted in these documents by "U+" followed by four to six hexadecimal digits, while a range of Unicode code points is denoted by two four to six digit hexadecimal numbers separated by "..", with no prefixes.
Unicode [unicode52]は、バージョン5.2の時点でコードポイントに割り当てられたやや100,000文字以上の文字を含むコード化された文字セットです。これらのドキュメントでは、「U」と4〜6匹の16進数桁が続く単一のユニコードコードポイントが示されていますが、ユニコードコードポイントの範囲は、「..」で区切られた2つの4〜6桁の16桁の1桁の数字で示されます。
ASCII means US-ASCII [ASCII], a coded character set containing 128 characters associated with code points in the range 0000..007F. Unicode is a superset of ASCII and may be thought of as a generalization of it; it includes all the ASCII characters and associates them with the equivalent code points.
ASCIIとは、US-ASCII [ASCII]を意味します。これは、範囲0000..007Fのコードポイントに関連付けられた128文字を含むコード化された文字セットです。UnicodeはASCIIのスーパーセットであり、それの一般化と考えられるかもしれません。これには、すべてのASCII文字が含まれ、それらを同等のコードポイントに関連付けます。
"Letters" are, informally, generalizations from the ASCII and common-sense understanding of that term, i.e., characters that are used to write text and that are not digits, symbols, or punctuation. Formally, they are characters with a Unicode General Category value starting in "L" (see Section 4.5 of The Unicode Standard [Unicode52]).
「文字」は、非公式に、ASCIIからの一般化とその用語の一般的な理解、つまりテキストを書くために使用され、数字、記号、または句読点ではない文字です。正式には、それらは「L」で始まるUnicode一般カテゴリ値を持つ文字です（Unicode標準[Unicode52]のセクション4.5を参照）。
When discussing the DNS, this document generally assumes the terminology used in the DNS specifications [RFC1034] [RFC1035] as subsequently modified [RFC1123] [RFC2181]. The term "lookup" is used to describe the combination of operations performed by the IDNA2008 protocol and those actually performed by a DNS resolver. The process of placing an entry into the DNS is referred to as "registration". This is similar to common contemporary usage of that term in other contexts. Consequently, any DNS zone administration is described as a "registry", and the terms "registry" and "zone administrator" are used interchangeably, regardless of the actual administrative arrangements or level in the DNS tree. More details about that relationship are included in the Rationale document.
DNSについて議論するとき、このドキュメントは一般に、DNS仕様[RFC1034] [RFC1035]で使用される用語をその後修正[RFC1123] [RFC2181]と想定しています。「ルックアップ」という用語は、IDNA2008プロトコルによって実行される操作と実際にDNSリゾルバーによって実行される操作の組み合わせを説明するために使用されます。DNSへのエントリを配置するプロセスは、「登録」と呼ばれます。これは、他のコンテキストでのその用語の一般的な現代的な使用に似ています。その結果、DNSゾーン管理は「レジストリ」として説明され、「レジストリ」と「ゾーン管理者」という用語は、DNSツリーの実際の管理契約やレベルに関係なく、同じ意味で使用されます。その関係の詳細は、理論的な文書に含まれています。
The term "LDH code point" is defined in this document to refer to the code points associated with ASCII letters (Unicode code points 0041..005A and 0061..007A), digits (0030..0039), and the hyphen-minus (U+002D). "LDH" is an abbreviation for "letters, digits, hyphen" but is used specifically in this document to refer to the set of naming rules described in Section 2.3.1 below.
「LDHコードポイント」という用語は、このドキュメントで定義されており、ASCII文字（Unicode Code Points 0041..005Aおよび0061..007A）、数字（0030..0039）、およびハイフン - マイナスに関連するコードポイントを参照してください。（U 002d）。「LDH」は、「文字、数字、ハイフン」の略語ですが、このドキュメントでは、以下のセクション2.3.1で説明されている一連の命名規則を参照するために特に使用されています。
The base DNS specifications [RFC1034] [RFC1035] discuss "domain names" and "hostnames", but many people use the terms interchangeably, as do sections of these specifications. Lack of clarity about that terminology has contributed to confusion about intent in some cases. These documents generally use the term "domain name". When they refer to, e.g., hostname syntax restrictions, they explicitly cite the relevant defining documents. The remaining definitions in this subsection are essentially a review: if there is any perceived difference between those definitions and the definitions in the base DNS documents or those cited below, the definitions in the other documents take precedence.
ベースDNS仕様[RFC1034] [RFC1035]は「ドメイン名」と「ホスト名」について説明しますが、多くの人はこれらの仕様のセクションと同様に、この用語を互換性があります。その用語に関する明確性の欠如は、場合によっては意図に関する混乱に貢献しています。これらのドキュメントは通常、「ドメイン名」という用語を使用します。たとえば、ホスト名の構文制限を参照すると、関連する定義ドキュメントを明示的に引用します。このサブセクションの残りの定義は、基本的にレビューです。これらの定義とベースDNSドキュメントの定義または以下で引用した定義の間に認識された違いがある場合、他のドキュメントの定義が優先されます。
A label is an individual component 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 complete name convention using a trailing dot described in RFC 1123 [RFC1123], which can be explicit as in "www.example.com." or implicit as in "www.example.com", is not considered in this specification.) IDNA extends the set of usable characters in labels that are treated as text (as distinct from the binary string labels discussed in RFC 1035 and RFC 2181 [RFC2181] and bitstring ones [RFC2673]), but only in certain contexts. The different contexts for different sets of usable characters are outlined in the next section. For the rest of this document and in the related ones, the term "label" is shorthand for "text label", and "every label" means "every text label", including the expanded context.
ラベルは、ドメイン名の個々のコンポーネントです。ラベルは通常、ドットで分離されています。たとえば、ドメイン名「www.example.com」は、「www」、「例」、「com」の3つのラベルで構成されています。（RFC 1123 [RFC1123]に記載されている後続のドットを使用した完全な名前の規則。これは、「www.example.com」のように明示的であるか、「www.example.com」のように暗黙的である可能性があります。）IDNAは、テキストとして扱われるラベルの使用可能な文字のセットを拡張します（RFC 1035およびRFC 2181 [RFC2181]およびビットストリングのもの[RFC2673]で説明されているバイナリ文字列ラベルとは異なりますが、特定のコンテキストでのみ）。使用可能な文字のさまざまなセットのさまざまなコンテキストについて、次のセクションで概説します。このドキュメントの残りの部分および関連するドキュメントでは、「ラベル」という用語は「テキストラベル」の速記であり、「すべてのラベル」は、拡張されたコンテキストを含む「すべてのテキストラベル」を意味します。
This section defines some terminology to reduce dependence on terms and definitions that have been problematic in the past. The relationships among these definitions are illustrated in Figure 1 and Figure 2. In the first of those figures, the parenthesized numbers refer to the notes below the figure.
このセクションでは、過去に問題があった用語と定義への依存を減らすためのいくつかの用語を定義します。これらの定義間の関係を図1と図2に示します。これらの図の最初の数字では、括弧付きの数字は図の下のメモを参照しています。
This is the classical label form used, albeit with some additional restrictions, in hostnames [RFC0952]. Its syntax is identical to that described as the "preferred name syntax" in Section 3.5 of RFC 1034 [RFC1034] as modified by RFC 1123 [RFC1123]. Briefly, it is a string consisting of ASCII letters, digits, and the hyphen with the further restriction that the hyphen cannot appear at the beginning or end of the string. Like all DNS labels, its total length must not exceed 63 octets.
これは、ホスト名[RFC0952]で、いくつかの追加の制限がありますが、使用される古典的なラベルフォームです。その構文は、RFC 1123 [RFC1123]によって変更されたRFC 1034 [RFC1034]のセクション3.5の「優先名構文」と記載されているものと同一です。簡単に言えば、それは、ハイフンが弦の最初または最後に現れないというさらなる制限を伴う、ASCIIの文字、数字、およびハイフンからなる文字列です。すべてのDNSラベルと同様に、その総長は63オクテットを超えてはなりません。
LDH labels include the specialized labels used by IDNA (described as "A-labels" below) and some additional restricted forms (also described below).
LDHラベルには、IDNA（以下の「Aラベル」と記述されている）で使用される特殊なラベルと、いくつかの追加の制限フォーム（以下に説明する）が含まれます。
To facilitate clear description, two new subsets of LDH labels are created by the introduction of IDNA. These are called Reserved LDH labels (R-LDH labels) and Non-Reserved LDH labels (NR-LDH labels). Reserved LDH labels, known as "tagged domain names" in some other contexts, have the property that they contain "--" in the third and fourth characters but which otherwise conform to LDH label rules. Only a subset of the R-LDH labels can be used in IDNA-aware applications. That subset consists of the class of labels that begin with the prefix "xn--" (case independent), but otherwise conform to the rules for LDH labels. That subset is called "XN-labels" in this set of documents. XN-labels are further divided into those whose remaining characters (after the "xn--") are valid output of the Punycode algorithm [RFC3492] and those that are not (see below). The XN-labels that are valid Punycode output are known as "A-labels" if they also meet the other criteria for IDNA-validity described below. Because LDH labels (and, indeed, any DNS label) must not be more than 63 octets in length, the portion of an XN-label derived from the Punycode algorithm is limited to no more than 59 ASCII characters. Non-Reserved LDH labels are the set of valid LDH labels that do not have "--" in the third and fourth positions.
明確な説明を容易にするために、LDHラベルの2つの新しいサブセットがIDNAの導入によって作成されます。これらは、予約済みのLDHラベル（R-LDHラベル）と非予定のLDHラベル（NR-LDHラベル）と呼ばれます。他のいくつかのコンテキストで「タグ付きドメイン名」として知られる予約済みのLDHラベルには、「3番目と4番目の文字」にあるが、LDHラベルルールに準拠しているプロパティを含むプロパティを持っています。IDNA対応アプリケーションでは、R-LDHラベルのサブセットのみを使用できます。そのサブセットは、プレフィックス「xn-」（ケース独立）で始まるが、LDHラベルのルールに準拠しているラベルのクラスで構成されています。そのサブセットは、この一連のドキュメントで「xn-labels」と呼ばれます。XN-Labelsは、残りの文字（「XN-」の後）がPunycodeアルゴリズム[RFC3492]の有効な出力とそうでないもの（以下を参照）の有効な出力であるものにさらに分割されます。有効なパニコード出力であるXN-Labelsは、以下で説明するIDNA有効性の他の基準を満たしている場合、「A-Labels」として知られています。LDHラベル（および実際には、DNSラベル）は長さ63オクテットを超えてはならないため、Punycodeアルゴリズムに由来するXN-Labelの部分は59個以下のASCII文字に制限されています。非予約されていないLDHラベルは、3番目と4番目のポジションで「 - 」を持たない有効なLDHラベルのセットです。
A consequence of the restrictions on valid characters in the native Unicode character form (see U-labels) turns out to be that mixed-case annotation, of the sort outlined in Appendix A of RFC 3492 [RFC3492], is never useful. Therefore, since a valid A-label is the result of Punycode encoding of a U-label, A-labels should be produced only in lowercase, despite matching other (mixed-case or uppercase) potential labels in the DNS.
ネイティブユニコード文字フォームの有効な文字に対する制限の結果（Uラベルを参照）は、RFC 3492 [RFC3492]の付録Aに概説されている種類の混合ケースアノテーションであることが判明しました。したがって、有効なA-LabelはUラベルのパニコードエンコードの結果であるため、DNSの他の（混合ケースまたは大文字または大文字の）潜在的なラベルを一致させたにもかかわらず、A-Labelは小文字でのみ生産する必要があります。
Some strings that are prefixed with "xn--" to form labels may not be the output of the Punycode algorithm, may fail the other tests outlined below, or may violate other IDNA restrictions and thus are also not valid IDNA labels. They are called "Fake A-labels" for convenience.
ラベルを形成するために「XN」が付いている文字列は、パニコードアルゴリズムの出力ではない場合、以下に概説した他のテストに失敗する可能性があるか、他のIDNA制限に違反する可能性があるため、有効なIDNAラベルも違反している可能性があります。それらは便利なために「偽のAラベル」と呼ばれます。
Labels within the class of R-LDH labels that are not prefixed with "xn--" are also not valid IDNA labels. To allow for future use of mechanisms similar to IDNA, those labels MUST NOT be processed as ordinary LDH labels by IDNA-conforming programs and SHOULD NOT be mixed with IDNA labels in the same zone.
「xn-」が付いていないR-LDHラベルのクラス内のラベルも有効なIDNAラベルではありません。IDNAと同様のメカニズムの将来の使用を可能にするために、これらのラベルは、IDNA制度プログラムによって通常のLDHラベルとして処理されるべきではなく、同じゾーンのIDNAラベルと混合されるべきではありません。
These distinctions among possible LDH labels are only of significance for software that is IDNA-aware or for future extensions that use extensions based on the same "prefix and encoding" model. For IDNA-aware systems, the valid label types are: A-labels, U-labels, and NR-LDH labels.
考えられるLDHラベル間のこれらの区別は、IDNA認識のソフトウェアまたは同じ「プレフィックスとエンコード」モデルに基づいて拡張機能を使用する将来の拡張機能にとってのみ重要です。IDNA-AWAREシステムの場合、有効なラベルタイプは次のとおりです。Aラベル、Uラベル、およびNR-LDHラベル。
IDNA labels come in two flavors: an ACE-encoded form and a Unicode (native character) form. These are referred to as A-labels and U-labels, respectively, and are described in detail in the next section.
IDNAラベルには、エースエンコードフォームとユニコード（ネイティブ文字）フォームの2つのフレーバーがあります。これらはそれぞれAラベルとUラベルと呼ばれ、次のセクションで詳細に説明されています。
ASCII Label
__________________________________________________________________
| |
| ____________________ LDH Label (1) (4) ________________ |
| | ___________________________________ | |
| | |IDN Reserved LDH Labels | | |
| | | ("??--") or R-LDH Labels | _______________ | |
| | | _______________________________ | |NON-RESERVED | | |
| | | | XN-labels | | | LDH Labels | | |
| | | | _____________ ___________ | | | (NR-LDH | | |
| | | | | A-labels | | Fake (3) || | | labels) | | |
| | | | | "xn--"(2) | | A-labels || | |_____________| | |
| | | | |___________| |__________|| | | |
| | | |_____________________________| | | |
| | |_________________________________| | |
| |_______________________________________________________| |
| |
| _____________NON-LDH label________ |
| | ______________________ | |
| | | Underscore labels | | |
| | | e.g., _tcp | | |
| | |____________________| | |
| | | Labels with leading| | |
| | | or trailing | | |
| | | hyphens "-abcd" | | |
| | | or "xyz-" | | |
| | | or "-uvw-" | | |
| | |____________________| | |
| | | Labels with other | | |
| | | non-LDH ASCII chars| | |
| | | e.g., #$%_ | | |
| | |____________________| | |
| |________________________________| |
|________________________________________________________________|
(1) ASCII letters (uppercase and lowercase), digits, hyphen. Hyphen may not appear in first or last position. No more than 63 octets. (2) Note that the string following "xn--" must be the valid output of the Punycode algorithm and must be convertible into valid U-label form. (3) Note that a Fake A-label has a prefix "xn--" but the remainder of the label is NOT the valid output of the Punycode algorithm. (4) LDH label subtypes are indistinguishable to applications that are not IDNA-aware.
(1) ASCII文字（大文字と小文字）、数字、ハイフン。ハイフンは最初の位置または最後の位置に表示されない場合があります。63オクテット以下。（2）「xn-」に続く文字列は、Punycodeアルゴリズムの有効な出力であり、有効なUラベル形式に変換可能でなければならないことに注意してください。（3）偽のAラベルには「xn-」というプレフィックスがあることに注意してください。ただし、ラベルの残りの部分は、プニュコードアルゴリズムの有効な出力ではないことに注意してください。（4）LDHラベルサブタイプは、IDNA認識ではないアプリケーションと区別できません。
Figure 1: IDNA and Related DNS Terminology Space -- ASCII Labels
図1：IDNAおよび関連DNS用語スペース-ASCIIラベル
__________________________
| Non-ASCII |
| |
| ___________________ |
| | U-label (5) | |
| |_________________| |
| | | |
| | Binary Label | |
| | (including | |
| | high bit on) | |
| |_________________| |
| | | |
| | Bit String | |
| | Label | |
| |_________________| |
|________________________|
(5) To applications that are not IDNA-aware, U-labels are indistinguishable from Binary ones.
(5) IDNAが認識していないアプリケーションに対して、Uラベルはバイナリのものと区別できません。
Figure 2: Non-ASCII Labels
図2：非ASSASCIIラベル
For IDNA-aware applications, the three types of valid labels are "A-labels", "U-labels", and "NR-LDH labels", each of which is defined below. The relationships among them are illustrated in Figure 1 and Figure 2.
IDNAが認識しているアプリケーションの場合、3つのタイプの有効なラベルは「A-Labels」、「U-Labels」、および「NR-LDHラベル」であり、それぞれが以下に定義されています。それらの間の関係を図1と図2に示します。
o A string is "IDNA-valid" if it meets all of the requirements of these specifications for an IDNA label. IDNA-valid strings may appear in either of the two forms defined immediately below, or may be drawn from the NR-LDH label subset. IDNA-valid strings must also conform to all basic DNS requirements for labels. These documents make specific reference to the form appropriate to any context in which the distinction is important.
o 文字列は、IDNAラベルのこれらの仕様のすべての要件を満たしている場合、「idna-valid」です。IDNA-valid文字列は、すぐ下に定義されている2つの形式のいずれかに表示されるか、NR-LDHラベルサブセットから描画される場合があります。idna-valid文字列は、ラベルのすべての基本的なDNS要件にも準拠する必要があります。これらのドキュメントは、区別が重要であるコンテキストに適したフォームに具体的に言及しています。
o An "A-label" is the ASCII-Compatible Encoding (ACE, see Section 2.3.2.5) form of an IDNA-valid string. It must be a complete label: IDNA is defined for labels, not for parts of them and not for complete domain names. This means, by definition, that every A-label will begin with the IDNA ACE prefix, "xn--" (see Section 2.3.2.5), followed by a string that is a valid output of the Punycode algorithm [RFC3492] and hence a maximum of 59 ASCII characters in length. The prefix and string together must conform to all requirements for a label that can be stored in the DNS including conformance to the rules for LDH labels (Section 2.3.1). If and only if a string meeting the above requirements can be decoded into a U-label is it an A-label.
o 「A-Label」は、IDNA-Valid文字列のASCII互換エンコード（ACE、セクション2.3.2.5を参照）形式です。それは完全なラベルでなければなりません：IDNAは、ラベルの一部ではなく、完全なドメイン名ではなく、ラベル用に定義されています。これは、定義上、すべてのA-LabelがIDNA ACEプレフィックス「XN-」（セクション2.3.2.5を参照）から始まることを意味し、その後にプニコードアルゴリズム[RFC3492]の有効な出力である文字列が続くことを意味します。長さが最大59個のASCII文字。プレフィックスと文字列は、LDHラベルのルールへの適合を含むDNSに保存できるラベルのすべての要件に準拠する必要があります（セクション2.3.1）。上記の要件を満たしている文字列がUラベルにデコードできる場合にのみ、Aラベルです。
o A "U-label" is an IDNA-valid string of Unicode characters, in Normalization Form C (NFC) and including at least one non-ASCII character, expressed in a standard Unicode Encoding Form (such as UTF-8). It is also subject to the constraints about permitted characters that are specified in Section 4.2 of the Protocol document and the rules in the Sections 2 and 3 of the Tables document, the Bidi constraints in that document if it contains any character from scripts that are written right to left, and the symmetry constraint described immediately below. Conversions between U-labels and A-labels are performed according to the "Punycode" specification [RFC3492], adding or removing the ACE prefix as needed.
o 「u-label」は、正規化形式C（NFC）で、標準的なユニコードエンコードフォーム（UTF-8など）で表される少なくとも1つの非ASCII文字を含む、ユニコード文字のIDNA-valid文字列です。また、プロトコルドキュメントのセクション4.2で指定されている許可された文字に関する制約と、テーブルドキュメントのセクション2および3のルールに関する制約の対象となります。右から左に、そしてすぐに説明する対称的な制約。UラベルとAラベル間の変換は、「Punycode」仕様[RFC3492]に従って実行され、必要に応じてACEプレフィックスを追加または削除します。
To be valid, U-labels and A-labels must obey an important symmetry constraint. While that constraint may be tested in any of several ways, an A-label A1 must be capable of being produced by conversion from a U-label U1, and that U-label U1 must be capable of being produced by conversion from A-label A1. Among other things, this implies that both U-labels and A-labels must be strings in Unicode NFC [Unicode-UAX15] normalized form. These strings MUST contain only characters specified elsewhere in this document series, and only in the contexts indicated as appropriate.
有効であるためには、UラベルとAラベルは重要な対称性の制約に従わなければなりません。その制約はいくつかの方法でテストされる場合がありますが、A-Label A1はUラベルU1からの変換によって生成できる必要があり、U-Label U1はA-Labelからの変換によって生成できる必要があります。A1。とりわけ、これは、UラベルとAラベルの両方がUnicode NFC [Unicode-Uax15]正規化された形式の文字列でなければならないことを意味します。これらの文字列には、このドキュメントシリーズの他の場所で指定された文字のみが含まれている必要があり、必要に応じて示されているコンテキストでのみです。
Any rules or conventions that apply to DNS labels in general apply to whichever of the U-label or A-label would be more restrictive. There are two exceptions to this principle. First, the restriction to ASCII characters does not apply to the U-label. Second, expansion of the A-label form to a U-label may produce strings that are much longer than the normal 63 octet DNS limit (potentially up to 252 characters) due to the compression efficiency of the Punycode algorithm. Such extended-length U-labels are valid from the standpoint of IDNA, but caution should be exercised as shorter limits may be imposed by some applications.
一般にDNSラベルに適用される規則または規則は、UラベルまたはAラベルのどれにも適用されます。この原則には2つの例外があります。まず、ASCII文字への制限はUラベルには適用されません。第二に、a-labelフォームのUラベルへの拡張は、プニコードアルゴリズムの圧縮効率により、通常の63オクテットDNS制限（潜在的に最大252文字）よりもはるかに長い文字列を生成する可能性があります。このような長さのUラベルは、IDNAの観点から有効ですが、一部のアプリケーションによってより短い制限が課される可能性があるため、注意する必要があります。
For context, applications that are not IDNA-aware treat all LDH labels as valid for appearance in DNS zone files and queries and some of them may permit additional types of labels (i.e., not impose the LDH restriction). IDNA-aware applications permit only A-labels and NR-LDH labels to appear in zone files and queries. U-labels can appear, along with the other two, in presentation and user interface forms, and in protocols that use IDNA forms but that do not involve the DNS itself.
コンテキストでは、すべてのLDHラベルをDNSゾーンファイルやクエリでの外観に有効なものとして扱い、一部のLDHラベルを扱うアプリケーションは、追加の種類のラベルを許可する場合があります（つまり、LDH制限を課しません）。IDNA-Awareアプリケーションでは、AラベルとNR-LDHラベルのみがゾーンファイルとクエリに表示されることができます。Uラベルは、他の2つとともに、プレゼンテーションおよびユーザーインターフェイスフォーム、およびIDNAフォームを使用しているプロトコルに表示できますが、DNS自体は関与しません。
Specifically, for IDNA-aware applications and contexts, the three allowed categories are A-label, U-label, and NR-LDH label. Of the Reserved LDH labels (R-LDH labels) only A-labels are valid for IDNA use.
具体的には、IDNAを認識しているアプリケーションとコンテキストの場合、3つの許可されたカテゴリはA-Label、U-Label、およびNR-LDHラベルです。予約済みのLDHラベル（R-LDHラベル）のみがAラベルのみがIDNA使用に有効です。
Strings that appear to be A-labels or U-labels are processed in various operations of the Protocol document [RFC5891]. Those strings are not yet demonstrably conformant with the conditions outlined above because they are in the process of validation. Such strings may be referred to as "unvalidated", "putative", or "apparent", or as being "in the form of" one of the label types to indicate that they have not been verified to meet the specified conformance requirements.
AラベルまたはUラベルのように見える文字列は、プロトコルドキュメント[RFC5891]のさまざまな操作で処理されます。これらの文字列は、検証の過程にあるため、上記の条件にまだ明確に適合していません。このような文字列は、「非検証」、「推定」、または「見かけ」と呼ばれる場合、または「ラベルタイプの1つ」の形で「ある」と呼ばれる場合があります。
Unvalidated A-labels are known only to be XN-labels, while Fake A-labels have been demonstrated to fail some of the A-label tests. Similarly, unvalidated U-labels are simply non-ASCII labels that may or may not meet the requirements for U-labels.
未検証のAラベルはXNラベルであることが知られていますが、偽のAラベルはAラベルテストの一部に失敗することが実証されています。同様に、未検証のUラベルは、U-Labelの要件を満たしている場合と満たしていない場合があるASCII以外のラベルです。
These specifications use the term "NR-LDH label" strictly to refer to an all-ASCII label that obeys the LDH label syntax discussed in Section 2.3.1 and that is neither an IDN nor a label form reserved by IDNA (R-LDH label). It should be stressed that all A-labels obey the "hostname" [RFC0952] rules other than the length restriction in those rules.
これらの仕様は、「NR-LDHラベル」という用語を使用して、セクション2.3.1で説明したLDHラベル構文に従うすべてのASCIIラベルを参照するために厳密に言及しています。）。すべてのAラベルは、これらのルールの長さの制限以外の「HOSTNAME」[RFC0952]ルールに従うことを強調する必要があります。
An "internationalized domain name" (IDN) is a domain name that contains at least one A-label or U-label, but that otherwise may contain any mixture of NR-LDH labels, A-labels, or U-labels. 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. Because of the diversity of characters that can be used in a U-label and the confusion they might cause, such restrictions are mandatory for IDN registries and zones even though the particular restrictions are not part of these specifications (the issue is discussed in more detail in Section 4.3 of the Protocol document [RFC5891]. Because these restrictions, commonly known as "registry restrictions", only affect what can be registered and not lookup processing, they have no effect 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. See the section on registration policy in the Rationale document [RFC5894] for additional discussion.
「国際化されたドメイン名」（IDN）は、少なくとも1つのAラベルまたはUラベルを含むドメイン名ですが、それ以外の場合はNR-LDHラベル、Aラベル、またはUラベルの混合物を含む場合があります。ASCII名の場合と同様に、一部のDNSゾーン管理者は、DNSまたはIDNAによって課されるものを超えて、ゾーン内のラベルとして登録される文字または文字列に制限を課す可能性があります。Uラベルで使用できるキャラクターの多様性とそれらが引き起こす可能性のある混乱のため、そのような制限は、特定の制限がこれらの仕様の一部ではないにもかかわらず、IDNレジストリとゾーンに必須です（問題については詳細に説明しますプロトコルドキュメント[RFC5891]のセクション4.3では、これらの制限は一般に「レジストリ制限」として知られているため、登録できるもののみに影響し、ルックアップ処理ではなく影響するため、DNSプロトコルメッセージの構文またはセマンティクスには影響しません。クエリレコードと一致する名前の場合、ゾーン内にない理由に関係なく、レコードが同じ応答をもたらしません。クエリを発行したり、応答を解釈したりするクライアントは、ゾーン固有の制限または慣習に関する知識があるとは想定できません。登録に関するセクションを参照してください追加の議論については、理論的文書[RFC5894]のポリシー。
"Internationalized label" is used when a term is needed to refer to a single label of an IDN, i.e., one that might be any of an NR-LDH label, A-label, or U-label. There are some standardized DNS label formats, such as the "underscore labels" used for service location (SRV) records [RFC2782], that do not fall into any of the three categories and hence are not internationalized labels.
「国際化されたラベル」は、IDNの単一のラベル、つまりNR-LDHラベル、A-Label、またはU-Labelのいずれかのラベルを参照するために用語が必要な場合に使用されます。サービスロケーション（SRV）レコード[RFC2782]に使用される「アンダースコアラベル」など、3つのカテゴリのいずれにも分類されないため、国際化されたラベルではない標準化されたDNSラベル形式があります。
In IDNA, equivalence of labels is defined in terms of the A-labels. If the A-labels are equal in a case-independent comparison, then the labels are considered equivalent, no matter how they are represented. Because of the isomorphism of A-labels and U-labels in IDNA2008, it is possible to compare U-labels directly; see the Protocol document [RFC5891] for details. Traditional LDH labels already have a notion of equivalence: within that list of characters, uppercase and lowercase are considered equivalent. The IDNA notion of equivalence is an extension of that older notion but, because the protocol does not specify any mandatory mapping and only those isomorphic forms are considered, the only equivalents are:
IDNAでは、ラベルの等価性がAラベルの観点から定義されています。A-Labelsがケースに依存しない比較で等しい場合、ラベルはどのように表現されていても、同等のものと見なされます。IDNA2008におけるAラベルとUラベルの同型のため、Uラベルを直接比較することができます。詳細については、プロトコルドキュメント[RFC5891]を参照してください。従来のLDHラベルにはすでに同等の概念があります。文字のリスト内で、大文字と小文字は同等と見なされます。同等性のIDNA概念は、その古い概念の拡張ですが、プロトコルは必須マッピングを指定しておらず、それらの同型形式のみが考慮されるため、唯一の同等のものは次のとおりです。
o Exact (bit-string identity) matches between a pair of U-labels.
o 正確な（ビットストリングアイデンティティ）は、Uラベルのペア間で一致します。
o Matches between a pair of A-labels, using normal DNS case-insensitive matching rules.
o 通常のDNSケース非感受性マッチングルールを使用して、A-Labelのペア間の一致。
o Equivalence between a U-label and an A-label determined by translating the U-label form into an A-label form and then testing for a match between the A-labels using normal DNS case-insensitive matching rules.
o UラベルとAラベルの等価性は、Uラベル形式をAラベル形式に変換し、通常のDNSケース非感受性マッチングルールを使用してAラベル間の一致をテストします。
The "ACE prefix" is defined in this document to be a string of ASCII characters, "xn--", that appears at the beginning of every A-label. "ACE" stands for "ASCII-Compatible Encoding".
「ACEプレフィックス」は、このドキュメントで、すべてのAラベルの先頭に表示されるASCII文字「XN-」の文字列であると定義されています。「Ace」は「ASCII互換のエンコード」の略です。
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() or getaddrinfo() standard C library functions;
「ドメイン名スロット」は、このドキュメントで、プロトコル要素、関数引数、またはドメイン名を運ぶために明示的に指定された返品値（など）であると定義されています。ドメイン名スロットの例には、DNSクエリのQNameフィールドが含まれます。gethostbyname（）またはgetaddrinfo（）標準Cライブラリ関数の名前引数。
the part of an email address following the at sign ("@") in the parameter to the SMTP MAIL or RCPT commands or the "From:" field of an email message header; and the host portion of the URI in the "src" attribute of an HTML "<IMG>" tag. A string that has the syntax of a domain name but that appears in general text is not in 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.
SMTPメールまたはRCPTコマンドのパラメーターのATサイン（ "@"）に続く電子メールアドレスの一部、または「from：」電子メールメッセージヘッダーのフィールド。HTML "<IMG>"タグの「SRC」属性のURIのホスト部分。ドメイン名の構文を持っているが、一般的なテキストに表示される文字列は、ドメイン名スロットにはありません。たとえば、電子メールメッセージのプレーンテキスト本文に表示されるドメイン名は、ドメイン名スロットを占有していません。
An "IDNA-aware domain name slot" is defined for this set of documents 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).
このドキュメントのセットは、このドキュメントで定義されている国際化されたドメイン名を搭載するために明示的に指定されたドメイン名スロットであるために、「idna-awareドメイン名スロット」が定義されています。指定は、静的（たとえば、プロトコルまたはインターフェイスの仕様）または動的（たとえば、インタラクティブセッションでのネゴシエーションの結果として）である場合があります。
Name slots that are not IDNA-aware obviously include any domain name slot whose specification predates IDNA. Note that the requirements of some protocols that use the DNS for data storage prevent the use of IDNs. For example, the format required for the underscore labels used by the service location protocol [RFC2782] precludes representation of a non-ASCII label in the DNS using A-labels because those SRV-related labels must start with underscores. Of course, non-ASCII IDN labels may be part of a domain name that also includes underscore labels.
Idna-Awareではない名前スロットには、仕様がIDNAより前のドメイン名スロットが含まれています。データストレージにDNSを使用する一部のプロトコルの要件は、IDNの使用を防ぐことに注意してください。たとえば、サービスロケーションプロトコル[RFC2782]で使用されるアンダースコアラベルに必要な形式は、A-Labelsを使用してDNSの非ASCIIラベルの表現を排除します。これは、これらのSRV関連ラベルがアンダースコアから開始する必要があるためです。もちろん、非ASCII IDNラベルは、アンダースコアラベルも含まれるドメイン名の一部である可能性があります。
Because IDN labels may contain characters that are read, and preferentially displayed, from right to left, there is a potential ambiguity about which character in a label is "first". For the purposes of these specifications, labels are considered, and characters numbered, strictly in the order in which they appear "on the wire". That order is equivalent to the leftmost character being treated as first in a label that is read left to right and to the rightmost character being first in a label that is read right to left. The Bidi specification contains additional discussion of the conditions that influence reading order.
IDNラベルには、右から左に読み、優先的に表示される文字が含まれているため、ラベル内のどの文字が「最初」であるかについての潜在的な曖昧さがあります。これらの仕様の目的のために、ラベルが考慮され、文字は「ワイヤー上」に表示される順序で厳密に数えられています。その順序は、左から右に読み取られたラベルで最初に扱われ、左から左に読み取られるラベルで最初に扱われる左端のキャラクターと同等です。BIDI仕様には、読み取り順に影響を与える条件の追加の議論が含まれています。
There has been some confusion about whether a "Punycode string" does or does not include the ACE prefix and about whether it is required that such strings could have been the output of the ToASCII operation (see RFC 3490, Section 4 [RFC3490]). This specification discourages the use of the term "Punycode" to describe anything but the encoding method and algorithm of RFC 3492 [RFC3492]. The terms defined above are preferred as much more clear than the term "Punycode string".
「Punycode String」にACEプレフィックスが含まれているかどうか、およびそのような文字列がToascii操作の出力である可能性があるかどうかについて、ある程度の混乱がありました（RFC 3490、セクション4 [RFC3490]を参照）。この仕様は、「パニコード」という用語の使用を妨げて、RFC 3492 [RFC3492]のエンコード方法とアルゴリズム以外のものを説明します。上記で定義された用語は、「Punycode String」という用語よりもはるかに明確な用語です。
IANA actions for this version of IDNA (IDNA2008) are specified in the Tables document [RFC5892]. An overview of the relationships among the various IANA registries appears in the Rationale document [RFC5894]. This document does not specify any actions for IANA.
このバージョンのIDNA（IDNA2008）のIANAアクションは、テーブルドキュメント[RFC5892]で指定されています。さまざまなIANAレジストリ間の関係の概要は、Rationale Document [RFC5894]に表示されます。このドキュメントでは、IANAのアクションは指定されていません。
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.
インターネット上のセキュリティは、DNSに部分的に依存しています。したがって、DNSの特性を変更すると、インターネットの多くのセキュリティが変更される可能性があります。
Domain names are used by users to identify and connect to Internet hosts and other network resources. 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. In addition to characters that are permitted by IDNA2003 and its mapping conventions (see Section 4.6), the current specification changes the interpretation of a few characters that were mapped to others in the earlier version; zone administrators should be aware of the problems that this might raise and take appropriate measures. The context for this issue is discussed in more detail in the Rationale document [RFC5894].
ドメイン名は、ユーザーがインターネットホストやその他のネットワークリソースを特定して接続するために使用されます。単一の国際化された名前を入力するユーザーが、国際化されたドメイン名の異なる解釈に基づいて異なるサーバーに接続されている場合、インターネットのセキュリティが損なわれます。IDNA2003で許可されている文字とそのマッピングコンベンション（セクション4.6を参照）に加えて、現在の仕様は、以前のバージョンの他のバージョンにマッピングされたいくつかの文字の解釈を変更します。ゾーン管理者は、これが提起し、適切な措置を講じる可能性のある問題を認識する必要があります。この問題のコンテキストについては、Rationale Document [RFC5894]で詳細に説明します。
In addition to the Security Considerations material that appears in this document, the Bidi document [RFC5893] contains a discussion of security issues specific to labels containing characters from scripts that are normally written right to left.
このドキュメントに掲載されているセキュリティに関する考慮事項に加えて、BIDIドキュメント[RFC5893]には、通常左から左に書かれたスクリプトの文字を含むラベルに固有のセキュリティ問題の議論が含まれています。
Labels associated with the DNS have traditionally been limited to 63 octets by the general restrictions in RFC 1035 and by the need to treat them as a six-bit string length followed by the string in actual calls to the DNS. That format is used in some other applications and, in general, that representations of domain names as dot-separated labels and as length-string pairs have been treated as interchangeable. Because A-labels (the form actually used in the DNS) are potentially much more compressed than UTF-8 (and UTF-8 is, in general, more compressed that UTF-16 or UTF-32), U-labels that obey all of the relevant symmetry (and other) constraints of these documents may be quite a bit longer, potentially up to 252 characters (Unicode code points). A fully-qualified domain name containing several such labels can obviously also exceed the nominal 255 octet limit for such names. Application authors using U-labels must exert due caution to avoid buffer overflow and truncation errors and attacks in contexts where shorter strings are expected.
DNSに関連付けられたラベルは、RFC 1035の一般的な制限により、およびそれらを6ビット文字列の長さとして扱う必要性により、実際にDNSへのコールで文字列を扱う必要により、伝統的に63オクテットに制限されてきました。その形式は、他のいくつかのアプリケーションで使用され、一般に、ドメイン名のドットを分離されたラベルとして、および長さ弦のペアとしてのその表現は、交換可能として扱われています。Aラベル（DNSで実際に使用されるフォーム）は、UTF-8よりもはるかに圧縮される可能性があるため（およびUTF-8は一般に、UTF-16またはUTF-32をより圧縮しています）、すべてに従うUラベルこれらのドキュメントの関連する対称性（およびその他）の制約は、かなり長く、潜在的に最大252文字（Unicodeコードポイント）があります。このようなラベルをいくつか含む完全に資格のあるドメイン名は、そのような名前の名目255オクテット制限を明らかに超えることがあります。U-Labelを使用するアプリケーション著者は、バッファーオーバーフローと切り捨てエラーと攻撃を避けるために、より短い文字列が予想されるコンテキストで攻撃を避けるために注意する必要があります。
When systems use local character sets other than ASCII and Unicode, these specifications leave the problem of converting between the local character set and Unicode up to the application or local system. If different applications (or different versions of one application) implement different rules for conversions among coded character sets, they could interpret the same name differently and contact different servers. This problem is not solved by security protocols, such as Transport Layer Security (TLS) [RFC5246], that do not take local character sets into account.
システムがASCIIおよびUnicode以外のローカル文字セットを使用する場合、これらの仕様により、ローカル文字セットとUnicodeの間でアプリケーションまたはローカルシステムに変換する問題が残ります。異なるアプリケーション（または1つのアプリケーションの異なるバージョン）がコード化された文字セット間で変換の異なるルールを実装すると、同じ名前を異なる方法で解釈し、異なるサーバーに連絡することができます。この問題は、輸送層のセキュリティ（TLS）[RFC5246]などのセキュリティプロトコルによっては解決されません。
To help prevent confusion between characters that are visually similar (sometimes called "confusables"), it is suggested that implementations provide visual indications where a domain name contains multiple scripts, especially when the scripts contain characters that are easily confused visually, such as an omicron in Greek mixed with Latin text. Such mechanisms can also be used to show when a name contains a mixture of Simplified Chinese characters with Traditional ones that have Simplified forms, or to distinguish zero and one from uppercase "O" and lowercase "L". DNS zone administrators may impose restrictions (subject to the limitations identified elsewhere in these documents) that try to minimize characters that have similar appearance or similar interpretations.
視覚的に類似した文字間の混乱を防ぐために（「混乱すること」と呼ばれることもあります）、実装は、ドメイン名に複数のスクリプトが含まれる視覚的表示を提供することが示唆されています。ラテン語のテキストと混合したギリシャ語で。このようなメカニズムは、名前に単純化された漢字と単純化された漢字の混合物が含まれている場合、またはゼロと大文字の「O」と小文字「L」を区別するために、名前に表示される場合にも使用できます。DNSゾーン管理者は、同様の外観または同様の解釈を持つ文字を最小限に抑えようとする制限（これらのドキュメントの他の場所で特定された制限の対象となる）を課す場合があります。
If multiple characters appear in a label and the label consists only of characters in one script, individual characters that might be confused with others if compared separately may be unambiguous and non-confusing. On the other hand, that observation makes labels containing characters from more than one script (often called "mixed-script labels") even more risky -- users will tend to see what they expect to see and context is a powerful reinforcement to perception. At the same time, while the risks associated with mixed-script labels are clear, simply prohibiting them will not eliminate problems, especially where closely related scripts are involved. For example, there are many strings that are entirely in Greek or Cyrillic scripts that can be confused with each other or with Latin script strings.
複数の文字がラベルに表示され、ラベルが1つのスクリプトの文字のみで構成されている場合、個々の文字が別々に比較された場合、他の文字と混同される可能性のある個々の文字は、明確で非混乱がある場合があります。一方、その観察により、複数のスクリプト（「混合スクリプトラベル」と呼ばれることが多い）の文字を含むラベルがさらにリスクを冒します。同時に、混合スクリプトラベルに関連するリスクは明確ですが、特に密接に関連するスクリプトが関与している場合、それらを禁止するだけで問題がなくなることを禁止することはありません。たとえば、ギリシャ語またはキリル文字のスクリプトに完全に混乱したり、ラテンスクリプト文字列と混同したりすることができる多くの文字列があります。
It is worth noting that there are no comprehensive technical solutions to the problems of confusable characters. One can reduce the extent of the problems in various ways, but probably never eliminate it. Some specific suggestions about identification and handling of confusable characters appear in a Unicode Consortium publication [Unicode-UTR36].
混乱しやすいキャラクターの問題に対する包括的な技術的解決策はないことは注目に値します。問題の程度をさまざまな方法で減らすことができますが、おそらくそれを排除することはありません。混乱しやすい文字の識別と取り扱いに関するいくつかの特定の提案は、Unicode Consortiumの出版物[Unicode-UTR36]に表示されます。
The Protocol specification [RFC5891] describes procedures for registering and looking up labels that are not compatible with the preferred syntax described in the base DNS specifications (see Section 2.3.1) because they contain non-ASCII characters. These procedures depend on the use of a special ASCII-compatible encoding form that contains only characters permitted in hostnames by those earlier specifications. The encoding used is Punycode [RFC3492]. 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.
プロトコル仕様[RFC5891]は、ベースDNS仕様に記載されている優先構文と互換性がないラベルを登録および検索する手順を説明します（セクション2.3.1を参照）。これらの手順は、以前の仕様によってホスト名で許可されている文字のみを含む特別なASCII互換エンコードフォームの使用に依存します。使用されるエンコーディングはPunycode [RFC3492]です。文字列の長さの増加や新しい許可された値などのセキュリティの問題は、エンコードプロセスまたはこれらのエンコード値の使用によって導入されません。
Domain names (or portions of them) are sometimes compared against a set of domains to be given special treatment if a match occurs, e.g., treated as more privileged than others or blocked in some way. In such situations, it is especially important that the comparisons be done properly, as specified in the "Requirements" section of the Protocol document [RFC5891]. 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 although IDNA-aware applications are expected to look up only A-labels and NR-LDH labels, i.e., to avoid looking up R-LDH labels that are not A-labels.
ドメイン名（またはそれらの一部）は、一致が発生した場合、特別な治療を与えられるドメインのセットと比較されることがあります。このような状況では、プロトコルドキュメント[RFC5891]の「要件」セクションで指定されているように、比較を適切に実行することが特に重要です。既にASCII形式のラベルの場合、適切な比較は、ASCIIラベルに常に使用されている同じケースに依存しないASCII比較に減少しますが、IDNA認識アプリケーションはAラベルとNR-LDHラベルのみ、つまり、つまり、A-LabelsではないR-LDHラベルを調べないでください。
The introduction of IDNA meant that any existing labels that start with the ACE prefix would be construed as A-labels, at least until they failed one of the relevant tests, whether or not that was the intent of the zone administrator or registrant. There is no evidence that this has caused any practical problems since RFC 3490 was adopted, but the risk still exists in principle.
IDNAの導入は、ACEプレフィックスから始まる既存のラベルは、少なくとも関連するテストの1つに失敗するまで、ゾーン管理者または登録者の意図であるかどうかにかかわらず、A-Labelsとして解釈されることを意味しました。RFC 3490が採用されて以来、これが実際的な問題を引き起こしたという証拠はありませんが、リスクは原則として存在します。
The URI Standard [RFC3986] and a number of application specifications (e.g., SMTP [RFC5321] and HTTP [RFC2616]) do not permit non-ASCII labels in DNS names used with those protocols, i.e., only the A-label form of IDNs is permitted in those contexts. If only A-labels are used, differences in interpretation between IDNA2003 and this version arise only for characters whose interpretation have actually changed (e.g., characters, such as ZWJ and ZWNJ, that were mapped to nothing in IDNA2003 and that are considered legitimate in some contexts by these specifications). Despite that prohibition, there are a significant number of files and databases on the Internet in which domain name strings appear in native-character form; a subset of those strings use native-character labels that require IDNA2003 mapping to produce valid A-labels. The treatment of such labels will vary by types of applications and application-designer preference: in some situations, warnings to the user or outright rejection may be appropriate; in others, it may be preferable to attempt to apply the earlier mappings if lookup strictly conformant to these specifications fails or even to do lookups under both sets of rules. This general situation is discussed in more detail in the Rationale document [RFC5894]. However, in the absence of care by registries about how strings that could have different interpretations under IDNA2003 and the current specification are handled, it is possible that the differences could be used as a component of name-matching or name-confusion attacks. Such care is therefore appropriate.
URI標準[RFC3986]および多くのアプリケーション仕様（例：SMTP [RFC5321]およびHTTP [RFC2616]）は、これらのプロトコルで使用されるDNS名の非ASCIIラベルを許可しません。これらのコンテキストで許可されています。Aラベルのみが使用されている場合、IDNA2003とこのバージョン間の解釈の違いは、実際に変更された文字（ZWJやZWNJなどの文字がIDNA2003でマッピングされ、一部では合法と見なされている文字に対してのみ生じます。これらの仕様によるコンテキスト）。その禁止にもかかわらず、インターネット上には、ドメイン名の文字列がネイティブキャラクターの形で表示されるかなりの数のファイルとデータベースがあります。これらの文字列のサブセットは、有効なAラベルを生成するためにIDNA2003マッピングを必要とするネイティブキャラクターラベルを使用します。このようなラベルの処理は、アプリケーションの種類とアプリケーションデザイナーの好みによって異なります。状況によっては、ユーザーへの警告または完全な拒否が適切かもしれません。他の人では、これらの仕様に厳密に適合している場合、または両方のルールのセットで検索を行うために、以前のマッピングを適用しようとすることが望ましい場合があります。この一般的な状況については、Rationale Document [RFC5894]で詳しく説明します。ただし、IDNA2003の下で異なる解釈を持つ可能性のある文字列と現在の仕様が処理される方法についてのレジストリによるケアがない場合、違いは名前マッチングまたはネームコンファージョン攻撃のコンポーネントとして使用できる可能性があります。したがって、そのようなケアは適切です。
The registration and lookup models described in this set of documents change the mechanisms available for lookup applications to determine the validity of labels they encounter. In some respects, the ability to test is strengthened. For example, putative labels that contain unassigned code points will now be rejected, while IDNA2003 permitted them (see the Rationale document [RFC5894] for a discussion of the reasons for this). On the other hand, the Protocol specification no longer assumes that the application that looks up a name will be able to determine, and apply, information about the protocol version used in registration. In theory, that may increase risk since the application will be able to do less pre-lookup validation. In practice, the protection afforded by that test has been largely illusory for reasons explained in RFC 4690 [RFC4690] and elsewhere in these documents.
この一連のドキュメントで説明されている登録および検索モデルは、遭遇するラベルの妥当性を判断するために、ルックアップアプリケーションで利用可能なメカニズムを変更します。いくつかの点で、テストする能力が強化されます。たとえば、未割り当てのコードポイントを含む推定ラベルは拒否されますが、IDNA2003はそれらを許可しました（この理由の議論については、根拠文書[RFC5894]を参照）。一方、プロトコルの仕様では、名前を検索するアプリケーションが登録で使用されるプロトコルバージョンに関する情報を決定し、適用できることを想定しなくなりました。理論的には、アプリケーションの見栄え前の検証を少なくすることができるため、それはリスクを高める可能性があります。実際には、そのテストによって提供される保護は、RFC 4690 [RFC4690]およびこれらの文書の他の場所で説明されている理由で大部分が幻想的でした。
Any change to the Stringprep [RFC3454] procedure that is profiled and used in IDNA2003, or, more broadly, the IETF's model of the use of internationalized character strings in different protocols, creates some risk of inadvertent changes to those protocols, invalidating deployed applications or databases, and so on. But these specifications do not change Stringprep at all; they merely bypass it. Because these documents do not depend on Stringprep, the question of upgrading other protocols that do have that dependency can be left to experts on those protocols: the IDNA changes and possible upgrades to security protocols or conventions are independent issues.
IDNA2003でプロファイルおよび使用されるStringPrep [RFC3454]手順、またはより広く使用されている手順、またはより広く、異なるプロトコルでの国際化された文字列の使用のIETFのモデルの変更は、それらのプロトコルに不注意な変化のリスクを生み出し、展開された適用または侵害の適用のリスクを生み出します。データベースなど。しかし、これらの仕様はStringPrepをまったく変更しません。彼らは単にそれをバイパスするだけです。これらのドキュメントはStringPrepに依存していないため、その依存関係を持っている他のプロトコルをアップグレードするという問題は、それらのプロトコルの専門家に任せることができます。IDNAの変更とセキュリティプロトコルまたは慣習へのアップグレードの可能性は独立した問題です。
No mechanism involving names or identifiers alone can protect against a wide variety of security threats and attacks that are largely independent of the naming or identification system. These attacks include spoofed pages, DNS query trapping and diversion, and so on.
名前または識別子だけを含むメカニズムは、命名システムまたは識別システムに大きく依存しないさまざまなセキュリティの脅威と攻撃から保護できません。これらの攻撃には、スプーフィングされたページ、DNSクエリトラップや転用などが含まれます。
The initial version of this document was created largely by extracting text from early draft versions of the Rationale document [RFC5894]. See the section of this name and the one entitled "Contributors", in it.
このドキュメントの初期バージョンは、主に理論的ドキュメント[RFC5894]の初期ドラフトバージョンからテキストを抽出することによって作成されました。この名前のセクションと、「貢献者」と題されたセクションを参照してください。
Specific textual suggestions after the extraction process came from Vint Cerf, Lisa Dusseault, Bill McQuillan, Andrew Sullivan, and Ken Whistler. Other changes were made in response to more general comments, lists of concerns or specific errors from participants in the Working Group and other observers, including Lyman Chapin, James Mitchell, Subramanian Moonesamy, and Dan Winship.
抽出プロセス後の特定のテキストの提案は、ヴィントCerf、Lisa Dusseault、Bill McQuillan、Andrew Sullivan、Ken Whistlerから来ました。他の変更は、より一般的なコメント、ワーキンググループの参加者や、ライマンチャピン、ジェームズミッチェル、スブラマニアンムーネシップ、ダンウィンシップなど、他のオブザーバーの参加者からの特定のエラーに応じて行われました。
[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年のバージョンはインターネットにとって決定的なままです。
[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月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[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月。
[Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms, Revision 31", September 2009, <http://www.unicode.org/reports/tr15/tr15-31.html>.
[Unicode-uax15] Unicode Consortium、「Unicode Standard Annex＃15：Unicode Normalization Forms、Revision 31」、2009年9月、<http://www.unicode.org/reports/tr15/TR15-31.html>。
[Unicode52] The Unicode Consortium. The Unicode Standard, Version 5.2.0, defined by: "The Unicode Standard, Version 5.2.0", (Mountain View, CA: The Unicode Consortium, 2009. ISBN 978-1-936213-00-9). <http://www.unicode.org/versions/Unicode5.2.0/>.
[Unicode52] Unicodeコンソーシアム。Unicode標準バージョン5.2.0、「Unicode Standard、バージョン5.2.0」、（Mountain View、CA：Unicode Consortium、2009。ISBN 978-1-936213-00-9）で定義されています。<http://www.unicode.org/versions/unicode5.2.0/>。
[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月の作業。
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985.
[RFC0952] Harrenstien、K.、Stahl、M。、およびE. Feinler、「DODインターネットホストテーブル仕様」、RFC 952、1985年10月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、RFC 2181、1997年7月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.
[RFC2673] Crawford、M。、「ドメイン名システムのバイナリラベル」、RFC 2673、1999年8月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454] Hoffman、P。およびM. Blanchet、「国際化された文字列の準備（「StringPrep」）」、RFC 3454、2002年12月。
[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月。
[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月。
[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月。
[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月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]クレンシン、J。、「アプリケーションの国際化ドメイン名（IDNA）：プロトコル」、RFC 5891、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. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010.
[RFC5893] Alvestrand、H。およびC. Karp、「アプリケーションの国際化されたドメイン名（IDNA）の右から左へのスクリプト」、RFC 5893、2010年8月。
[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-UTR36] The Unicode Consortium, "Unicode Technical Report #36: Unicode Security Considerations, Revision 7", July 2008, <http://www.unicode.org/reports/tr36/tr36-7.html>.
[Unicode-UTR36] Unicode Consortium、「Unicode Technical Report＃36：Unicode Security Scomisations、Revision 7 "、2008年7月、<http://www.unicode.org/reports/tr36/tr36-7.html>。
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