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