Internet Architecture Board (IAB) D. Thaler
Request for Comments: 6055 Microsoft
Updates: 2130 J. Klensin
Category: Informational
ISSN: 2070-1721 S. Cheshire
Apple
February 2011
IAB Thoughts on Encodings for Internationalized Domain Names
Abstract
抽象
This document explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as UTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm. It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today.
この文書は、UTF-8とピュニコードアルゴリズムによって生成されるASCIIコンパチブルエンコーディングのような種々の符号化方式の使用から生じる国際化ドメイン名（IDNドメイン）の問題を探ります。これは、単一の符号化方法と、複雑な事務の状態が今日異なるエンコーディングを使用した結果としてされて終わるの合意の重要性に焦点を当てています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットアーキテクチャ委員会（IAB）の製品であり、IABは、永久的な記録を提供するために貴重なものとみなされたことの情報を表します。 IABによって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 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/rfc6055.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6055で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Use of Non-DNS Protocols . . . . . . . . . . . . . . . . . . . 9
3. Use of Non-ASCII in DNS . . . . . . . . . . . . . . . . . . . 10
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
7. IAB Members at the Time of Approval . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 20
The goal of this document is to explore what can be learned from some current difficulties in implementing Internationalized Domain Names (IDNs).
このドキュメントの目標は、国際化ドメイン名（IDNの）実装では、いくつかの現在の困難から学ぶことができるものを探ることです。
A domain name consists of a sequence of labels, conventionally written separated by dots. An IDN is a domain name that contains one or more labels that, in turn, contain one or more non-ASCII characters. Just as with plain ASCII domain names, each IDN label must be encoded using some mechanism before it can be transmitted in network packets, stored in memory, stored on disk, etc. These encodings need to be reversible, but they need not store domain names the same way humans conventionally write them on paper. For example, when transmitted over the network in DNS packets, domain name labels are *not* separated with dots.
ドメイン名はラベルの配列からなる、従来はドットで区切られ書かれました。 IDNは、順番に、1以上の非ASCII文字を含む、一つ以上のラベルを含むドメイン名です。単なるASCIIドメイン名と同じように、各IDNラベルは、これらのエンコーディングは可逆的である必要がなど、ディスク上に格納され、メモリに格納し、ネットワークパケットで送信することができます前に、いくつかのメカニズムを使用してエンコードする必要がありますが、彼らは店のドメイン名である必要はありません人間は、従来の紙の上にそれらを書くのと同じ方法。 DNSパケットでネットワークを介して送信する場合、例えば、ドメイン名のラベルが* *ドットで区切られていません。
Internationalized Domain Names for Applications (IDNA), discussed later in this document, is the standard that defines the use and coding of internationalized domain names for use on the public Internet [RFC5890]. An earlier version of IDNA [RFC3490] is now being phased out. Except where noted, the two versions are approximately the same with regard to the issues discussed in this document. However, some explanations appeared in the earlier documents that were no longer considered useful when the later revision was created; they are quoted here from the documents in which they appear. In addition, the terminology of the two versions differ somewhat; this document reflects the terminology of the current version.
このドキュメントで後述するアプリケーションのための国際化ドメイン名（IDNA）は、公共のインターネット[RFC5890]で使用するための国際化ドメイン名の使用およびコーディングを定義する標準です。 IDNA [RFC3490]の以前のバージョンは現在段階的に廃止されています。注記がある場合を除いて、2つのバージョンが約この文書で議論された問題に関しては同じです。しかし、いくつかの説明は以降のリビジョンが作成されたとき、もはや有用であると考えられた以前の文書に登場しました。彼らは、彼らが表示されている文書から、ここで引用しています。また、二つのバージョンの用語は幾分異なります。このドキュメントは、現在のバージョンの用語を反映しています。
Unicode [Unicode] is a list of characters (including non-spacing marks that are used to form some other characters), where each character is assigned an integer value, called a code point. In simple terms a Unicode string is a string of integer code point values in the range 0 to 1,114,111 (10FFFF in base 16). These integer code points must be encoded using some mechanism before they can be transmitted in network packets, stored in memory, stored on disk, etc. Some common ways of encoding these integer code point values in computer systems include UTF-8, UTF-16, and UTF-32. In addition to the material below, those forms and the tradeoffs among them are discussed in Chapter 2 of The Unicode Standard [Unicode].
ユニコード[UNICODE]は各文字が整数値を割り当てられている（いくつかの他の文字を形成するために使用される非間隔マークを含む）文字のリストは、コード・ポイントと呼ばれます。簡単に言えばUnicode文字列は、1114111の範囲0の整数コードポイント値の文字列（塩基16で10FFFF）です。これらの整数のコードポイントは、それらがコンピュータ・システムにおけるこれらの整数のコードポイント値をコードするいくつかの一般的な方法は、UTF-8、UTF-16が挙げられるなど、ディスク上に格納され、メモリに格納され、ネットワークパケットで送信されることができる前に、いくつかのメカニズムを使用して符号化されなければなりません、およびUTF-32。以下の物質に加えて、それらの形態およびそれらの間のトレードオフは、Unicode標準[UNICODE]の第2章に記載されています。
UTF-8 is a mechanism for encoding a Unicode code point in a variable number of 8-bit octets, where an ASCII code point is preserved as-is. Those octets encode a string of integer code point values, which represent a string of Unicode characters. The authoritative definition of UTF-8 is in Sections 3.9 and 3.10 of The Unicode Standard [Unicode], but a description of UTF-8 encoding can also be found in RFC 3629 [RFC3629]. Descriptions and formulae can also be found in Annex D of ISO/IEC 10646-1 [10646].
UTF-8は、そのままASCIIコードポイントが保存される8ビットオクテットの可変数にUnicodeコードポイントを符号化するための機構です。これらのオクテットは、Unicode文字列を表す整数コードポイント値の文字列をエンコードします。 UTF-8の正式な定義はセクション3.9およびUnicode標準[UNICODE]の3.10であるが、UTF-8エンコーディングの説明は、RFC 3629 [RFC3629]に見出すことができます。説明および数式はまた、ISO / IEC 10646-1の附属書D [10646]に見出すことができます。
UTF-16 is a mechanism for encoding a Unicode code point in one or two 16-bit integers, described in detail in Sections 3.9 and 3.10 of The Unicode Standard [Unicode]. A UTF-16 string encodes a string of integer code point values that represent a string of Unicode characters.
UTF-16は、セクション3.9およびユニコード規格の3.10に詳細に記載されている1つ又は2つの16ビット整数、[UNICODE]にUnicodeコードポイントを符号化するための機構です。 UTF-16の文字列は、Unicode文字列を表す整数コードポイント値の文字列を符号化します。
UTF-32 (formerly UCS-4), also described in Sections 3.9 and 3.10 of The Unicode Standard [Unicode], is a mechanism for encoding a Unicode code point in a single 32-bit integer. A UTF-32 string is thus a string of 32-bit integer code point values, which represent a string of Unicode characters.
UTF-32（以前はUCS-4）、また、セクション3.9およびUnicode標準[UNICODE]の3.10に記載され、1つの32ビット整数にUnicodeコードポイントを符号化するための機構です。 UTF-32の文字列は、このようにUnicode文字列を表す32ビット整数のコードポイント値の文字列です。
Note that UTF-16 results in some all-zero octets when code points occur early in the Unicode sequence, and UTF-32 always has all-zero octets.
コードポイントが初期Unicodeシーケンスで発生したときに、いくつかのすべてのゼロオクテットでそのUTF-16の結果を確認し、UTF-32は、常にすべてゼロオクテットを有しています。
IDNA specifies validity of a label, such as what characters it can contain, relationships among them, and so on, in Unicode terms. Valid labels can be in either "U-label" or "A-label" form, with the appropriate one determined by particular protocols or by context. U-label form is a direct representation of the Unicode characters using one of the encoding forms discussed above. This document discusses UTF-8 strings in many places. While all U-labels can be represented by UTF-8 strings, not all UTF-8 strings are valid U-labels (see Section 2.3.2 of the IDNA Definitions document [RFC5890] for a discussion of these distinctions). A-label form uses a compressed, ASCII-compatible encoding (an "ACE" in IDNA and other terminology) produced by an algorithm called Punycode. U-labels and
IDNAは、このような、それはUnicodeの用語で、その上、それらの間の関係を含み、そしてどのようなことができ文字として、ラベルの有効性を指定します。有効なラベルは、特定のプロトコルによって、または文脈によって決定される適切なものと、「U-標識」または「A-ラベル」形態のいずれかであることができます。 Uラベルの形態は、上述した符号化形式のいずれかを使用して、Unicode文字の直接表現です。この文書では、多くの場所でUTF-8文字列について説明します。すべてのU-ラベルがUTF-8文字列で表すことができますが、すべてではないUTF-8文字列は有効なU-ラベル（これらの区別の議論のためにIDNA定義文書[RFC5890]のセクション2.3.2を参照）があります。ラベルフォームがピュニコードと呼ばれるアルゴリズムによって生成される圧縮され、ASCIIコンパチブルエンコーディング（IDNAおよび他の用語で「ACE」）を使用します。 U-ラベルと
A-labels are duals of each other: transformations from one to the other do not lose information. The transformation mechanisms are specified in the IDNA Protocol document [RFC5891].
-ラベルは、互いの双対です：1から他方への変換は、情報を失うことはありません。変換機構は、IDNAプロトコルドキュメント[RFC5891]で指定されています。
Punycode [RFC3492] is thus a mechanism for encoding a Unicode string in an ASCII-compatible encoding, i.e., using only letters, digits, and hyphens from the ASCII character set. When a Unicode label that is valid under the IDNA rules (a U-label) is encoded with Punycode for IDNA purposes, it is prefixed with "xn--"; the result is called an A-label. The prefix convention assumes that no other DNS labels (at least no other DNS labels in IDNA-aware applications) are allowed to start with these four characters. Consequently, when A-label encoding is assumed, any DNS labels beginning with "xn--" now have a different meaning (the Punycode encoding of a label containing one or more non-ASCII characters) or no defined meaning at all (in the case of labels that are not IDNA-compliant, i.e., are not well-formed A-labels).
ピュニコード[RFC3492]はこのように、すなわち、ASCII文字セットから文字、数字、およびハイフンを使用して、ASCIIコンパチブルエンコーディングでUnicode文字列を符号化するための機構です。 IDNAルール（Uラベル）の下で有効であるユニコードラベルがIDNAのためにピュニコードで符号化されたとき、それは「xn--」が付いています。結果は、A-ラベルと呼ばれています。プレフィックス規則は、他のDNSラベル（IDNA対応アプリケーションでは、少なくともいない他のDNSラベルが）これらの4つの文字で開始する許可されないことを前提としています。ラベルのエンコーディングを想定した場合その結果、「xn--」で始まる任意のDNSラベルは今まったく異なる意味（一つ以上の非ASCII文字を含むラベルのピュニコードエンコーディング）、または全く意味を持っている（中IDNAに準拠していないラベルの場合、すなわち、）整形式A-ラベルではありません。
ISO-2022-JP [RFC1468] is a mechanism for encoding a string of ASCII and Japanese characters, where an ASCII character is preserved as-is. ISO-2022-JP is stateful: special sequences are used to switch between character coding tables. As a result, if there are lost or mangled characters in a character stream, it is extremely difficult to recover the original stream after such a lost character encoding shift.
ISO-2022-JP [RFC1468]はASCII文字はそのままで保存されるASCII、日本語の文字列を符号化するための機構です。 ISO-2022-JPは、ステートフルです：特別なシーケンスは、文字符号化テーブルを切り替えるために使用されています。文字ストリーム内の損失またはマングルされた文字がある場合、結果として、そのような失われた文字エンコーディングシフト後に元のストリームを復元することは極めて困難です。
Comparison of Unicode strings is not as easy as comparing ASCII strings. First, there are a multitude of ways to represent a string of Unicode characters. Second, in many languages and scripts, the actual definition of "same" is very context-dependent. Because of this, comparison of two Unicode strings must take into account how the Unicode strings are encoded. Regardless of the encoding, however, comparison cannot simply be done by comparing the encoded Unicode strings byte by byte. The only time that is possible is when the strings are both mapped into some canonical form and encoded the same way.
Unicode文字列の比較は、ASCII文字列を比較するのと同じくらい簡単ではありません。まず、Unicode文字の文字列を表現する多くの方法があります。第二に、多くの言語やスクリプトで、「同じ」の実際の定義は非常にコンテキスト依存です。このため、2つのUnicode文字列の比較では、Unicode文字列のエンコード方法を考慮に入れる必要があります。関係なく符号化の、しかし、比較は、単にバイトによってエンコードされたUnicode文字列のバイトを比較することによって行うことができません。文字列が両方のいくつかの標準形式にマップと同じように符号化されるときに可能である唯一の時間です。
In 1996 the IAB sponsored a workshop on character sets and encodings [RFC2130]. This document adds to that discussion and focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today.
1996年IABは、文字セットとエンコーディング[RFC2130]に関するワークショップを主催します。この文書では、その議論に追加し、単一の符号化とどのように複雑な事務の状態が今日異なるエンコーディングを使用した結果としてされて終わるの合意の重要性に焦点を当てています。
Different applications, APIs, and protocols use different encoding schemes today. Many of them were originally defined to use only ASCII. Internationalizing Domain Names in Applications (IDNA) [RFC5890] defines a mechanism that requires changes to applications, but in an attempt not to change APIs or servers, specifies that the
異なるアプリケーション、API、およびプロトコルは、今日の異なる符号化スキームを使用します。それらの多くは、もともとASCIIだけを使用するように定義されました。 [RFC5890]アプリケーション（IDNA）でドメイン名を国際は、アプリケーションへの変更を要求するメカニズムを定義しますが、APIまたはサーバーを変更しない試みで、ことを指定します
A-label format is to be used in many contexts. In some ways this could be seen as not changing the existing APIs, in the sense that the strings being passed to and from the APIs are still apparently ASCII strings. In other ways it is a very profound change to the existing APIs, because while those strings are still syntactically valid ASCII strings, they no longer mean the same thing that they used to. What looks like a plain ASCII string to one piece of software or library could be seen by another piece of software or library (with the application of out-of-band information) to be in fact an encoding of a Unicode string.
ラベルフォーマットは、多くの状況で使用されるべきです。いくつかの点で、これはAPIへのから渡される文字列は、まだ明らかにASCII文字列であるという意味では、既存のAPIを変更しないと見ることができます。これらの文字列はまだ構文的に有効なASCII文字列であるが、彼らはもはや彼らが使用していることと同じことを意味するので、他の方法では、既存のAPIに非常に重大な変化ではありません。どのようなソフトウェアやライブラリの1つのピースにプレーンなASCII文字列のように見えるが、実際にはUnicode文字列のエンコーディングであることを（アウト・オブ・バンド情報のアプリケーションとの）ソフトウェアやライブラリの別の部分で見ることができました。
Section 1.3 of the original IDNA specification [RFC3490] states:
元IDNA仕様[RFC3490]のセクション1.3で述べています：
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は名前がゾーンにコミットされる直前に使用されています。
Figure 1 depicts a simplistic architecture that a naive reader might assume from the paragraph quoted above. (A variant of this same picture appears in Section 6 of the original IDNA specification [RFC3490], further strengthening this assumption.)
図1は、ナイーブな読者は、上記引用の段落から想定かもしれない単純なアーキテクチャを示しています。 （同じ画像の変異体は、さらに、この仮定を強化し、元のIDNA仕様[RFC3490]のセクション6に表示されます。）
+-----------------------------------------+
|Host |
| +-------------+ |
| | Application | |
| +------+------+ |
| | |
| +----+----+ |
| | DNS | |
| | Resolver| |
| | Library | |
| +----+----+ |
| | |
+-----------------------------------------+
|
_________|_________
/ \
/ \
/ \
| Internet |
\ /
\ /
\___________________/
Simplistic Architecture
単純化したアーキテクチャ
Figure 1
図1
There are, however, two problems with this simplistic architecture that cause it to differ from reality.
それが現実と異なる場合がこの単純なアーキテクチャを持つ2つの問題は、しかし、があります。
First, resolver APIs on Operating Systems (OSs) today (Mac OS, Windows, Linux, etc.) are not DNS-specific. They typically provide a layer of indirection so that the application can work independent of the name resolution mechanism, which could be DNS, mDNS [DNS-MULTICAST], LLMNR [RFC4795], NetBIOS-over-TCP [RFC1001][RFC1002], hosts table [RFC0952], NIS [NIS], or anything else. For example, "Basic Socket Interface Extensions for IPv6" [RFC3493] specifies the getaddrinfo() API and contains many phrases like "For example, when using the DNS" and "any type of name resolution service (for example, the DNS)". Importantly, DNS is mentioned only as an example, and the application has no knowledge as to whether DNS or some other protocol will be used.
まず、オペレーティングシステム（OS）今日は（Mac OS、WindowsやLinuxなど）上のリゾルバAPIは、DNS固有のものではありません。アプリケーションがDNS、のmDNS [DNSマルチキャスト]、LLMNR [RFC4795]、NetBIOSのオーバーTCP [RFC1001]、[RFC1002]、ホストとすることができる名前解決メカニズムの独立して動作できるように、それらは、典型的には、間接の層を提供しますテーブル[RFC0952]、NIS [NIS]、または何か他のもの。例えば、「IPv6のための基本的なソケットインタフェース拡張」[RFC3493]ははgetaddrinfo（）APIを指定し、「例えば、DNS使用」と「（例えば、DNS）名前解決サービスのいずれかのタイプを」のような多くのフレーズが含まれています。重要なのは、DNSは、例として挙げられ、アプリケーションはDNSまたはいくつかの他のプロトコルが使用されるか否かの知識を持たないれます。
Second, even with the DNS protocol, private namespaces (sometimes including private uses of the DNS) do not necessarily use the same character set encoding scheme as the public Internet namespace.
第二に、でも、DNSプロトコルで、（時々、DNSの私的使用を含む）のプライベート名前空間は、必ずしも公共のインターネットの名前空間と同じ文字セット符号化方式を使用しないでください。
We will discuss each of the above issues in subsequent sections. For
reference, Figure 2 depicts a more realistic architecture on typical
hosts today (which don't have IDNA inserted as a shim immediately
above the DNS resolver library). More generally, the host may be
attached to one or more local networks, each of which may or may not
be connected to the public Internet and may or may not have a private
namespace.
+-----------------------------------------+
|Host |
| +-------------+ |
| | Application | |
| +------+------+ |
| | |
| +------+------+ |
| | Generic | |
| | Name | |
| | Resolution | |
| | API | |
| +------+------+ |
| | |
| +-----+------+---+--+-------+-----+ |
| | | | | | | |
| +-+-++--+--++--+-++---+---++--+--++-+-+ |
| |DNS||LLMNR||mDNS||NetBIOS||hosts||...| |
| +---++-----++----++-------++-----++---+ |
| |
+-----------------------------------------+
|
______|______
/ \
/ \
/ local \
\ network /
\ /
\_____________/
|
_________|_________
/ \
/ \
/ \
| Internet |
\ /
\ /
\___________________/
Realistic Architecture
現実的なアーキテクチャ
Figure 2
図2
Section 6.2 of the original IDNA specification [RFC3490] states (where ToASCII and ToUnicode below refer to conversions using the Punycode algorithm):
（もしToASCIIとのToUnicodeは以下ピュニコードアルゴリズムを使用してコンバージョンを参照）、元のIDNA仕様のセクション6.2 [RFC3490]の状態：
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以外の文字セットでドメイン名を受け入れることができるようになりますし、アプリケーション開発者が一日のための新しいAPIにローカルスクリプトでもUnicodeではないだけのドメイン名を渡すことが、可能性があることを期待されていますオペレーティングシステムのリゾルバのライブラリ。したがって、もしToASCIIとのToUnicode操作は、リゾルバのライブラリのこれらの新しいバージョンの内部で実行されることがあります。
Resolver APIs such as getaddrinfo() and its predecessor gethostbyname() were defined to accept C-Language "char *" arguments, meaning they accept a string of bytes, terminated with a NULL (0) byte. Because of the use of a NULL octet as a string terminator, this is sufficient for ASCII strings (including A-labels) and even ISO-2022-JP [RFC1468] and UTF-8 strings (unless an implementation artificially precludes them), but not UTF-16 or UTF-32 strings because a NULL octet could appear in the middle of strings using these encodings. Several operating systems historically used in Japan will accept (and expect) ISO-2022-JP strings in such APIs. Some platforms used worldwide also have new versions of the APIs (e.g., GetAddrInfoW() on Windows) that accept other encoding schemes such as UTF-16.
リゾルバのAPIなどのgetaddrinfo（）やその前身のgethostbyname（）は、彼らがNULL（0）バイトで終了バイトの文字列を、受け入れる意味、C言語「のchar *」引数を受け入れるように定義されていました。 （実装が人為的にそれらを排除しない限り）ため、文字列の終端としてNULLオクテットの使用は、これは、（ - ラベルを含む）ASCII文字列ともISO-2022-JP [RFC1468]とUTF-8文字列には十分であるが、ないUTF-16またはUTF-32文字列がNULLのオクテットは、これらのエンコーディングを使用して文字列の途中に現れる可能性があるため。歴史的に日本で使用され、いくつかのオペレーティングシステムが受け入れ（と期待）するようなAPIでISO-2022-JP文字列。世界中で使用されている一部のプラットフォームはまた、UTF-16などの他の符号化方式を受け入れる（Windows上例えば、GetAddrInfoW（））のAPIの新バージョンを持っています。
It is worth noting that an API using C-Language "char *" arguments can distinguish between conventional ASCII "hostname" labels, A-labels, ISO-2022-JP, and UTF-8 labels in names if the coding is known to be one of those four, and the label is intact (no lost or mangled characters). If a stateful encoding like ISO-2022-JP is used, applications extracting labels from text must take special precautions to be sure that the appropriate state-setting characters are included in the string passed to the API.
これは、コーディングがあることが知られている場合はC言語「のchar *」引数を使用してAPIが名前で、従来のASCIIの間で、「ホスト名」のラベル、A-ラベル、ISO-2022-JP、およびUTF-8のラベルを区別できることは注目に値しますこれら4つの1、およびラベルはそのままです（無損失またはマングル化された文字）。 ISO-2022-JPのようなステートフルエンコーディングが使用されている場合は、テキストからラベルを抽出するアプリケーションは、適切な状態設定の文字がAPIに渡された文字列に含まれていることを確認するために、特別な予防措置を講じなければなりません。
An example method for distinguishing among such codings is as follows:
次のようなコーディングを区別するための例示的な方法です。
o if the label contains an ESC (0x1B) byte, the label is ISO-2022-JP; otherwise,
ラベルは、ESC（として0x1B）バイトを含む場合、O、ラベルは、ISO-2022-JPです。そうでなければ、
o if any byte in the label has the high bit set, the label is UTF-8; otherwise,
ラベル内の任意のバイトは、高ビットがセットされている場合、O、ラベルは、UTF-8です。そうでなければ、
o if the label starts with "xn--", then it is presumed to be an A-label; otherwise,
ラベルは「xn--」で始まる場合、O、A-ラベルであると推定されます。そうでなければ、
o the label is ASCII (and therefore, by definition, the label is also UTF-8, since ASCII is a subset of UTF-8).
OラベルはASCII（そしてASCIIがUTF-8のサブセットであるので、従って、定義により、ラベルは、また、UTF-8です）。
Again this assumes that ASCII labels never start with "xn--", and also that UTF-8 strings never contain an ESC character. Also the above is merely an illustration; UTF-8 can be detected and distinguished from other 8-bit encodings with good accuracy [MJD].
再び、これはASCIIラベルは「xn--」で始まることはないと仮定し、また、そのUTF-8文字列は、ESC文字を含めることはありません。また、上記は単なる例示です。 UTF-8は検出され、精度良く[MJD]と他の8ビットエンコーディングと区別することができます。
It is more difficult or impossible to distinguish the ISO 8859 character sets [ISO8859] from each other, because they differ in up to about 90 characters that have exactly the same encodings, and a short string is very unlikely to contain enough characters to allow a receiver to deduce the character set. Similarly, it is not possible in general to distinguish between ISO-2022-JP and any other encoding based on ISO 2022 code table switching.
彼らはまったく同じエンコーディングを持つ約90文字までで異なり、短い文字列ができるように十分な文字が含まれていることがほとんどありませんので、お互いからISO 8859文字集合[ISO8859]を区別することはより困難または不可能です文字セットを推定する受信機。同様に、ISO-2022-JPとISO 2022符号表の切り替えに基づく任意の他の符号化を区別するために一般的に不可能です。
Although it is possible (as in the example above) to distinguish some encodings when not explicitly specified, it is cleaner to have the encodings specified explicitly, such as specifying UTF-16 for GetAddrInfoW(), or specifying explicitly which APIs expect UTF-8 strings.
それが明示的に指定しない場合、いくつかのエンコーディングを区別するために（上記の例のように）ことが可能であるが、このような）（GetAddrInfoWためUTF-16指定、又はAPIが期待れる明示指定として明示的に指定されたエンコーディングを有することがクリーンであるUTF-8文字列。
As noted earlier, typical name resolution libraries are not DNS-specific. Furthermore, some protocols are defined to use encoding forms other than IDNA A-labels. For example, mDNS [DNS-MULTICAST] specifies that UTF-8 be used. Indeed, the IETF policy on character sets and languages [RFC2277] (which followed the 1996 IAB-sponsored workshop [RFC2130]) states:
先に述べたように、一般的な名前解決ライブラリは、DNS固有のものではありません。さらに、いくつかのプロトコルはIDNA A-ラベル以外の符号化形式を使用するように定義されています。例えば、のmDNS [DNSマルチキャスト]はUTF-8を使用することを指定します。確かに、文字セットと言語[RFC2277]でIETF方針（1996 IAB主催のワークショップに続いて、[RFC2130]）は述べています：
Protocols MUST be able to use the UTF-8 charset, which consists of the ISO 10646 coded character set combined with the UTF-8 character encoding scheme, as defined in [10646] Annex R (published in Amendment 2), for all text.
プロトコルは[10646]アネックスR（修正2で発行）に定義されているすべてのテキストに、UTF-8文字コード体系と組み合わせるISO 10646符号化された文字セットからなるUTF-8文字セットを使用できなければなりません。
Protocols MAY specify, in addition, how to use other charsets or other character encoding schemes for ISO 10646, such as UTF-16, but lack of an ability to use UTF-8 is a violation of this policy; such a violation would need a variance procedure ([BCP9] section 9) with clear and solid justification in the protocol specification document before being entered into or advanced upon the standards track.
プロトコルは、UTF-16として、ISO 10646のために他の文字セットまたは他の文字符号化方式を使用する方法、ほかに指定することができるが、UTF-8を使用する能力の欠如は、このポリシーの違反です。入力され、または標準化過程の際に前進される前に、そのような違反は、プロトコル仕様書で明確かつ固体正当で分散手順（[BCP9]セクション9）を必要とするであろう。
For existing protocols or protocols that move data from existing datastores, support of other charsets, or even using a default other than UTF-8, may be a requirement. This is acceptable, but UTF-8 support MUST be possible.
既存のプロトコルまたはプロトコルの既存のデータストアからデータを移動し、他の文字セットをサポートするため、あるいは必要とすることができる、UTF-8以外のデフォルトを使用して。これは許容可能であるが、UTF-8のサポートが可能でなければなりません。
Applications that convert an IDN to A-label form before calling getaddrinfo() will result in name resolution failures if the Punycode name is directly used in such protocols. Having libraries or protocols to convert from A-labels to the encoding scheme defined by the protocol (e.g., UTF-8) would require changes to APIs and/or servers, which IDNA was intended to avoid.
ピュニコード名が直接そのようなプロトコルで使用されている場合はgetaddrinfoを呼び出す前にラベルのフォームにIDNを変換するアプリケーションは、（）名前解決の障害になります。プロトコル（例えば、UTF-8）で定義された符号化方式に-ラベルへ変換するライブラリまたはプロトコルを有するIDNAを回避することを意図したAPIおよび/またはサーバの変更を必要とするであろう。
As a result, applications that assume that non-ASCII names are resolved using the public DNS and blindly convert them to A-labels without knowledge of what protocol will be selected by the name resolution library, have problems. Furthermore, name resolution libraries often try multiple protocols until one succeeds, because they are defined to use a common namespace. For example, the hosts file [RFC0952], NetBIOS-over-TCP [RFC1001], and DNS [RFC1034], are all defined to be able to share a common syntax. This means that when an application passes a name to be resolved, resolution may in fact be attempted using multiple protocols, each with a potentially different encoding scheme. For this to work successfully, the name must be converted to the appropriate encoding scheme only after the choice is made to use that protocol. In general, this cannot be done by the application since the choice of protocol is not made by the application.
その結果、非ASCII名は盲目的にパブリックDNSを使って解決していることを前提としていたアプリケーションは、名前解決ライブラリによって選択されるか、プロトコルの知識がなくても、ラベルに変換、問題を抱えています。 1が成功するまで、共通の名前空間を使用するように定義されているので、さらに、名前解決ライブラリは、多くの場合、複数のプロトコルを試してみてください。例えば、ホストは、NetBIOSのオーバーTCP [RFC1001]、[RFC0952]ファイル、およびDNS [RFC1034]は、すべての一般的な構文を共有することができるように定義されます。これは、アプリケーションが解決する名前を通過する際に、解像度は、実際には複数のプロトコル、潜在的に異なる符号化方式とのそれぞれを使用して試みることができることを意味します。これが正常に機能するためには、名前を選択はそのプロトコルを使用するように作られた後にのみ、適切な符号化方式に変換する必要があります。プロトコルの選択は、アプリケーションによって行われていないので、一般的に、これはアプリケーションによって行うことができません。
A common misconception is that DNS only supports names that can be expressed using letters, digits, and hyphens.
一般的な誤解は、DNSのみ、文字、数字、ハイフンを使用して表現することができるの名前をサポートしていることです。
This misconception originally stems from the 1985 definition of an "Internet hostname" (and net, gateway, and domain name) for use in the "hosts" file [RFC0952]. An Internet hostname was defined therein as including only letters, digits, and hyphens, where uppercase and lowercase letters were to be treated as identical. The DNS specification [RFC1034], Section 3.5 entitled "Preferred name syntax" then repeated this definition in 1987, saying that this "syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET)".
この誤解は、もともと、「hosts」ファイル[RFC0952]で使用するために、「インターネットホスト名」（およびネット、ゲートウェイ、およびドメイン名）の1985年の定義に由来します。インターネットホスト名は大文字と小文字は同じものとして扱われるべきであった唯一の文字、数字、およびハイフンを含むようにその中に画定されました。 「優先名の構文」と題されたDNSの仕様[RFC1034]、セクション3.5は、この「構文は、ドメイン名（例えば、メール、TELNET）を使用する多くのアプリケーションで、より少ない問題が発生するだろう」と述べ、1987年にこの定義を繰り返しました。
The confusion was thus left as to whether the "preferred" name syntax was a mandatory restriction in DNS, or merely "preferred".
混乱は、このように「好ましい」名前の構文は必須制限がDNSにあった、または単に「優先」か否かの判断が残っていました。
The definition of an Internet hostname was updated in 1989 ([RFC1123], Section 2.1) to allow names starting with a digit. However, it did not address the increasing confusion as to whether all names in DNS are "hostnames", or whether a "hostname" is merely a special case of a DNS name.
インターネットホスト名の定義は、数字で始まる名前を許可するために1989（[RFC1123]、2.1節）で更新されました。しかし、それはDNS内のすべての名前は、「ホスト名」ある、または「ホスト名」は単にDNS名の特殊なケースであるかどうかかどうかについての増加の混乱に対処していませんでした。
By 1997, things had progressed to a state where it was necessary to clarify these areas of confusion. "Clarifications to the DNS Specification" [RFC2181], Section 11 states:
1997年までに、物事は、混乱のこれらの領域を明確にする必要があった状態に進行しました。 [RFC2181] "DNS仕様の明確化"、第11節の状態：
The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".". Those restrictions aside, any binary string whatever can be used as the label of any resource record. Similarly, any binary string can serve as the value of any record that includes a domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, and any others that may be added). Implementations of the DNS protocols must not place any restrictions on the labels that can be used.
DNS自体は、リソースレコードを識別するために使用することができ、特定のラベルにのみつの制限を配置します。それつの制限は、ラベルの長さとフルネームに関するものです。いずれかのラベルの長さは1〜63オクテットに制限されています。完全なドメイン名が（セパレータを含む）255オクテットに制限されています。ゼロ長フルネームは、DNSツリーのルートを表すものとして定義され、典型的に書き込まれたように表示されます「」。これらの制限はさておき、任意のリソースレコードのラベルとして使用することができますどのような任意のバイナリ文字列。同様に、任意のバイナリ文字列がその値（SOA、NS、MX、PTR、CNAME、および添加することができる任意の他のもの）の一部または全部としてドメイン名を含む任意のレコードの値としての役割を果たすことができます。 DNSプロトコルの実装は使用することができ、ラベル上の任意の制限を置かないでなければなりません。
Hence, it clarified that the restriction to letters, digits, and hyphens does not apply to DNS names in general, nor to records that include "domain names". Hence, the "preferred" name syntax described in the original DNS specification [RFC1034] is indeed merely "preferred", not mandatory.
したがって、それは文字、数字、およびハイフンに制限が一般的で、また「ドメイン名」が含まれるレコードへのDNS名には適用されないことを明らかにしました。したがって、元のDNS仕様[RFC1034]に記載された「好ましい」名の構文は、確か単に必須ではなく、「好ましい」です。
Since there is no restriction even to ASCII, let alone letter-digit-hyphen use, DNS does not violate the subsequent IETF requirement to allow UTF-8 [RFC2277].
でもASCIIに制限はありませんので、単独の文字桁ハイフンの使用を聞かせて、その後のIETFの要件に違反していないDNSは、UTF-8 [RFC2277]を許可します。
Using UTF-16 or UTF-32 encoding, however, would not be ideal for use in DNS packets or C-Language "char *" APIs because existing software already uses ASCII, and UTF-16 and UTF-32 strings can contain all-zero octets that existing software will interpret as the end of the string. To use UTF-16 or UTF-32, one would need some way of knowing whether the string was encoded using ASCII, UTF-16, or UTF-32, and indeed for UTF-16 or UTF-32 whether it was big-endian or little-endian encoding. In contrast, UTF-8 works well because any 7-bit ASCII string is also a UTF-8 string representing the same characters.
既存のソフトウェアは、すでにASCIIを使用し、UTF-16とUTF-32文字列がオール含めることができるので、UTF-16またはUTF-32エンコーディングを使用して、しかし、DNSパケットまたはC言語「のchar *」のAPIでの使用に理想的ではないであろう既存のソフトウェアは、文字列の最後として解釈されますゼロのオクテット。 UTF-16またはUTF-32を使用するためには、それはビッグエンディアンであったかどうか文字列はASCII、UTF-16、またはUTF-32を使用してエンコードされたかどうかを知ることのいくつかの方法を必要とし、実際にUTF-16またはUTF-32のためでしょうまたはリトルエンディアンエンコーディング。すべての7ビットASCII文字列でも同じ文字を表すUTF-8文字列であるため、これとは対照的に、UTF-8がうまく動作します。
If a private namespace is defined to use UTF-8 (and not other encodings such as UTF-16 or UTF-32), there's no need for a mechanism to know whether a string was encoded using ASCII or UTF-8, because (for any string that can be represented using ASCII) the representations are exactly the same. In other words, for any string that can be represented using ASCII, it doesn't matter whether it is interpreted as ASCII or UTF-8 because both encodings are the same, and for any string that can't be represented using ASCII, it's obviously UTF-8. In addition, unlike UTF-16 and UTF-32, ASCII and UTF-8 are both byte-oriented encodings so the question of big-endian or little-endian encoding doesn't apply.
プライベート名前空間がUTF-8（およびないなどUTF-16またはUTF-32などの他のエンコーディング）を使用するように定義されている場合は、文字列がASCIIまたはUTF-8を使用してエンコードされたかどうかを知るためのメカニズムのための必要はありません、（のための理由ASCIIを使用して表すことができる任意の文字列）の表現はまったく同じです。両方のエンコーディングが同じで、ASCIIを使って表現することはできません任意の文字列のために、それはだから、他の言葉では、ASCIIを使用して表すことができ、任意の文字列のために、ASCIIまたはUTF-8として解釈されているかどうかは問題ではありません。明らかにUTF-8。ビッグエンディアンかリトルエンディアンエンコーディングの問題は適用されませんので、また、UTF-16とUTF-32、ASCIIとは異なりUTF-8には、両方のバイト指向エンコーディングがあります。
While implementations of the DNS protocol must not place any restrictions on the labels that can be used, applications that use the DNS are free to impose whatever restrictions they like, and many have. The above rules permit a domain name label that contains unusual characters, such as embedded spaces, which many applications consider a bad idea. For example, the original specification [RFC0821] of the SMTP protocol [RFC5321] constrains the character set usable in email addresses. There is now an effort underway to define an extension to SMTP to support internationalized email addresses and headers. See the EAI framework [RFC4952] for more discussion on this topic.
DNSプロトコルの実装が使用できる標識に制限を置かないでなければなりませんが、DNSを使用するアプリケーションは、彼らが好きな制限が課されるために自由であり、多くは持っています。上記のルールは、このような多くのアプリケーションが悪いアイデアを検討埋め込みスペース、など、異常な文字を含むドメイン名のラベルを許可します。例えば、SMTPプロトコル[RFC5321]の元の仕様[RFC0821]は電子メールアドレスに使用可能な文字セットを制約します。国際化電子メールアドレスとヘッダをサポートするために、SMTPの拡張を定義するために進行中の努力が用意されました。このトピックの詳細な議論のためのEAIフレームワーク[RFC4952]を参照してください。
Shortly after the DNS Clarifications [RFC2181] and IETF character sets and languages policy [RFC2277] were published, the need for internationalized names within private namespaces (i.e., within enterprises) arose. The current (and past, predating IDNA and the prefixed ACE conventions) practice within enterprises that support other languages is to put UTF-8 names in their internal DNS servers in a private namespace. For example, "Using the UTF-8 Character Set in the Domain Name System" [UTF8-DNS] was first written in 1997, and was then widely deployed in Windows. The use of UTF-8 names in DNS was similarly implemented and deployed in Mac OS, simply by virtue of the fact that applications blindly passed UTF-8 strings to the name resolution APIs, the name resolution APIs blindly passed those UTF-8 strings to the DNS servers, and the DNS servers correctly answered those queries. From the user's point of view, everything worked properly without any special new code being written, except that ASCII is matched case-insensitively whereas UTF-8 is not (although some enterprise DNS servers reportedly attempt to do case-insensitive matching on UTF-8 within private namespaces, an action that causes other problems and violates a subsequent prohibition [RFC4343]). Within a private namespace, and especially in light of the IETF UTF-8 policy [RFC2277], it was reasonable to assume that binary strings were encoded in UTF-8.
まもなくDNS明確化[RFC2181]とIETFの文字セットと言語政策[RFC2277]が発表された、（すなわち、企業内の）プライベート名前空間内の国際名の必要性の後に起こりました。他の言語をサポートし、企業内の現在（および過去、IDNAとプレフィックスACEの規則より以前の）練習は、プライベート名前空間で、内部DNSサーバでUTF-8名を置くことです。たとえば、[UTF8-DNS]「ドメインネームシステムでUTF8文字セットを使用すると、」最初の1997年に書かれた、そして広くWindowsで展開されました。 DNSでのUTF-8名の使用は、同様に、アプリケーションが盲目的に名前解決のAPIへのUTF-8文字列を渡され、名前解決APIは盲目的にそれらのUTF-8文字列を渡すことを単に事実のおかげで、マックOSに実装され、展開されましたDNSサーバ、DNSサーバが正しくこれらのクエリに答え。 UTF-8ではないのに対し、そのASCIIは大文字と小文字を区別せずにマッチしている以外ユーザの視点から見ると、すべてが、特別な新しいコードが書き込まれてなくても正常に働いていた（一部のエンタープライズDNSサーバは伝えUTF-8に大文字と小文字を区別しないマッチングを行うことを試みるが、プライベート名前空間内の、他の問題を引き起こし、それに続く禁止[RFC4343]に違反アクション）。プライベート名前空間内、特にIETF UTF-8ポリシー[RFC2277]の光では、バイナリ文字列がUTF-8でエンコードされたと仮定することは合理的でした。
As implied earlier, there are also issues with mapping strings to some canonical form, independent of the encoding. Such issues are not discussed in detail in this document. They are discussed to some extent in, for example, Section 3 of "Unicode Format for Network Interchange" [RFC5198], and are left as opportunities for elaboration in other documents.
以前に示唆されるように、エンコーディングの独立したいくつかの標準的な形式にマッピングする文字列を、との問題もあります。このような問題は、この文書で詳しく説明されていません。彼らは、「ネットワークインターチェンジのUnicodeフォーマット」の例については、第3節[RFC5198]である程度説明され、および他の文書に精緻化のための機会として残されています。
A few years after UTF-8 was already in use in private namespaces in DNS, the strategy of using a reserved prefix and an ASCII-compatible encoding (ACE) was developed for IDNA. That strategy included the Punycode algorithm, which began to be developed (during the period from 2002 [IDN-PUNYCODE] to 2003 [RFC3492]) for use in the public DNS namespace. There were a number of reasons for this. One such reason the prefixed ACE strategy was selected for the public DNS namespace had to do with the fact that other encodings such as ISO 8859-1 were also in use in DNS and the various encodings were not necessarily distinguishable from each other. Another reason had to do with concerns about whether the details of IDNA, including the use of the Punycode algorithm, were an adequate solution to the problems that were posed. If either the Punycode algorithm or fundamental aspects of character handling were wrong, and had to be changed to something incompatible, it would be possible to switch to a new prefix or adopt another model entirely. Only the part of the public DNS namespace that starts a label with "xn--" would be polluted.
UTF-8は、DNS内のプライベート名前空間ですでに使用されていた数年後、予約済みのプレフィックスとASCII互換エンコーディング（ACE）を使用しての戦略がIDNAのために開発されました。その戦略は、パブリックDNS名前空間での使用のために（2003年から2002年までの期間中に[IDN-PUNYCODE] [RFC3492]）が開発されるようになったピュニコードアルゴリズムを、含まれていました。その理由はいくつかありました。接頭辞ACE戦略が公共のDNS名前空間のために選択された一つのそのような理由は、ISO 8859-1など、他のエンコーディングがDNSでの使用にもしており、さまざまなエンコーディングが必ずしも互いに区別はありませんでしたという事実としなければなりませんでした。もう一つの理由は、ピュニコードアルゴリズムの使用を含むIDNAの詳細は、提起された問題の適切な解決策だったかどうかについての懸念としなければなりませんでした。ピュニコードアルゴリズムや文字の取り扱いの基本的な側面のどちらかが間違っていた、と互換性のないものに変更する必要があった場合は、新しいプレフィックスに切り替えるか、完全に別のモデルを採用することも可能です。 「xn--」とラベルを開始し、パブリックDNS名前空間の一部のみが汚染されるだろう。
Today the algorithm is seen as being about as good as it can realistically be, so moving to a different encoding (UTF-8 as suggested in this document) that can be viewed as "native" would not be as risky as it would have been in 2002.
今日は、このアルゴリズムは、それがあったであろうようとして危険ではない「ネイティブ」とみなすことができる（この文書で提案されているようにUTF-8）別のエンコーディングに移動し、それが現実的に可能な限り良い程度であるものとして見られています2002インチ
In any case, the publication of Punycode [RFC3492] and the dependencies on it in the IDNA Protocol document [RFC5891] and the earlier IDNA specification [RFC3490] thus resulted in having to use different encodings for different namespaces (where UTF-8 for private namespaces was already deployed). Hence, referring back to Figure 2, a different encoding scheme may be in use on the Internet vs. a local network.
いずれの場合においても、ピュニコード[RFC3492]とIDNAプロトコル文書におけるその依存関係[RFC5891]の出版物およびそれ以前IDNA仕様[RFC3490]は、したがって、異なる名前空間の異なるエンコーディングを（使用する必要が生じた場合UTF-8プライベート用名前空間はすでに）展開されました。従って、背面図2を参照すると、異なる符号化方式は、ローカルネットワーク対インターネット上で使用されてもよいです。
In general, a host may be connected to zero or more networks using private namespaces, plus potentially the public namespace. Applications that convert a U-label form IDN to an A-label before calling getaddrinfo() will incur name resolution failures if the name is actually registered in a private namespace in some other encoding (e.g., UTF-8). Having libraries or protocols convert from A-labels to the encoding used by a private namespace (e.g., UTF-8) would require changes to APIs and/or servers, which IDNA was intended to avoid.
一般的には、ホストは、プライベート名前空間に加えて、潜在的に公共の名前空間を使用して、ゼロまたはそれ以上のネットワークに接続することができます。名前は実際にいくつかの他の符号化（例えば、UTF-8）でのプライベート名前空間に登録されている場合（getaddrinfoはを呼び出す前に、A-ラベルにU-ラベル形式IDNを変換するアプリケーションは）名前解決の失敗が発生します。持つライブラリやプロトコルはプライベートのネームスペースで使用されるエンコーディングに-ラベルから変換する（例えば、UTF-8）IDNAを避けるために意図されたAPIおよび/またはサーバへの変更が必要となります。
Also, a fully-qualified domain name (FQDN) to be resolved may be obtained directly from an application, or it may be composed by the DNS resolver itself from a single label obtained from an application by using a configured suffix search list, and the resulting FQDN may use multiple encodings in different labels. For more information on the suffix search list, see Section 6 of "Common DNS Implementation Errors and Suggested Fixes" [RFC1536], the DHCP Domain Search Option [RFC3397], and Section 4 of "DNS Configuration options for DHCPv6" [RFC3646].
また、解決される完全修飾ドメイン名（FQDN）は、アプリケーションから直接得ることができる、又はそれは、設定サフィックス検索リストを使用して、アプリケーションから得られた単一のラベルからDNSリゾルバ自体によって構成されていてもよい、及びFQDNを得、異なるラベルで複数のエンコーディングを使用してもよいです。サフィックス検索一覧の詳細については、「一般的なDNSの実装のエラーと推奨修正」[RFC1536]、DHCPドメイン検索オプション[RFC3397]、および「DHCPv6のDNSの設定オプション」の第4節[RFC3646]のセクション6を参照してください。
As noted in Section 6 of "Common DNS Implementation Errors and Suggested Fixes" [RFC1536], the community has had bad experiences (e.g., security problems [RFC1535]) with "searching" for domain names by trying multiple variations or appending different suffixes. Such searching can yield inconsistent results depending on the order in which alternatives are tried. Nonetheless, the practice is widespread and must be considered.
第6節で述べた「一般的なDNSの実装のエラーと修正提案」[RFC1536]を通り、社会が悪い経験を持っていた（例えば、セキュリティ問題[RFC1535]）複数のバリエーションをしようとか、別のサフィックスを追加することで、ドメイン名を「検索」を持ちます。そのような検索は、選択肢が試行される順序に応じて一貫性のない結果を得ることができます。それにもかかわらず、実際には広まっていると考えなければなりません。
The practice of searching for names, whether by the use of a suffix search list or by searching in different namespaces, can yield inconsistent results. For example, even when a suffix search list is only used when an application provides a name containing no dots, two clients with different configured suffix search lists can get different answers, and the same client could get different answers at different times if it changes its configuration (e.g., when moving to another network). A deeper discussion of this topic is outside the scope of this document.
かどうかサフィックス検索一覧を使用することによって、または異なる名前空間で検索することで、名前を検索するの実践は、一貫性のない結果をもたらすことができます。例えば、でもアプリケーションがドットを含まない名前を提供したときにサフィックス検索一覧にのみ使用されている場合、異なる構成されたサフィックス検索リストは異なる回答を得ることができ、そしてそれはそのを変更した場合、同じクライアントが異なる時間に異なる答えを得ることができるとの2つのクライアントコンフィギュレーション（例えば、別のネットワークに移動するとき）。このトピックのより深い議論は、この文書の範囲外です。
Some examples of cases that can happen in existing implementations today (where {non-ASCII} below represents some user-entered non-ASCII string) are:
今日の既存の実装で発生する可能性症例のいくつかの例は、（ここで、{非ASCII}以下、いくつかのユーザが入力した非ASCII文字列を表す）です。
o User types in {non-ASCII}.{non-ASCII}.com, and the application passes it, in the form of a UTF-8 string, to getaddrinfo() or gethostbyname() or equivalent.
Oユーザー{非ASCII}でタイプ。{非ASCII} .COM、およびアプリケーションが（）またはのgethostbyname（）または同等のgetaddrinfoするために、UTF-8文字列の形で、それを通過します。
1. The DNS resolver passes the (UTF-8) string unmodified to a DNS server.
1. DNSリゾルバは、DNSサーバに修飾されていない（UTF-8）文字列を渡します。
o User types in {non-ASCII}.{non-ASCII}.com, and the application passes it to a name resolution API that accepts strings in some other encoding such as UTF-16, e.g., GetAddrInfoW() on Windows.
{非ASCII}におけるOユーザタイプ。{非ASCII} .COM、およびアプリケーションは、UTF-16、例えば、GetAddrInfoW（）Windowsのようなコードいくつかの他の文字列を受け付ける名前解決APIに渡します。
1. The name resolution API decides to pass the string to DNS (and possibly other protocols).
1.名前解決APIは、DNS（そしておそらく他のプロトコル）に文字列を渡すことにしました。
2. The DNS resolver converts the name from UTF-16 to UTF-8 and passes the query to a DNS server.
2. DNSリゾルバは、UTF-8とUTF-16から名前を変換してDNSサーバにクエリを渡します。
o User types in {non-ASCII}.{non-ASCII}.com, but the application first converts it to A-label form such that the name that is passed to name resolution APIs is (say) xn--e1afmkfd.xn--80akhbyknj4f.com.
Oユーザー{非ASCII}でタイプ{非ASCII} .COMが、アプリケーションが最初に名前解決のAPIに渡される名前は、（例えば）XNなるように、ラベル形式に変換 - 。e1afmkfd.xn --80akhbyknj4f.com。
1. The name resolution API decides to pass the string to DNS (and possibly other protocols).
1.名前解決APIは、DNS（そしておそらく他のプロトコル）に文字列を渡すことにしました。
3. If the name is not found in DNS, the name resolution API decides to try another protocol, say mDNS.
名前がDNSで見つからない場合は3、名前解決のAPIは、別のプロトコルを試しすることを決定し、mDNSのは言います。
4. The query goes out in mDNS, but since mDNS specified that names are to be registered in UTF-8, the name isn't found since it was encoded as an A-label in the query.
4.クエリはmDNSの中に出て行くが、mDNSの名前がUTF-8に登録することを指定したので、それは、クエリ内のA-ラベルとしてエンコードされたため、名前が見つかりません。
o User types in {non-ASCII}, and the application passes it, in the form of a UTF-8 string, to getaddrinfo() or equivalent.
Oユーザー{非ASCII}でタイプ、及びアプリケーションがUTF-8文字列の形で、それを通過するには、（）または同等のgetaddrinfoします。
1. The name resolution API decides to pass the string to DNS (and possibly other protocols).
1.名前解決APIは、DNS（そしておそらく他のプロトコル）に文字列を渡すことにしました。
2. The DNS resolver will append suffixes in the suffix search list, which may contain UTF-8 characters if the local network uses a private namespace.
2. DNSリゾルバは、ローカルネットワークがプライベート名前空間を使用する場合はUTF-8文字を含む可能性がある、サフィックス検索一覧にサフィックスを追加します。
3. Each FQDN in turn will then be sent in a query to a DNS server, until one succeeds.
1が成功するまで順番に3.各FQDNはその後、DNSサーバへのクエリで送信されます。
o User types in {non-ASCII}, but the application first converts it to an A-label, such that the name that is passed to getaddrinfo() or equivalent is (say) xn--e1afmkfd.
Oユーザー{非ASCII}でタイプが、アプリケーションは、第1のA-ラベルに変換し、（のgetaddrinfoに渡される名前）または同等の（例えば）XNとなるよう - e1afmkfd。
1. The name resolution API decides to pass the string to DNS (and possibly other protocols).
1.名前解決APIは、DNS（そしておそらく他のプロトコル）に文字列を渡すことにしました。
2. The DNS stub resolver will append suffixes in the suffix search list, which may contain UTF-8 characters if the local network uses a private namespace, resulting in (say) xn--e1afmkfd.{non-ASCII}.com
2. DNSスタブリゾルバは、ローカルネットワークは、（例えば）XNで、その結果、民間のネームスペースを使用する場合はUTF-8文字を含む可能性がある、サフィックス検索一覧にサフィックスを追加します - 。e1afmkfd {非ASCII} .COM
3. Each FQDN in turn will then be sent in a query to a DNS server, until one succeeds.
1が成功するまで順番に3.各FQDNはその後、DNSサーバへのクエリで送信されます。
4. Since the private namespace in this case uses UTF-8, the above queries fail, since the A-label version of the name was not registered in that namespace.
4.この場合、プライベート名前空間はUTF-8を使用していますので、名前のA-ラベルのバージョンはその名前空間に登録されていなかったことから、上記のクエリは、失敗します。
o User types in {non-ASCII1}.{non-ASCII2}.{non-ASCII3}.com, where {non-ASCII3}.com is a public namespace using IDNA and A-labels, but {non-ASCII2}.{non-ASCII3}.com is a private namespace using UTF-8, which is accessible to the user. The application passes the name, in the form of a UTF-8 string, to getaddrinfo() or equivalent.
{非ASCII1}中のOユーザータイプ。{非ASCII2}。{非ASCII3} .COM、{非ASCII3} .COM IDNAを使用して、パブリック名前空間と、ラベルが、{非ASCII2}。 {非ASCII3} .COMは、ユーザにアクセス可能であるUTF-8を使用してプライベート名前空間です。アプリケーションは、（）または同等のgetaddrinfoするために、UTF-8文字列の形式で名前を渡します。
1. The name resolution API decides to pass the string to DNS (and possibly other protocols).
1.名前解決APIは、DNS（そしておそらく他のプロトコル）に文字列を渡すことにしました。
2. The DNS resolver tries to locate the authoritative server, but fails the lookup because it cannot find a server for the UTF-8 encoding of {non-ASCII3}.com, even though it would have access to the private namespace. (To make this work, the private namespace would need to include the UTF-8 encoding of {non-ASCII3}.com.)
2. DNSリゾルバは、それがプライベート名前空間へのアクセスを持っているでしょうにもかかわらず、権限のあるサーバーを検索しようと、それは{非ASCII3} .COMのUTF-8エンコーディング用のサーバーを見つけることができないため、ルックアップに失敗しました。 （この作業を行うには、プライベート名前空間は{非ASCII3} .COMのUTF-8エンコーディングを含める必要があります。）
When users use multiple applications, some of which do A-label conversion prior to passing a name to name resolution APIs, and some of which do not, odd behavior can result which at best violates the Principle of Least Surprise, and at worst can result in security vulnerabilities.
ユーザーが複数のアプリケーションを使用する場合は、そのうちのいくつかは、以前の名前解決のAPIに名前を渡すには、ラベルの変換を行うと、そのうちのいくつかは、奇妙な振る舞いは、せいぜい最小サプライズの原則に違反し、最悪の場合生じる可能性が生じることはありませんセキュリティの脆弱性インチ
First consider two competing applications, such as web browsers, that are designed to achieve the same task. If the user types the same name into each browser, one may successfully resolve the name (and hence access the desired content) because the encoding scheme is correct, while the other may fail name resolution because the encoding scheme is incorrect. Hence the issue can incent users to switch to another application (which in some cases means switching to an IDNA application, and in other cases means switching away from an IDNA application).
まず、このような同じタスクを達成するために設計されているWebブラウザ、などの2つの競合するアプリケーションを、検討します。各ブラウザにユーザタイプ同じ名前場合、一方が正常に名前を解決することができる（したがって、所望のコンテンツにアクセスする）符号化方式が正しいので、符号化方式が正しくないため、他の名前解決が失敗する可能性がありながら、。したがって問題は、ユーザーが別のアプリケーションに切り替える（いくつかのケースではIDNAのアプリケーションへの切り替えを意味し、他の場合にはIDNAアプリケーションから離れ切替手段）するincentができます。
Next consider two separate applications where one is designed to be launched from the other, for example a web browser launching a media player application when the link to a media file is clicked. If both types of content (web pages and media files in this example) are hosted at the same IDN in a private namespace, but one application converts to A-labels before calling name resolution APIs and the other does not, the user may be able to access a web page, click on the media file causing the media player to launch and attempt to retrieve the media file, which will then fail because the IDN encoding scheme was incorrect. Or even worse, if an attacker is able to register the same name in the other encoding scheme, the user may get the content from the attacker's machine. This is similar to a normal phishing attack, except that the two names represent exactly the same Unicode characters.
次のいずれかがメディアファイルへのリンクがクリックされたときに、メディアプレーヤーアプリケーションを起動する他、例えばWebブラウザから起動するように設計された二つの別々のアプリケーションを検討してください。コンテンツの両方のタイプ（この例では、Webページやメディアファイルが）プライベート名前空間で同じIDNでホストされている、が、1つのアプリケーションが名前解決のAPIを呼び出す前に、ラベルに変換し、他にはないされている場合、ユーザーはできるかもしれませんWebページにアクセスするには、起動し、IDN符号化方式が間違っていたため、その後失敗するメディアファイルを、取得しようとするメディアプレーヤーを引き起こしてメディアファイルをクリックしてください。攻撃者は、他の符号化方式で同じ名前を登録することができる場合には、さらに悪いことに、ユーザーが攻撃者のマシンからコンテンツを取得することがあります。これは、二つの名前がまったく同じUnicode文字を表すことを除いて、通常のフィッシング攻撃に似ています。
On many platforms, the name resolution library will automatically use a variety of protocols to search a variety of namespaces, which might be using UTF-8 or other encodings. In addition, even when only the DNS protocol is used, in many operational environments, a private DNS namespace using UTF-8 is also deployed and is automatically searched by the name resolution library.
多くのプラットフォームでは、名前解決ライブラリは自動的にUTF-8または他のエンコーディングを使用している可能性があり、名前空間の多様性を、検索するためのさまざまなプロトコルを使用します。また、唯一のDNSプロトコルを使用した場合でも、多くの運用環境では、UTF-8を使用してプライベートDNS名前空間も展開されていると自動的に名前解決ライブラリで検索されます。
As explained earlier, using multiple canonical formats, and multiple encodings in different protocols or even in different places in the same namespace creates problems. Because of this, and the fact that both IDNA A-labels and UTF-8 are in use as encoding mechanisms for domain names today, we make the recommendations described below.
複数の標準的なフォーマットを使用して、先に説明し、異なるプロトコルで、あるいは同じ名前空間内の別の場所で複数のエンコーディングは、問題を作成したよう。こののため、およびIDNA A-ラベルとUTF-8の両方が、今日のドメイン名のためのメカニズムをコードとして使用されていることを、私たちは以下の勧告を行うこと。
It is inappropriate for an application that calls a general-purpose name resolution library to convert a name to an A-label unless the application is absolutely certain that, in all environments where the application might be used, only the global DNS that uses IDNA A-labels actually will be used to resolve the name.
これは、アプリケーションが絶対確実でない限り、A-ラベルに名前を変換するための汎用的な名前解決ライブラリを呼び出すアプリケーションには不適切である、というIDNA Aを使用する唯一のグローバルDNSアプリケーションが使用する可能性のあるすべての環境では-labelsは実際に名前を解決するために使用されます。
Instead, conversion to A-label form, or any other special encoding required by a particular name-lookup protocol, should be done only by an entity that knows which protocol will be used (e.g., the DNS resolver, or getaddrinfo() upon deciding to pass the name to DNS), rather than by general applications that call protocol-independent name resolution APIs. (Of course, applications that store strings internally in a different format than that required by those APIs, need to convert strings from their own internal format to the format required by the API.) Similarly, even if an application can know that DNS is to be used, the conversion to A-labels should be done only by an entity that knows which part of the DNS namespace will be used.
代わりに、ラベルの形態、または特定の名前ルックアッププロトコルによって必要とされる任意の他の特別なエンコーディングへの変換は、決定の際にプロトコルが使用される知っているエンティティ（例えば、DNSリゾルバ、又はのgetaddrinfo（）によってのみ行われるべき）DNSに名前を渡すのではなく、プロトコルに依存しない名前解決APIを呼び出す一般的なアプリケーションによる。 （もちろん、それらのAPIが必要とするよりも、別の形式で内部的に文字列を格納するアプリケーションは、APIが必要とする形式に独自の内部フォーマットから文字列を変換する必要があります。）同様に、アプリケーションは、DNSがにあることを知ることができる場合でも、使用され、-ラベルへの変換が使用されるDNS名前空間の一部を知っている実体によってのみ行われるべきです。
That is, a more intelligent DNS resolver would be more liberal in what it would accept from an application and be able to query for both a name in A-label form (e.g., over the Internet) and a UTF-8 name (e.g., over a corporate network with a private namespace) in case the server only recognizes one. However, we might also take into account that the various resolution behaviors discussed earlier could also occur with record updates (e.g., with Dynamic Update [RFC2136]), resulting in some names being registered in a local network's private namespace by applications doing conversion to A-labels, and other names being registered using UTF-8. Hence, a name might have to be queried with both encodings to be sure to succeed without changes to DNS servers.
それは、よりインテリジェントDNSリゾルバは、例えば（これはアプリケーションから受け入れ、ラベル形式の名前（例えば、インターネットを介した）とUTF-8名の両方を照会できるようになるのか、よりリベラルだろうさケース内のプライベート名前空間を持つ企業ネットワーク）を介してサーバには、一つだけを認識します。しかし、我々はまた、前述した様々な解像度の行動はまた、Aへの変換を行うアプリケーションがローカルネットワークのプライベート名前空間に登録されているいくつかの名前で、その結果、レコード更新（例えば、動的更新[RFC2136]で）で発生する可能性があることを考慮に入れるかもしれません-labels、およびUTF-8を使用して登録されている他の名前。したがって、名前がDNSサーバを変更せずに成功することを確認する両方のエンコーディングを使用して照会することが必要になる場合があります。
Similarly, a more intelligent stub resolver would also be more liberal in what it would accept from a response as the value of a record (e.g., PTR) in that it would accept either UTF-8 (U-labels in the case of IDNA) or A-labels and convert them to whatever encoding is used by the application APIs to return strings to applications.
同様に、よりインテリジェントなスタブリゾルバはまた、UTF-8（IDNAの場合におけるU-ラベル）のいずれかを受け入れることで、レコード（例えば、PTR）の値として応答から受け入れるものでより自由であろうまたはA-ラベルやアプリケーションに文字列を返すために、アプリケーションAPIで使用されているものは何でもエンコーディングに変換します。
Indeed the choice of conversion within the resolver libraries is consistent with the quote from Section 6.2 of the original IDNA specification [RFC3490] stating that conversion using the Punycode algorithm (i.e., to A-labels) "might be performed inside these new versions of the resolver libraries".
実際、リゾルバライブラリ内の変換の選択は、元IDNA仕様の6.2節からの引用[RFC3490]（すなわち、-ラベルに）ピュニコードアルゴリズムを使用して、その変換を述べる「のこれらの新しいバージョンの内部で実行されることがありますと一致していますリゾルバライブラリ」。
That said, some application-layer protocols (e.g., EPP Domain Name Mapping [RFC5731]) are defined to use A-labels rather than simply using UTF-8 as recommended by the IETF character sets and languages policy [RFC2277]. In this case, an application may receive a string containing A-labels and want to pass it to name resolution APIs. Again the recommendation that a resolver library be more liberal in what it would accept from an application would mean that such a name would be accepted and re-encoded as needed, rather than requiring the application to do so.
前記いくつかのアプリケーション層プロトコル（例えば、EPPドメイン名マッピング[RFC5731]）は、単純にUTF-8 IETF文字セットと言語ポリシー[RFC2277]によって推奨されるように使用するのではなく、ラベルを使用するように定義されています。この場合、アプリケーションは、ラベルを含む文字列を受け取り、名前解決のAPIに渡すことができます。再度、リゾルバライブラリは、アプリケーションから受け入れるだろう何でより自由なことが推奨は、このような名前が受け入れられ、必要に応じて、むしろそうするようにアプリケーションを必要とするよりも、再エンコードされることを意味します。
It is important that any APIs used by applications to pass names specify what encoding(s) the API uses. For example, GetAddrInfoW() on Windows specifies that it accepts UTF-16 and only UTF-16. In contrast, the original specification of getaddrinfo() [RFC3493] does not, and hence platforms vary in what they use (e.g., Mac OS uses UTF-8 whereas Windows uses Windows code pages).
名前を渡すためにアプリケーションが使用するAPIはAPIを使用してどのようなエンコーディング（複数可）を指定することが重要です。たとえば、Windows上のGetAddrInfoW（）はUTF-16とのみUTF-16を受け入れることを指定します。対照的にのgetaddrinfoの、元の仕様（）[RFC3493]はなく、したがってプラットフォームは、（WindowsはWindowsコードページを使用するのに対し、例えば、MacのOSはUTF-8を使用して）、彼らが使用するものに変わります。
Finally, the question remains about what, if anything, a DNS server should do to handle cases where some existing applications or hosts do IDNA queries using A-labels within the local network using a private namespace, and other existing applications or hosts send UTF-8 queries. It is undesirable to store different records for different encodings of the same name, since this introduces the possibility for inconsistency between them. Instead, a new DNS server serving a private namespace using UTF-8 could potentially treat encoding-conversion in the same way as case-insensitive comparison which a DNS server is already required to do, as long the DNS server has some way to know what the encoding is. Two encodings are, in this sense, two representations of the same name, just as two case-different strings are. However, whereas case comparison of non-ASCII characters is complicated by ambiguities (as explained in the IAB's Review and Recommendations for Internationalized Domain Names [RFC4690]), encoding conversion between A-labels and U-labels is unambiguous.
最後に、質問はどちらかと言えば、DNSサーバは、いくつかの既存のアプリケーションやホストがプライベートな名前空間を使用してローカルネットワーク内で、ラベルを使用してIDNAクエリを行うケースを処理するために何をすべきか、についてのままで、他の既存のアプリケーションやホストがUTF-を送ります8つのクエリ。これは、それらの間の矛盾の可能性を紹介するので、同じ名前の異なるエンコーディングのために別のレコードを格納することは望ましくありません。代わりに、潜在的にDNSサーバがすでに行うために必要な大文字と小文字を区別しない比較と同じ方法でエンコーディング変換を扱うことができUTF-8を使用している限りDNSサーバーをプライベートの名前空間を提供する新しいDNSサーバーは何を知っているいくつかの方法がありますエンコーディングがあります。二つのエンコーディングは2ケース、異なる文字列があると同じように、この意味では、同じ名前の2つの表現です。 （IABのレビューおよび国際化ドメイン名のための推薦[RFC4690]で説明したように）非ASCII文字の場合、比較は曖昧さによって複雑になるのに対し、しかし、-ラベルおよびU-ラベル間符号化変換は明白です。
Having applications convert names to prefixed ACE format (A-labels) before calling name resolution can result in security vulnerabilities. If the name is resolved by protocols or in zones for which records are registered using other encoding schemes, an attacker can claim the A-label version of the same name and hence trick the victim into accessing a different destination. This can be done for any non-ASCII name, even when there is no possible confusion due to case, language, or other issues. Other types of confusion beyond those resulting simply from the choice of encoding scheme are discussed in "Review and Recommendations for IDNs" [RFC4690].
持つアプリケーションは、セキュリティの脆弱性につながることができます名前解決を呼び出す前にプレフィックスACE形式（A-ラベル）に名前を変換します。名前は、プロトコルによって、またはレコードは他の符号化スキームを使用して登録されているゾーンで解決されている場合、攻撃者は、同じ名前のA-ラベルバージョンを主張し、したがって異なる宛先へのアクセスに被害者をだますことができます。これは何の混乱が原因の場合、言語、またはその他の問題のために存在しない場合でも、任意の非ASCII名のために行うことができます。符号化方式の選択から、単純に生じるものを越えた混乱の他のタイプは、「IDNのためのレビューと勧告」[RFC4690]で議論されています。
Designers and users of encodings that represent Unicode strings in terms of ASCII should also consider whether trademark protection or phishing are issues, e.g., if one name would be encoded in a way that would be naturally associated with another organization or product.
ASCIIの面でのUnicode文字列を表す符号化方式の設計者およびユーザーはまた、1名は自然に別の組織または製品に関連するであろう方法で符号化されるかどう商標保護やフィッシング詐欺は、例えば、問題であるかどうかを検討すべきです。
The authors wish to thank Patrik Faltstrom, Martin Duerst, JFC Morfin, Ran Atkinson, S. Moonesamy, Paul Hoffman, and Stephane Bortzmeyer for their careful review and helpful suggestions. It is also interesting to note that none of the first three individuals' names above can be spelled out and written correctly in ASCII text. Furthermore, one of the IAB member's names below (Andrei Robachevsky) cannot be written in the script as it appears on his birth certificate.
著者は、彼らの慎重に検討し、有用な提案のためのパトリックFaltstrom、マーティンDuerst、JFC Morfin、アトキンソン蘭、S. Moonesamy、ポール・ホフマン、そしてステファンBortzmeyerに感謝したいです。上記の最初の3人の名前のどれもが綴られていないと、ASCIIテキストに正しく書き込むことができることに注意することも興味深いものです。それは彼の出生証明書に表示されるさらに、以下IABメンバーの名前（アンドレイRobachevsky）の一つは、スクリプトで記述することはできません。
Bernard Aboba Marcelo Bagnulo Ross Callon Spencer Dawkins Vijay Gill Russ Housley John Klensin Olaf Kolkman Danny McPherson Jon Peterson Andrei Robachevsky Dave Thaler Hannes Tschofenig
バーナードAbobaマルセロBagnuloロスCallonスペンサーダウキンズビジェイ・ギルラスHousleyジョン・クレンシンオラフKolkmanダニー・マクファーソンジョン・ピーターソンアンドレイRobachevskyデーブターラーハンネスTschofenig
[10646] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS)".
[10646]国際標準化のため、「情報技術 - ユニバーサルマルチオクテット符号化文字集合（UCS）」。
ISO/IEC Standard 10646, comprised of ISO/IEC 10646-
1:2000, "Information technology -- Universal
Multiple-Octet Coded Character Set (UCS) -- Part 1:
Architecture and Basic Multilingual Plane", ISO/IEC
10646-2:2001, "Information technology -- Universal
Multiple-Octet Coded Character Set (UCS) -- Part 2:
Supplementary Planes" and ISO/IEC 10646- 1:2000/Amd
1:2002, "Mathematical symbols and other characters".
[Unicode] The Unicode Consortium. The Unicode Standard, Version 5.1.0, defined by: "The Unicode Standard, Version 5.0", Boston, MA, Addison-Wesley, 2007, ISBN 0-321-48091-0, as amended by Unicode 5.1.0 (http://www.unicode.org/versions/Unicode5.1.0/).
[UNICODE]ユニコードコンソーシアム。 Unicodeで定義された標準、バージョン5.1.0、： "Unicode標準、バージョン5.0"、ボストン、MA、アディソン・ウェズリー、2007、ISBN 0-321-48091-0、ユニコード5.1.0で修正された（のhttp： //www.unicode.org/versions/Unicode5.1.0/）。
[DNS-MULTICAST] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in Progress, February 2011.
[DNSマルチキャスト]チェシャー、S.とM. Krochmal、 "マルチキャストDNS"、進歩、2011年2月での作業。
[IDN-PUNYCODE] Costello, A., "Punycode version 0.3.3", Work in Progress, January 2002.
[IDN-PUNYCODE]コステロ、A.、 "ピュニコードバージョン0.3.3"、進歩、2002年1月の作業。
[ISO8859] International Organization for Standardization, "Information technology -- 8-bit single-byte coded graphic character sets".
標準化のために[ISO8859]国際機関、「情報技術 - 8ビットシングルバイトコード化されたグラフィック文字集合」。
ISO/IEC Standard 8859, comprised of ISO/IEC 8859-
1:1998, Part 1: Latin alphabet No. 1 - ISO/IEC 8859-
2:1999, Part 2: Latin alphabet No. 2 - ISO/IEC 8859-
3:1999, Part 3: Latin alphabet No. 3 - ISO/IEC 8859-
4:1998, Part 4: Latin alphabet No. 4 - ISO/IEC 8859-
5:1999, Part 5: Latin/Cyrillic alphabet - ISO/IEC
8859-6:1999, Part 6: Latin/Arabic alphabet - ISO/IEC
8859-7:2003, Part 7: Latin/Greek alphabet - ISO/IEC
8859-8:1999, Part 8: Latin/Hebrew alphabet - ISO/IEC
8859-9:1999, Part 9: Latin alphabet No. 5 - ISO/IEC
8859-10:1998, Part 10: Latin alphabet No. 6 - ISO/
IEC 8859-11:2001, Part 11: Latin/Thai alphabet -
ISO/IEC 8859-13:1998, Part 13: Latin alphabet No. 7
- ISO/IEC 8859-14:1998, Part 14: Latin alphabet No. 8 (Celtic) - ISO/IEC 8859-15:1999, Part 15: Latin alphabet No. 9 - ISO/IEC 8859-16:2001, Part 16: Latin alphabet No. 10.
- ISO / IEC 8859-14：1998、パート14：ラテンアルファベット8号（ケルト） - ISO / IEC 8859-15：1999、パート15：ラテンアルファベット9号 - ISO / IEC 8859-16：2001、パート16：ラテンアルファベットの第10号。
[MJD] Duerst, M., "The Properties and Promizes of UTF-8", 11th International Unicode Conference, San Jose , September 1997, <http://www.ifi.unizh.ch/mml/ mduerst/papers/PDF/IUC11-UTF-8.pdf>.
[MJD] Duerst、M.、 "UTF-8の特性とPromizes"、第11回国際会議のUnicode、サンノゼ、1997年9月、<http://www.ifi.unizh.ch/mml/ mduerst /論文/ PDF /IUC11-UTF-8.pdf>。
[NIS] Sun Microsystems, "System and Network Administration", March 1990.
[NIS]サン・マイクロシステムズ、「システムおよびネットワーク管理」、1990年3月。
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC0821]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1982年8月。
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985.
[RFC0952] Harrenstien、K.、スタール、M.、およびE. Feinler、 "DoDのインターネットホストテーブル仕様"、RFC 952、1985年10月。
[RFC1001] NetBIOS Working Group, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods", STD 19, RFC 1001, March 1987.
[RFC1001] NetBIOSのワーキンググループ、 "TCP / UDPトランスポート上のNetBIOSサービスのためのプロトコル標準：概念と方法"、STD 19、RFC 1001、1987年3月。
[RFC1002] NetBIOS Working Group, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications", STD 19, RFC 1002, March 1987.
[RFC1002] NetBIOSのワーキンググループ、 "TCP / UDPトランスポート上のNetBIOSサービスのためのプロトコル標準：詳細な仕様"、STD 19、RFC 1002、1987年3月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[RFC1468] Murai, J., Crispin, M., and E. van der Poel, "Japanese Character Encoding for Internet Messages", RFC 1468, June 1993.
[RFC1468]村井、J.、クリスピン、M.、およびE.ファンデPoel、 "インターネットメッセージの日本語文字コード"、RFC 1468、1993年6月。
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, October 1993.
[RFC1535] Gavron、E.、 "セキュリティ課題と広く配布しているDNSソフトウェアと提案さ補正"、RFC 1535、1993年10月。
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller, "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, October 1993.
[RFC1536]クマー、A.、ポステル、J.、ニューマン、C.、ダンツィヒ、P.、およびS. Millerの "一般的なDNS実装エラーおよび推奨修正"、RFC 1536、1993年10月。
[RFC2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Crispin, M., and P. Svanberg, "The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996", RFC 2130, April 1997.
[RFC2130]ウイダー、C.、プレストン、C.、シモンセン、K.、Alvestrand、H.、アトキンソン、R.、クリスピン、M.、およびP. Svanberg、「ワークショップセットIAB文字の報告は2月29日開催しました - 1996" 年3月1日、RFC 2130、1997年4月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]いるVixie、P.、トムソン、S.、Rekhter、Y.、およびJ.バウンド、 "ドメインネームシステムにおける動的更新（DNS更新）"、RFC 2136、1997年4月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
"DNS仕様の明確化" [RFC2181]エルツ、R.とR.ブッシュ、RFC 2181、1997年7月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, November 2002.
[RFC3397] Aboba、B.とS.チェシャー、 "動的ホスト構成プロトコル（DHCP）ドメイン検索オプション"、RFC 3397、2002年11月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]コステロ、A.、 "ピュニコード：アプリケーションにおける国際化ドメイン名のUnicodeのブートストリングのエンコード（IDNA）"、RFC 3492、2003年3月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493]ギリガン、R.、トムソン、S.、バウンド、J.、マッキャン、J.、およびW.スティーブンス、 "IPv6の基本的なソケットインタフェース拡張"、RFC 3493、2003年2月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646] Droms、R.、RFC 3646、2003年12月の "IPv6のための動的ホスト構成プロトコル（DHCPv6）のためのDNSの設定オプション"。
[RFC4343] Eastlake, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006.
[RFC4343]イーストレイク、D.、 "ドメインネームシステム（DNS）大文字小文字の明確化"、RFC 4343、2006年1月。
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006.
[RFC4690] Klensin、J.、Faltstrom、P.、カープ、C.、およびIAB、RFC 4690 "国際化ドメイン名（IDNの）のレビューと提言"、2006年9月。
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007.
[RFC4795] Aboba、B.、ターラー、D.、およびL. Esibov、 "リンクローカルマルチキャスト名前解決（LLMNR）"、RFC 4795、2007年1月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952] Klensin、J.とY.コ、 "国際電子メールのための概要とフレームワーク"、RFC 4952、2007年7月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198] Klensin、J.とM. Padlipsky、 "ネットワークインターチェンジのUnicodeフォーマット"、RFC 5198、2008年3月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J.、 "簡易メール転送プロトコル"、RFC 5321、2008年10月。
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, August 2009.
[RFC5731]ホレンベック、S.、 "拡張プロビジョニングプロトコル（EPP）ドメイン名のマッピング"、STD 69、RFC 5731、2009年8月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890] Klensin、J.、 "アプリケーション（IDNA）のための国際化ドメイン名：定義とドキュメントフレームワーク"、RFC 5890、2010年8月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891] Klensin、J.、 "アプリケーション（IDNA）で国際化ドメイン名：プロトコル"、RFC 5891、2010年8月。
[UTF8-DNS] Kwan, S. and J. Gilroy, "Using the UTF-8 Character Set in the Domain Name System", Work in Progress, November 1997.
、進歩、1997年11月の作業「ドメインネームシステムでUTF8文字セットを使用する」[UTF8-DNS]クワン、S.とJ.ギルロイ、。
Authors' Addresses
著者のアドレス
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
デーブターラーマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052 USA
Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
電話：+1 425 703 8835 Eメール：dthaler@microsoft.com
John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140
ジョンはklensina 1770 masasacusetatasa、サント322、ケンブリッジ、02140であります
Phone: +1 617 245 1457 EMail: john+ietf@jck.com
電話：+1 617 245 1457 Eメール：john+ietf@jck.com
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014
スチュアートチェシャーれたApple Inc. 1無限ループクパチーノ、CA 95014
Phone: +1 408 974 3207 EMail: cheshire@apple.com
電話：+1 408 974 3207 Eメール：cheshire@apple.com