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