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
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）のためのプロトコルと使用状況を説明し、コレクションの一つです。これは、文書コレクションについて説明し、セットに共通する定義と他の材料を提供します。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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.
この文書では、一緒に、シリーズ内および他の場所で「IDNA2008」として知られ、主に2008年に完成したアプリケーション（IDNA）のための国際化ドメイン名の改正のためのプロトコルと使用状況を説明し、コレクションの一つです。シリーズはIDNA [RFC3490] [RFC3491]の以前のバージョンを置き換えます。便宜上、IDNAのバージョンは「IDNA2003」として、これらの文書で言及されています。新しいバージョンは、ピュニコードアルゴリズム[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,
、どのような名前をDNSゾーンファイルで許可されているO
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.
プロトコルおよび説明資料とともに、関連するテーブルとIDNA2008につながっ決定するためのいくつかの根拠の概要を提供O文書、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".
コアIDNA2008プロトコルとその動作について説明した文書、RFC 5891 [RFC5891]、O。双方向の文書との組み合わせで、それが明示的に更新し、それが非公式に「プロトコル」として、セット内の他の文書で言及された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.
右から左に書かれている文字を含むラベルのための特別なルール（双方向）を指定した文書、RFC 5893 [RFC5893]、O。
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、カテゴリと（以下のセクション2.3.2.1で「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.
他の文字にマッピングする文字の問題について説明し、それが適切であるときには、そうするための指針を提供するドキュメント[IDNA2008-マッピング] O。その文書は、非公式に「マッピング」というアドバイスを提供します。それは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以上の文字を含む符号化された文字セットです。 Unicodeコードポイントの範囲はないプレフィックスと、「..」で区切られた2つの4〜6桁の16進数で表されている間、単一のUnicodeコードポイントは、4〜6桁の16進数字が続く「U +」によってこれらの文献に示されています。
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を論じる場合、この文書は、一般に、その後修飾[RFC1123]、[RFC2181]と[RFC1034]、[RFC1035] DNS仕様で使用される用語を想定しています。用語「ルックアップ」は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コードポイント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」、「例」、および「COM」：例えば、ドメイン名「www.example.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
これは、ホスト名、[RFC0952]に、いくつかの追加の制限はあるものの、使用古典ラベル形式です。 RFC 1123 [RFC1123]によって修正され、その構文は、RFC 1034 [RFC1034]のセクション3.5で「好ましい名前構文」として記載したものと同一です。簡単に言えば、それは
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.
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ラベルは（以下、「A-ラベル」と記載）IDNAによって使用される特殊なラベルおよびいくつかの追加の制限された形態（これも以下に記載）が挙げられます。
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ラベルの二つの新しいサブセットがIDNAの導入によって作成されます。これらは、予約LDHラベル（R-LDHのラベル）と非予約LDHラベル（NR-LDHのラベル）と呼ばれています。いくつかの他の文脈では「タグ付けされたドメイン名」として知られている予約LDHラベルは、それらに含まれるプロパティを持っている「 - 」第三及び第四文字で、それ以外LDHラベル規則に準拠しています。 R-LDHラベルのサブセットのみがIDNA対応のアプリケーションで使用することができます。そのサブセットは、接頭辞「xn--」（独立したケース）で始まるラベルのクラスで構成され、それ以外LDHラベルのための規則に準拠しています。そのサブセットは、文書のこのセットに「XN-ラベル」と呼ばれています。 XN-ラベルはさらに、その残りの文字（「xn--」後）（下記参照）は、有効なピュニコードアルゴリズムの出力[RFC3492]とされないものであるものに分けられます。彼らはまた、以下に説明IDNA-有効性のために他の基準を満たしている場合、有効なピュニコード出力されるXN-ラベルは、「A-ラベル」として知られています。 LDHのラベル（とは、実際に、任意のDNSラベル）以上の長さ63個のオクテットをしてはならないので、ピュニコードアルゴリズム由来XN-ラベルの部分は、せいぜい59 ASCII文字に制限されています。 「 - 」第三及び第四の位置に非予約LDHラベルはありません有効な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.
ネイティブのUnicode文字形式で有効な文字の制限の結果（U-ラベルを参照してください）RFC 3492の付録Aで概説したソートの混在ケース注釈、[RFC3492]であることが判明したが、便利なことはありません。有効なA-ラベルがUラベルのピュニコード符号化の結果であるので、したがって、A-ラベルは他の（混在ケースまたは大文字）と一致するにもかかわらず、小文字のみで製造されなければならないDNSにおける電位ラベル。
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対応のシステムでは、有効なラベルの種類は次のとおりです。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.
ACEで符号化された形式とUnicode（ネイティブ文字）形式：IDNAラベルは2つの種類があります。これらは、それぞれ、ラベルおよび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.
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：非ASCIIラベル
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-ラベル」、「U-ラベル」、および以下に定義されてそれぞれが「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-有効」です。 IDNA-有効な文字列は、すぐ下に定義された2つの形式のいずれかで表示されることがあり、またはNR-LDHラベルサブセットから引き出されます。 IDNA-有効な文字列も、ラベルのすべての基本的な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
「A-ラベル」O IDNA-有効な文字列の形式（ACE、セクション2.3.2.5を参照）ASCII互換エンコーディングです。それは完全なラベルでなければなりません：IDNAはないそれらの部品のためではなく、完全なドメイン名のために、ラベルのために定義されています。これは、すべてのA-ラベルはIDNA ACEプレフィックスで開始することを、定義によって、意味、「xn--」（セクション2.3.2.5を参照）、したがって、ピュニコードアルゴリズム[RFC3492]との有効な出力である文字列が続きます長さは59 ASCII文字の最大。プレフィックスと文字列が一緒に保存することができますラベルのすべての要件に適合しなければなりません
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.
LDHラベル（2.3.1項）のための規則への適合を含むDNS。上記の要件を満たす文字列が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ラベル」は、少なくとも1つの非ASCII文字を含むIDNA、有効な正規化形式C（NFC）のUnicode文字の文字列、および（例えば、UTF-8のような）標準のUnicodeエンコーディング形式で表現されます。また、第2条およびテーブルドキュメントの3に議定書の第4.2節とルールに指定されている使用できる文字についての制約を受けている、その文書で双方向の制約は、それが書かれたスクリプトからの任意の文字が含まれている場合右に左に、そして対称性の制約がすぐ下に説明。 U-ラベルと、ラベル間の変換は、必要に応じてACEプレフィックスを追加または削除、「ピュニコード」仕様[RFC3492]に従って実行されます。
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-ラベルA1は、UラベルU1からの変換によって生成されることが可能でなければならず、U-ラベルU1は、ラベルからの変換によって生成されることが可能でなければならないことA1。とりわけ、これは、UラベルとA-ラベルの両方がUnicode NFC [ユニコード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-ラベルまたはラベルのいずれかに適用されます。この原則には、2つの例外があります。まず、ASCII文字に制限はU-ラベルには適用されません。第二に、UラベルのA-ラベルフォームの膨張が原因ピュニコードアルゴリズムの圧縮効率に通常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.
コンテキストの場合、IDNA対応でないアプリケーションでは、のようにDNSゾーンファイルとクエリで外観のために有効な、そのうちのいくつかは、ラベル（すなわち、LDHの制限を課していない）の追加の種類を許可することができるすべてのLDHラベルを扱います。 IDNA対応アプリケーションは、ゾーンファイルとクエリに表示されるだけで、ラベルとNR-LDHラベルを許可します。 U-ラベルは他の二つと一緒に、プレゼンテーションやユーザーインターフェースの形で、および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つの許可されるカテゴリは、ラベル、Uラベル、およびNR-LDHラベルです。予約LDHラベル（R-LDHラベル）のみ、ラベルの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.
- ラベルまたは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-ラベルはA-ラベルテストの一部に失敗することが実証されている一方、未検証のA-ラベルは、XN-ラベルすることだけが知られています。同様に、未検証のU-ラベルは、またはU-ラベルの要件を満たしていない可能性があり、単純に非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.
これらの仕様は厳しく、セクション2.3.1で説明したLDHラベルの構文に従うと、それはIDNもIDNAによって予約ラベルフォーム（R-LDHラベルでもないすべての-ASCIIラベルを参照するための用語「NR-LDHラベル」を使用します）。全ラベルが「ホスト名」[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レジストリおよびゾーンのための必須です議定書の4.3節では、[RFC5891]一般的に、「レジストリの制限」として知られているこれらの制限は、のみ登録および処理をルックアップないことができるかに影響するので、彼らは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ラベル、ラベル、またはUラベルのいずれかであるかもしれない1。こうした三つのカテゴリーのいずれにも該当しないので、国際化ラベルではありませんん、サービスロケーション（SRV）レコード[RFC2782]のために使用される「アンダーラベル」、などいくつかの標準化された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-ラベルはケース非依存の比較で等しい場合には、ラベルは関係なく、それらがどのように表現されるか、同等とみなされていません。なぜならIDNA2008で、ラベルおよび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-標識の対間の一致。
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ラベルとの間の等価性は、A-ラベル状にUラベル形式を変換した後、通常の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コマンドまたは「から：」をパラメータに記号（「@」）における次の電子メールアドレスの一部電子メールメッセージヘッダのフィールドとそして、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対応のドメイン名スロット」は、明示的に、この文書で定義されている国際化ドメイン名を運ぶために指定されたドメイン名スロットであることを文書のこのセットのために定義されています。指定は、（例えば、プロトコルまたはインターフェースの仕様で）静的または（例えば、対話型セッションでネゴシエーションの結果として）動的であってもよいです。
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-認識していない名前のスロットは、明らかに、その仕様IDNAに先行する任意のドメイン名スロットを含みます。データストレージ用にDNSを使用するいくつかのプロトコルの要件は、IDNの使用を妨げることに注意してください。例えば、サービス・ロケーション・プロトコル[RFC2782]で使用されるアンダーラベルに必要な形式は、それらのSRV関連ラベルが下線で始まる必要があるため、ラベルを使用してDNSに非ASCIIラベルの表現を妨げます。もちろん、非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ラベルが右から左に、読み込まれた文字が含まれており、優先的に表示可能性があるため、ラベルの文字が「最初」であるかについての潜在的なあいまいさがあります。これらの仕様の目的のために、ラベルが考慮され、そして文字は、厳密に、彼らは「ワイヤに」表示される順序で、番号。そのためには、右にして最初の右から左に読まれているラベルにある右端の文字に残さ読まれるラベルの最初のものとして扱われている左端の文字に相当します。双方向の仕様では、順序を読んで影響を与える条件の追加の議論が含まれています。
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".
「ピュニコード文字列が」ないか、ACEプレフィックスが含まれていないかどうかについて、それは、そのような文字列がもしToASCII操作の出力されている可能性があることが必要であるかどうかについて、いくつかの混乱がありました（RFC 3490、セクション4を参照してください[RFC3490]）。この仕様は、符号化方式およびRFC 3492 [RFC3492]のアルゴリズム以外のものを記述するために用語「ピュニコード」の使用を阻止します。上記で定義された用語はできるだけ多く、より明確な用語「ピュニコード文字列」よりも好まれます。
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レジストリ間の関係の概要については、理論的根拠文書[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節を参照）。ゾーン管理者は、これが提起し、適切な措置をとる可能性のある問題に注意する必要があります。この問題に対するコンテキストは、根拠文書[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.
この文書に表示されたセキュリティの考慮材料に加えて、双方向のドキュメント[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での一般的な制限により、およびDNSへの実際の呼び出しで文字列が続く6ビットの文字列の長さとして扱う必要性によって63個のオクテットに制限されています。そのフォーマットは、ドットで区切られたラベル等の長さの文字列ペアとしてドメイン名の表現は、交換可能として扱われていることをいくつかの他のアプリケーションや、一般的に使用されます。 - ラベル（実際にはDNSで使用されるフォーム）はUTF-8よりも潜在的にはるかに圧縮されるので、U-ラベル全て従うこと（及びUTF-8は、一般的に、より圧縮され、UTF-16またはUTF-32に）関連の対称性（およびその他）のこれらの文書の制約は、潜在的に252の文字（Unicodeコードポイント）まで、かなり長くなることがあります。いくつかのような標識を含む完全修飾ドメイン名は明らかにもそのような名前の公称255オクテットの制限を超えることができます。 U-ラベルを使用したアプリケーションの作成者は、短い文字列が期待されている状況で、バッファオーバーフローと切り捨てエラーや攻撃を避けるために十分な注意を発揮しなければなりません。
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.
（時々「confusables」と呼ばれる）視覚的に類似している文字間の混乱を防ぐために、実装は、そのようなオミクロンなどのスクリプトを簡単に視覚的に混乱している文字を含む特にドメイン名が複数のスクリプトが含まれている視覚的な表示を、提供することが示唆されましたギリシャ語ラテン語のテキストと混合。このようなメカニズムは、名前がフォームを簡素化している、または大文字の「O」と小文字の「L」から0と1を区別するために、従来のものと簡体字中国語の文字の混合物が含まれている場合に表示するために使用することができます。 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コンソーシアムの出版[ユニコード-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.
彼らは非ASCII文字が含まれているためプロトコル仕様[RFC5891]は（2.3.1項を参照）をベースDNSの仕様に記載されている好ましい構文との互換性はありませんラベルを登録し、検索するための手順を説明します。これらの手順は、これらの以前の仕様により、ホスト名に許可された文字のみが含まれている特殊なASCII互換エンコード形式の使用に依存します。使用されるエンコーディングは、ピュニコード[RFC3492]です。そのような文字列の長さが増大したり、新しい許容値としてはセキュリティの問題は別としてACE符号化自体によって導入されたものから、符号化処理、またはこれらエンコードされた値を使用することにより導入されません。
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形式ですでにラベルのために、適切な比較はIDNA対応アプリケーションがに、すなわち、専用のラベルおよびNR-LDHのラベルを検索することが予想されるが、常にASCIIラベルに使用されてきた同じ大文字と小文字を区別しないASCII比較に減少し・ラベルではありません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プレフィックスで始まる既存のラベルは、-ラベルとして解釈されることを意味しました。 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ラベル、すなわち、のIDNの唯一のA-ラベルのフォームを許可していません。これらのコンテキストで許可されています。唯一、ラベルが使用されている場合は、IDNA2003と、このバージョンの間で解釈の違いが唯一その解釈は、実際に変更されている（例えば、IDNA2003で何にマップされたZWJとZWNJ、などの文字は、一部では正当とみなされる文字のために発生しますこれらの仕様によってコンテキスト）。その禁止にもかかわらず、ドメイン名の文字列はネイティブの文字の形で表示されているインターネット上のファイルとデータベースのかなりの数があります。これらの文字列のサブセットは、有効なA-ラベルを作成するためにIDNA2003マッピングを必要とするネイティブの文字のラベルを使用します。このような標識の治療は、アプリケーションとアプリケーション設計者の好みのタイプによって変化するであろう。いくつかの状況では、ユーザまたは完全に拒絶に警告が適切であり得ます。他では、これらの仕様に厳密に準拠したルックアップは、ルールの両方のセットの下で検索を行うにしても失敗した場合、またはそれ以前のマッピングを適用しようとすることが好ましいです。この一般的な状況は、理論的根拠文書[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のモデルは、デプロイされたアプリケーションまたはを無効に、これらのプロトコルへの不用意な変更のいくつかのリスクが発生しますその上のデータベース、および。しかし、これらの仕様は、すべての文字列準備を変更しないでください。彼らは単にそれをバイパスします。これらの文書は、文字列準備に依存しないので、その依存性は、これらのプロトコルの専門家に任せることができていない他のプロトコルのアップグレードの質問：セキュリティプロトコルまたは規則に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]の初期のドラフト版からテキストを抽出することにより、主に作成されました。それには、この名前のセクションと「協力者」と題する1を参照してください。
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.
抽出処理後の具体的なテキストの提案はヴィントン・サーフ、リサDusseault、ビルMcQuillan氏の説明による、アンドリュー・サリバン、とケンウィスラーから来ました。その他の変更は、より一般的なコメントに反応してライマンチャピン、ジェームス・ミッチェル、サブラマニアンMoonesamy、そしてダン・ウィンシップなどのワーキンググループの参加者と他のオブザーバーからの懸念や特定のエラーのリストを、作りました。
[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]米国規格協会（アメリカ規格協会の旧米国）、「情報交換用米国コード」、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]ブレーデン、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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>.
[ユニコード-UAX15]のUnicodeコンソーシアム、 "Unicode規格附属書＃15：Unicode正規化フォーム、リビジョン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標準、バージョン5.2.0"、（カリフォルニア州マウンテンビュー：ユニコードコンソーシアム、2009年ISBN 978-1-936213-00-9）によって定義されたUnicode標準、バージョン5.2.0、。 <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-マッピング]レズニック、P.およびP.ホフマン、「アプリケーションのための国際化ドメイン名でのマッピング文字（IDNA）」進行中、仕事、2010年4月。
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985.
[RFC0952] Harrenstien、K.、スタール、M.、およびE. Feinler、 "DoDのインターネットホストテーブル仕様"、RFC 952、1985年10月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
"DNS仕様の明確化" [RFC2181]エルツ、R.とR.ブッシュ、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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.
[RFC2673]クロフォード、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]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、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.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（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]ホフマン、P.とM.ブランシェ、 "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]コステロ、A.、 "ピュニコード：アプリケーションにおける国際化ドメイン名のUnicodeのブートストリングのエンコード（IDNA）"、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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、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.、カープ、C.、およびIAB、RFC 4690 "国際化ドメイン名（IDNの）のレビューと提言"、2006年9月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J.、 "簡易メール転送プロトコル"、RFC 5321、2008年10月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891] Klensin、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.、エド。、 "アプリケーションの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.カープ、 "アプリケーションのための国際化ドメイン名のために右から左へのスクリプト（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>.
[ユニコード-UTR36]のUnicodeコンソーシアム、 "Unicodeの技術レポート＃36：Unicodeのセキュリティ上の考慮事項、改訂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
ジョン・S Clensin 1770マサチューセッツアベニュー、隣接する322ケンブリッジ、MA 02140彼
Phone: +1 617 245 1457 EMail: john+ietf@jck.com
電話：+1 617 245 1457 Eメール：john+ietf@jck.com