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