[要約] RFC 6055は、国際化ドメイン名のエンコーディングに関するIABの考えをまとめたものです。その目的は、国際化ドメイン名のエンコーディングに関する問題を理解し、解決策を提案することです。
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などのさまざまなエンコーディングスキームの使用や、Punycodeアルゴリズムによって生成される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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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つ以上のラベルを含む1つ以上のラベルを含むドメイン名です。プレーン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つのバージョンはほぼ同じです。ただし、以前の文書には、後の改訂が作成されたときに有用であるとは考えられなくなったいくつかの説明が表示されました。ここでは、表示される文書から引用されています。さらに、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]は、各文字がコードポイントと呼ばれる整数値を割り当てられる文字（他の文字を形成するために使用される非間隔マークを含む）のリストです。簡単に言えば、Unicode文字列は、0〜1,114,111（ベース16の10ffff）の範囲の整数コードポイント値の文字列です。これらの整数コードポイントは、ネットワークパケットに送信され、メモリに保存され、ディスクに保存されます。コンピューターシステムでこれらの整数コードポイント値をエンコードする一般的な方法が含まれます。、および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ビットオクテットの変数数でユニコードコードポイントをエンコードするメカニズムです。これらのオクテットは、一連のユニコード文字を表す整数コードポイント値の文字列をエンコードします。UTF-8の権威ある定義は、Unicode標準[Unicode]のセクション3.9および3.10にありますが、UTF-8エンコードの説明はRFC 3629 [RFC3629]にもあります。説明と式は、ISO/IEC 10646-1 [10646]の付属書Dにも記載されています。
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は、Unicode標準[Unicode]のセクション3.9および3.10で詳細に説明されている1つまたは2つの16ビット整数でユニコードコードポイントをエンコードするメカニズムです。UTF-16文字列は、ユニコード文字の文字列を表す一連の整数コードポイント値をエンコードします。
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.
Unicode標準[Unicode]のセクション3.9および3.10で説明されているUTF-32（以前のUCS-4）は、単一の32ビット整数でユニコードコードポイントをエンコードするメカニズムです。したがって、UTF-32文字列は、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.
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 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].
IDNAは、ユニコード用語で、キャラクターが含めることができるキャラクター、それらの間の関係など、ラベルの妥当性を指定します。有効なラベルは、特定のプロトコルまたはコンテキストによって決定される適切なラベルが「U-Label」または「A-Label」フォームのいずれかにあります。U-Labelフォームは、上記のエンコードフォームの1つを使用して、Unicode文字を直接表現しています。このドキュメントでは、多くの場所でUTF-8文字列について説明しています。すべてのUラベルはUTF-8文字列で表すことができますが、すべてのUTF-8文字列が有効なUラベルであるわけではありません（これらの区別の議論については、IDNA定義文書[RFC5890]のセクション2.3.2を参照）。A-Label Formは、Punycodeと呼ばれるアルゴリズムによって生成される圧縮されたASCII互換のエンコード（IDNAおよびその他の用語の「ACE」）を使用します。UラベルとAラベルはお互いの二重です。一方から他方への変換は情報を失いません。変換メカニズムは、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).
したがって、Punycode [RFC3492]は、ASCII互換のエンコードでユニコード文字列をエンコードするメカニズムです。つまり、ASCII文字セットからの文字、数字、およびハイフンのみを使用します。IDNAルール（U-Label）で有効なUnicodeラベルがIDNAの目的でPunycodeでエンコードされている場合、「xn-」が付いています。結果はAラベルと呼ばれます。プレフィックス条約では、他のDNSラベル（IDNA認識アプリケーションでは少なくとも他のDNSラベルはない）がこれらの4つの文字で開始できることを前提としています。その結果、A-Labelエンコーディングが想定される場合、「xn-」で始まるDNSラベルが異なる意味（1つ以上の非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文字列を比較するほど簡単ではありません。まず、ユニコード文字の文字列を表す方法はたくさんあります。第二に、多くの言語とスクリプトで、「同じ」の実際の定義は非常にコンテキスト依存です。このため、2つのユニコード文字列の比較は、Unicode文字列のエンコード方法を考慮する必要があります。ただし、エンコーディングに関係なく、エンコードされたユニコード文字列BYTEをBYTEごとに比較することで、比較を単純に実行することはできません。可能な唯一の時間は、文字列が両方とも標準形式にマッピングされ、同じ方法でエンコードされる場合です。
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 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のみを使用するために定義されていました。アプリケーションの国際化ドメイン名（IDNA）[RFC5890]は、アプリケーションの変更を必要とするメカニズムを定義しますが、APIまたはサーバーを変更しないように、A-Label形式が多くのコンテキストで使用されることを指定します。いくつかの点で、これは既存のAPIを変更していないと見ることができます。これは、APIに出入りする文字列がまだ明らかにASCII文字列であるという意味です。他の方法では、既存のAPIに対する非常に深い変化です。これらの文字列はまだ構文的に有効なASCII文字列であるが、以前と同じことを意味しなくなったからです。1つのソフトウェアまたはライブラリへの単純なASCII文字列のように見えるものは、実際にはユニコード文字列のエンコードであると、別のソフトウェアまたはライブラリ（帯域外情報を適用する）で見ることができます。
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 Resolverライブラリとともに使用すると、IDNAはアプリケーションとResolverライブラリの間に「シム」として挿入されます。名前を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.
まず、オペレーティングシステム（OSS）のリゾルバーAPI（Mac OS、Windows、Linuxなど）はDNS固有ではありません。彼らは通常、間接的な層を提供するため、アプリケーションは、DNS、MDNS [DNS-Multicast]、LLMNR [RFC4795]、NetBios-Over-TCP [RFC1001] [RFC1002]、dns、mdns [dns-multicast]、llmnr [rfc4795]、hostsなどの名前解像度メカニズムとは無関係に機能します。表[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):
元のIDNA仕様[RFC3490]のセクション6.2（以下のToasciiおよびTounicodeは、Punycodeアルゴリズムを使用した変換を指します）：
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.
将来のResolverライブラリの新しいバージョンは、ASCIIよりも他のcharセットのドメイン名を受け入れることができると予想され、アプリケーション開発者はいつかユニコードでドメイン名だけでなく、ローカルスクリプトでも新しいAPIに渡すことができます。オペレーティングシステムのリゾルバーライブラリ。したがって、ToasciiおよびTounicode操作は、これらの新しいバージョンのResolverライブラリ内で実行される可能性があります。
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.
getaddrinfo（）やその前任者のgethostbyname（）などのリゾルバーAPIは、null（0）バイトで終了したバイトの文字列を受け入れることを意味します。ストリングターミネーターとしてヌルオクテットを使用しているため、これはASCII文字列（Aラベルを含む）、さらにはISO-2022-JP [RFC1468]およびUTF-8文字列にも十分です（実装が人為的に排除されない限り）、nullオクテットがこれらのエンコーディングを使用して文字列の中央に現れる可能性があるため、UTF-16またはUTF-32文字列ではありません。日本で歴史的に使用されているいくつかのオペレーティングシステムは、そのようなAPIでISO-2022-JP文字列を受け入れます（そして予想します）。世界中で使用される一部のプラットフォームには、UTF-16などの他のエンコードスキームを受け入れるAPI（例：WindowsのgetAddrinfow（））の新しいバージョンもあります。
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,
o ラベルにESC（0x1B）バイトが含まれている場合、ラベルは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,
o ラベルが「xn-」で始まる場合、それは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は、良好な精度で他の8ビットエンコーディングから検出および区別できます[MJD]。
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.
ISO 8859文字セット[ISO8859]を互いに区別することはより困難または不可能です。なぜなら、それらはまったく同じエンコーディングを持つ最大90文字で異なるため、短い文字列は、キャラクターセットを推定するレシーバー。同様に、一般に、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を指定したり、UTF-8を期待するAPIを明示的に指定するなど、エンコーディングを明示的に指定することはクリーンです。文字列。
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-Multicast]は、UTF-8を使用することを指定しています。実際、文字セットと言語に関するIETFポリシー[RFC2277]（1996年に支援されたワークショップ[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文字セットで構成される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.
さらに、Protocolは、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をA-Labelフォームに変換するアプリケーションは、そのようなプロトコルでPunycode名が直接使用される場合、名前解決障害になります。Aラベルからプロトコル（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を使用して解決され、名前解像度ライブラリによって選択されるプロトコルが選択されていることを知らずに盲目的にA-Labelsに変換すると仮定するアプリケーションに問題があります。さらに、名前解像度ライブラリは、一般的な名前空間を使用するように定義されるため、成功するまで複数のプロトコルを試みることがよくあります。たとえば、ホストファイル[RFC0952]、NetBioS-Over-TCP [RFC1001]、および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)".
この誤解は、もともと「ホスト」ファイル[RFC0952]で使用するための1985年の「インターネットホスト名」（およびネット、ゲートウェイ、ドメイン名）の定義に由来しています。そこでは、文字、数字、ハイフンのみを含むインターネットホスト名が定義されていました。ここでは、大文字と小文字が同一と扱われます。DNS仕様[RFC1034]、セクション3.5「優先名の構文」と題されたセクション3.5は、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年までに、物事はこれらの混乱の領域を明確にするために必要な状態に進みました。「DNS仕様の説明」[RFC2181]、セクション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つの制限のみを配置します。その1つの制限は、ラベルの長さとフルネームに関連しています。1つのラベルの長さは、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にさえ制限がないため、Letter-Digit-Hyphenの使用は言うまでもなく、DNSはUTF-8を許可するためのその後のIETF要件に違反しません[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.
ただし、UTF-16またはUTF-32エンコーディングを使用すると、既存のソフトウェアはすでにASCIIを使用しており、UTF-16およびUTF-32文字列にはALL-を含むことができるため、DNSパケットまたはC言語「Char *」APIでの使用には理想的ではありません。既存のソフトウェアが文字列の終わりとして解釈するゼロオクテット。UTF-16またはUTF-32を使用するには、ASCII、UTF-16、またはUTF-32を使用して文字列がエンコードされたかどうか、そして実際にはUTF-16またはUTF-32がビッグエンディアンであったかどうかを知るための何らかの方法が必要です。またはリトルエンディアンエンコーディング。対照的に、UTF-8は、7ビットASCII文字列も同じ文字を表す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または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以前のIDNAおよびプレフィックスのエースコンベンション）の実践は、UTF-8名を内部DNSサーバーにプライベートネームスペースに配置することです。たとえば、「ドメイン名システムでUTF-8文字セットを使用する」[UTF8-DNS]は1997年に最初に書かれ、Windowsに広く展開されました。DNSでのUTF-8名の使用は、アプリケーションが盲目的にUTF-8文字列を名前解像度APIに渡したという事実によって、Mac OSに同様に実装および展開されました。DNSサーバーとDNSサーバーは、これらのクエリに正しく回答しました。ユーザーの観点からは、ASCIIがケースインスセンシタルに一致しているのに対し、UTF-8はそうではないことを除いて、すべてが特別な新しいコードを作成することなく適切に機能しました（ただし、一部のエンタープライズ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.
以前に暗示されているように、エンコーディングとは無関係に、文字列をいくつかの標準形式にマッピングすることにも問題があります。このような問題については、このドキュメントで詳しく説明していません。これらは、たとえば「ネットワークインターチェンジ用のユニコード形式」[RFC5198]のセクション3である程度議論されており、他の文書で精緻化の機会として残されています。
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ネームスペースで使用するために（2002年[IDN-Punycode] 2003年[RFC3492]）開発が開始されたPunycodeアルゴリズムが含まれていました。これにはいくつかの理由がありました。Public DNS NamespaceのプレフィックスACE戦略が選択されたそのような理由の1つは、ISO 8859-1などの他のエンコーディングもDNSで使用されており、さまざまなエンコーディングが必ずしも互いに区別できるわけではないという事実に関係していました。別の理由は、Punycodeアルゴリズムの使用を含む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.
いずれにせよ、Punycode [RFC3492]の公開とIDNAプロトコルドキュメント[RFC5891]および以前のIDNA仕様[RFC3490]の依存関係は、異なる名前空間（Privateの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.
一般に、ホストは、プライベートネームスペースを使用してゼロ以上のネットワークに接続され、さらにパブリックネームスペースに接続できます。getaddrinfo（）を呼び出す前にu-labelフォームIDNをAラベルに変換するアプリケーションは、名前が実際に他のエンコードのプライベートネームスペースに登録されている場合（例：UTF-8）。ライブラリまたはプロトコルがAラベルからプライベートネームスペース（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実装エラーと提案された修正」のセクション6 [RFC1536]、DHCPドメイン検索オプション[RFC3397]、および「DHCPV6のDNS構成オプション」[RFC3646]のセクション4を参照してください。
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.
「一般的なDNS実装エラーと提案された修正」[RFC1536]のセクション6で述べたように、コミュニティは、複数のバリエーションを試したり、異なるサフィックスを追加したりすることでドメイン名を「検索」するという悪い経験（例：セキュリティ問題[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 {nonascii}。{nonascii} .comのユーザータイプ、およびアプリケーションは、utf-8文字列の形でgetaddrinfo（）またはgethostbyname（）または等価物に渡されます。
1. The DNS resolver passes the (UTF-8) string unmodified to a DNS server.
1. DNS Resolverは、（UTF-8）文字列をDNSサーバーに変更していません。
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.
o {nonascii}。{nonascii} .comのユーザータイプと、アプリケーションは、Windowsのgetaddrinfow（）など、UTF-16などの他のエンコードの文字列を受け入れる名前解像度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-16からUTF-8に変換し、クエリを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 {non ascii}。{non ascii} .comのユーザータイプ。ただし、アプリケーションは最初にa-labelフォームに変換して、名前解像度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（および場合によっては他のプロトコル）に渡すことを決定します。
2. The DNS resolver passes the string unmodified to a DNS server.
2. DNSリゾルバーは、変更されていない文字列をDNSサーバーに渡します。
3. If the name is not found in DNS, the name resolution API decides to try another protocol, say mDNS.
3. 名前がDNSで見つからない場合、Name Resolution 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 {non 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 Resolverは、Suffix検索リストに接尾辞を追加します。これには、ローカルネットワークがプライベートネームスペースを使用する場合、UTF-8文字が含まれる場合があります。
3. Each FQDN in turn will then be sent in a query to a DNS server, until one succeeds.
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 ユーザーは{non ascii}でタイプしますが、アプリケーションは最初にa-labelに変換されるため、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 Stub Resolverは、接尾辞検索リストに接尾辞を追加します。これには、ローカルネットワークがプライベートネームスペースを使用している場合にUTF-8文字を含む場合があります。
3. Each FQDN in turn will then be sent in a query to a DNS server, until one succeeds.
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.
o {nonascii1}。{nonascii2}nonascii3} .comは、ユーザーがアクセスできるUTF-8を使用したプライベートネームスペースです。アプリケーションは、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 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リゾルバーは権威あるサーバーを見つけようとしますが、{nonascii3} .comのUTF-8エンコードのサーバーを見つけることができないため、ルックアップに失敗します。（この作業を行うには、プライベートネームスペースに{nonascii3} .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.
ユーザーが複数のアプリケーションを使用する場合、その一部は名前を渡す前にA-Label変換を行うと、名前の解像度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アプリケーションから離れることを意味します）。
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ブラウザなど、他のアプリケーションが他のアプリケーションを起動するように設計されている2つの別個のアプリケーションを検討します。両方のタイプのコンテンツ（この例のWebページとメディアファイル）がプライベートネームスペースで同じIDNでホストされている場合、1つのアプリケーションが名前解像度APIを呼び出す前にAラベルに変換され、もう1つはユーザーができない場合がありますWebページにアクセスするには、メディアファイルをクリックしてメディアプレーヤーが起動してメディアファイルを取得しようとします。これは、IDNエンコードスキームが正しくなかったために失敗します。さらに悪いことに、攻撃者が他のエンコードスキームで同じ名前を登録できる場合、ユーザーは攻撃者のマシンからコンテンツを取得できます。これは通常のフィッシング攻撃に似ていますが、2つの名前がまったく同じユニコード文字を表していることを除きます。
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.
多くのプラットフォームでは、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-Labelsと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.
アプリケーションが使用される可能性のあるすべての環境で、IDNA aを使用するグローバルDNSのみが絶対に確信していない限り、汎用名解像度ライブラリを呼び出すアプリケーションにはA-Labelに名前を変換するアプリケーションには不適切です。-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.
代わりに、A-Labelフォームへの変換、または特定のName-Lookupプロトコルで必要なその他の特別なエンコードは、どのプロトコルが使用されるかを知っているエンティティ（例：DNS Resolver、またはGetAddrinfo（）が決定すると実行する必要があります。名前をDNSに渡すには）、プロトコルに依存しない名前解像度APIを呼び出す一般的なアプリケーションではなく。（もちろん、文字列がそれらのAPIで必要な形式とは異なる形式で文字列を保存するアプリケーションは、文字列を独自の内部形式からAPIで必要な形式に変換する必要があります。）同様に、アプリケーションがDNSであることを知っていても、使用すると、A-Labelsへの変換は、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リゾルバーは、アプリケーションから受け入れるものでよりリベラルになり、Aラベル形式（たとえば、インターネット上）とUTF-8の名前（例えば、サーバーがそれのみを認識している場合に備えて、プライベートネームスペースを持つコーポレートネットワーク上。ただし、前述のさまざまな解像度の動作がレコードの更新（例：動的更新[RFC2136]）でも発生する可能性があることを考慮に入れることができます。 - ラベル、および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.
同様に、よりインテリジェントなスタブリゾルバーは、RECONSEからレコードの値として受け入れるもの（例えば、PTR）において、よりリベラルであることもあります。または、アプリケーション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".
実際、Resolverライブラリ内の変換の選択は、Punycodeアルゴリズムを使用した変換（つまり、A-Labelsへ）を使用して、これらの新しいバージョンのこれらの新しいバージョン内で実行できることを示す、元のIDNA仕様[RFC3490]のセクション6.2からの引用と一致しています。リゾルバーライブラリ」。
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]）は、IETF文字セットと言語ポリシー[RFC2277]で推奨されるようにUTF-8を単に使用するのではなく、A-Labelを使用するように定義されます。この場合、アプリケーションはAラベルを含む文字列を受信し、解像度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は、APIが使用するエンコードを指定することが重要です。たとえば、WindowsのgetAddrinfow（）は、UTF-16とUTF-16のみを受け入れることを指定します。対照的に、getaddrinfo（）[RFC3493]の元の仕様はそうではないため、プラットフォームは使用するものが異なります（たとえば、Mac OSはUTF-8を使用しますが、WindowsはWindowsコードページを使用します）。
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サーバーが、既存のアプリケーションまたはホストがプライベートネームスペースを使用してローカルネットワーク内のAラベルを使用してIDNAクエリを使用する場合、および他の既存のアプリケーションまたはホストがUTFを送信する場合に何をすべきかについての疑問のままです。8つのクエリ。同じ名前の異なるエンコーディングのために異なるレコードを保存することは望ましくありません。これは、それらの間の矛盾の可能性を導入するためです。代わりに、UTF-8を使用してプライベートネームスペースを提供する新しいDNSサーバーは、DNSサーバーが何を知るために何らかの方法を知るために、DNSサーバーが既に行う必要があるケース非感受性比較と同じ方法で、エンコーディングコンバージョンを潜在的に処理する可能性があります。エンコーディングはです。この意味で、2つのエンコーディングは、2つのケース異なる文字列がそうであるように、同じ名前の2つの表現です。ただし、ASCII以外のキャラクターの症例比較は、あいまいさによって複雑になります（IABのレビューと国際化ドメイン名の推奨事項[RFC4690]の推奨事項で説明されています）、Aラベルと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-Labels）に変換すると、セキュリティの脆弱性が生じる可能性があります。名前がプロトコルまたは他のエンコードスキームを使用してレコードが登録されているゾーンによって解決された場合、攻撃者は同じ名前のAラベルバージョンを請求することができ、したがって、被害者が別の目的地にアクセスするように縮小できます。これは、ケース、言語、またはその他の問題による混乱がない場合でも、ASCII以外の名前で実行できます。単にエンコードスキームの選択に起因するものを超えた他のタイプの混乱については、「IDNSのレビューと推奨事項」[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に関してユニコード文字列を表すエンコーディングの設計者とユーザーは、商標保護またはフィッシングが問題であるかどうかを検討する必要があります。たとえば、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.
著者は、Patrik Faltstrom、Martin Duerst、JFC Morfin、Ran Atkinson、S。Moonesamy、Paul Hoffman、Stephane Bortzmeyerの慎重なレビューと有益な提案に感謝します。また、上記の最初の3人の個人の名前のいずれもASCIIテキストで正しく書かれていないことに注意することも興味深いことです。さらに、以下のIABメンバーの名前の1つ（Andrei 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
バーナード・アボバ・マルセロ・バグヌロ・ロス・ロス・キャロン・スペンサー・ドーキンス・ヴィジャイ・ギル・ラス・ヒューズ・ジョン・クレンシン・オラフ・コルクマン・ダニー・マクファーソンジョン・ピーターソン・アンドレイ・ロバチェフスキー・デイブ・ザラー・ハン・ハンズ・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".
ISO/IEC標準10646、ISO/IEC 10646- 1：2000、「情報技術 - ユニバーサルマルチオクテットコード化された文字セット（UCS） - パート1：アーキテクチャと基本的な多言語平面」、ISO/IEC 10646-2：2001、「情報技術 - ユニバーサルマルチオクテットコード化された文字セット（UCS） - パート2：補足平面」およびISO/IEC 10646- 1：2000/AMD 1：2002、「数学シンボルおよびその他の文字」。
[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コンソーシアム。Unicode標準バージョン5.1.0、「Unicode Standard、バージョン5.0」、マサチューセッツ州ボストン、Addison-Wesley、2007、ISBN 0-321-48091-0、Unicode 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-Multicast] Cheshire、S。およびM. Krochmal、「Multicast DNS」、Work in Progress、2011年2月。
[IDN-PUNYCODE] Costello, A., "Punycode version 0.3.3", Work in Progress, January 2002.
[IDN-Punycode] Costello、A。、「Punycodeバージョン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：ラテンアルファベットNo. 8（ケルティック） - ISO/IEC 8859-15：1999、パート15：ラテンアルファベットNo. 9- ISO/IEC 8859-16：2001、パート16：ラテンアルファベットNo. 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のプロパティとプロモーション」、第11回国際ユニコード会議、サンノゼ、1997年9月、<http://www.ifi.unizh.ch/mml/ mduerst/papers/pdf/iuc11-utf-8.pdf>。
[NIS] Sun Microsystems, "System and Network Administration", March 1990.
[NIS] Sun Microsystems、「システムおよびネットワーク管理」、1990年3月。
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC0821] Postel、J。、「Simple Mail Transfer Protocol」、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.、Stahl、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] Braden、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] Murai、J.、Crispin、M。、およびE. van der 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] Kumar、A.、Postel、J.、Neuman、C.、Danzig、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] Weider、C.、Preston、C.、Simonsen、K.、Alvestrand、H.、Atkinson、R.、Crispin、M。、およびP. Svanberg、」 - 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.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメイン名システムの動的更新（DNSアップデート）」、RFC 2136、1997年4月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、RFC 2181、1997年7月。
[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. Cheshire、「動的ホスト構成プロトコル（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.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（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] Costello、A。、「Punycode：Applications（IDNA）の国際化ドメイン名のUnicodeのブートストリングエンコーディング」、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] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J。、およびW. Stevens、「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。、「IPv6（DHCPV6）の動的ホスト構成プロトコルのDNS構成オプション」、RFC 3646、2003年12月。
[RFC4343] Eastlake, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006.
[RFC4343] EastLake、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.、Karp、C。、およびIAB、「国際化されたドメイン名（IDN）のレビューと推奨事項」、RFC 4690、2006年9月。
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007.
[RFC4795] Aboba、B.、Thaler、D。、およびL. Esibov、「Link-Local Multicast Name Resolution（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. Ko、「国際化された電子メールの概要とフレームワーク」、RFC 4952、2007年7月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198] Klensin、J。およびM. Padlipsky、「ネットワークインターチェンジのユニコード形式」、RFC 5198、2008年3月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, August 2009.
[RFC5731] Hollenbeck、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]クレンシン、J。、「アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク」、RFC 5890、2010年8月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]クレンシン、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.
[UTF8-DNS] Kwan、S。およびJ. Gilroy、「ドメイン名システムでUTF-8文字セットを使用」、1997年11月、進行中の作業。
Authors' Addresses
著者のアドレス
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Dave Thaler Microsoft Corporation One Microsoft Way Redmond、WA 98052 USA
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140
ジョンCクレンシン1770マサチューセッツアベニュー、STE 322ケンブリッジ、マサチューセッツ州02140
Phone: +1 617 245 1457
EMail: john+ietf@jck.com
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino、CA 95014
Phone: +1 408 974 3207
EMail: cheshire@apple.com