Network Working Group J. Klensin
Request for Comments: 4185 October 2005
Category: Informational
National and Local Characters for DNS Top Level Domain (TLD) Names
DNSトップレベルドメイン（TLD）名の国家と地域の文字
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 [RFC3932] for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のために、このRFCのフィットネスの知識を否認し、公開する決定がIETF仕事との競合のためのIESGレビューとは別にIETFレビューに基づいていないことを指摘しています。 RFC Editorはその裁量でこの文書を公開することを選択しました。詳細については、RFC 3932 [RFC3932]を参照してください。
Abstract
抽象
In the context of work on internationalizing the Domain Name System (DNS), there have been extensive discussions about "multilingual" or "internationalized" top level domain names (TLDs), especially for countries whose predominant language is not written in a Roman-based script. This document reviews some of the motivations for such domains, several suggestions that have been made to provide needed functionality, and the constraints that the DNS imposes. It then suggests an alternative, local translation, that may solve a superset of the problem while avoiding protocol changes, serious deployment delays, and other difficulties. The suggestion utilizes a localization technique in applications to permit any TLD to be accessed using the vocabulary and characters of any language. It is not restricted to language- or country-specific "multilingual" TLDs in the language(s) and script(s) of that country.
ドメインネームシステム（DNS）の国際化に関する作業との関連では、特にその主要な言語ローマベースで書かれていない国のために、「多言語」または「国際化」トップレベルドメイン名（TLDの）についての広範な議論がなされています脚本。この文書では、このようなドメイン、必要な機能を提供する試みがなされてきたいくつかの提案、DNSが課す制約のための動機のいくつかをレビュー。これは、プロトコルの変更、深刻な展開の遅れ、および他の困難を回避しながら、問題のスーパーセットを解決することの代替、地元の翻訳を、示唆しています。提案は、語彙や任意の言語の文字を使用してアクセスするための任意のTLDを許可するアプリケーションでローカライズ技術を利用しています。その国の言語（複数可）およびスクリプト（複数可）に、言語や国固有の「多言語」のTLDに限定されるものではありません。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Background on the "Multilingual Name" Problem ..............3
1.2.1. Approaches to the Requirement .......................3
1.2.2. Writing the Name of One's Country in its Own
Characters ..........................................4
1.2.3. Countries with Multiple Languages and
Countries with Multiple .............................5
1.2.4. Availability of Non-ASCII Characters in Programs ....5
1.3. Domain Name System Constraints .............................6
1.3.1. Administrative Hierarchy ............................6
1.3.2. Aliases .............................................6
1.4. Internationalization and Localization ......................7
2. Client-Side Solutions ...........................................7
2.1. IDNA and the Client ........................................8
2.2. Local Translation Tables for TLD Names .....................8
3. Advantages and Disadvantages of Local Translation ...............9
3.1. Every TLD Appears in the Local Language and Character Set ..9
3.2. Unification of Country Code Domains .......................10
3.3. User Understanding of Local and Global References .........11
3.4. Limits on Expansion of the Number of TLDs .................11
3.5. Standardization of the Translations .......................12
3.6. Implications for Future New Domain Names ..................13
3.7. Mapping for TLDs, Not Domain Names or Keywords ............13
4. Information Interchange, IDNs, Comparisons, and Translations ...13
5. Internationalization Considerations ............................15
6. Security Considerations ........................................15
7. Acknowledgements ...............................................16
8. Informative References .........................................17
This document assumes the conventional terminology used to discuss the domain name system (DNS) and its hierarchical arrangements. Terms such as "top level domain" (or just "TLD"), "subdomain", "subtree", and "zone file" are used without further explanation. In addition, the term "ccTLD" is used to denote a "country code top level domain" and "gTLD" is used to denote a "generic top level domain" as described in [RFC1591] and in common usage.
このドキュメントでは、ドメインネームシステム（DNS）とその階層的な取り決めを議論するために使用される従来の用語を前提としています。こうした「トップレベルドメイン」（または単に「TLD」）、「サブドメイン」、「サブツリー」、および「ゾーンファイル」などの用語は、さらなる説明なしで使用されています。加えて、用語「のccTLD」は、[RFC1591]に記載されているように、「一般的なトップレベルドメイン」と一般的な用法でを表すために使用される「国コードトップレベルドメイン」と「のgTLD」を示すために使用されます。
People who share a language usually prefer to communicate in it, using whatever characters are normally used to write that language, rather than in some "foreign" one. There have been standards for using mutually-agreed characters and languages in electronic mail message bodies and selected headers since the introduction of MIME in 1992 [MIME] and the Web has permitted multilingual text since its inception, also using MIME. Actual use of non-Roman-character content came even earlier, using private conventions. However, domain names are exposed to users in email addresses and URLs. Corresponding arrangements, typically also exposing domain names, are made for other application protocols. The combination of exposed domain names with internationalization requirements led rapidly to demands to permit domain names in applications that used characters other than those of the very restrictive, ASCII-subset, "hostname" (or "letter-digit-hyphen" ("LDH")) conventions recommended in the DNS specifications [RFC1035]. The effort to do this soon became known as "multilingual domain names". That was actually a misnomer, since the DNS deals only with characters and identifier strings, and not, except by accident or local registration conventions, with what people usually think of as "names". There has also been little interest in what would actually be a "multilingual name", i.e., a name that contains components from more than one language. Instead, interest has focused on the use, in the context of the DNS, of strings that conform to specific individual languages.
言語を共有する人々は、通常、一般にはむしろ、いくつかの「外来」1に比べて、その言語を記述するために使用されているものは何でも文字使用して、それに通信することを好みます。そこ1992年にMIMEの導入以来、電子メールメッセージの本文と選択ヘッダに相互に合意された文字や言語を使用するための標準化[MIME]となっているとWebもMIMEを使用して、創業以来、多言語テキストを許可しています。ローマ字以外の文字コンテンツの実際の使用は、専用の規則を使用して、以前にも来ました。ただし、ドメイン名、電子メールアドレスやURLでユーザーに公開されています。アレンジを対応する、一般的にも、ドメイン名を露出し、他のアプリケーションプロトコルのために作られています。国際化の要件にさらさドメイン名の組み合わせは非常に制限、ASCII-サブセット以外の文字を使用するアプリケーションでのドメイン名を許可する需要に迅速に導かれ、「ホスト名」（または「レター桁ハイフン」（「LDH」 DNSの仕様で推奨））規則[RFC1035]。これを実行するための努力はすぐに「多言語ドメイン名」として知られるようになりました。それは、人々は通常、「名前」として考えるものとの事故やローカル登録の規則、による場合を除いて、だけでなく、文字や識別文字列を持つDNSディール以来、実際には誤称だった、と。また、実際に「多言語名」、すなわち、複数の言語からのコンポーネントが含まれている名前であるものにはほとんど関心がありました。代わりに、関心は特定の個人の言語に準拠した文字列を、DNSの文脈では、使用に焦点を当てています。
When the requirement was seen, not as "modifying the DNS", but as "providing users with access to the DNS from a variety of languages and character sets", three sets of proposals emerged in the IETF and elsewhere. They were:
要件が見られた場合には、ない「DNSの変更」としてではなくとして「言語と文字セットの様々なからDNSへのアクセスをユーザーに提供する」、提案の3セットは、他の場所IETFとして現れました。彼らはいた：
1. Perform processing in client software that recodes a user-visible string into an ASCII-compatible form that can safely be passed through the DNS protocols and stored in the DNS. This is the approach used, for example, in the IETF's "IDNA" protocol [RFC3490].
1.安全にDNSプロトコルを通過し、DNSに格納することができるASCII互換形式にユーザーに表示する文字列を再符号化クライアントソフトウェアで処理を実行します。これは、IETFの「IDNA」プロトコル[RFC3490]は、例えば、使用されるアプローチです。
2. Modify the DNS to be more hospitable to non-ASCII names and strings. There have been a variety of proposals to do this, using several different techniques. Some of these have been implemented on a proprietary basis by various vendors. None of them have gained acceptance in the IETF community, primarily because they would take a long time to deploy, would leave many problems unsolved, and have been shown to cause problems with deployed approaches that had not yet been upgraded.
2.非ASCII名と文字列に、より親切であることをDNSを変更します。いくつかの異なる技術を使用して、これを行うための種々の提案がなされています。これらのいくつかは、さまざまなベンダーが独自の基準で実施されています。それらのどれもが、彼らが展開するのに長い時間がかかるだろう主な理由は、IETFコミュニティに受け入れられていない、未解決の多くの問題を残して、まだアップグレードされていなかった展開のアプローチで問題を引き起こすことが示されています。
3. Move the problem out of the DNS entirely, relying instead on a "directory" or "presentation" layer to handle internationalization. The rationale for this approach is discussed in [RFC3467].
3.国際化を処理するために、「ディレクトリ」または「プレゼンテーション」レイヤーの上に代わりに頼って、完全にDNSのうち、問題を移動します。このアプローチの理論的根拠は、[RFC3467]に記載されています。
This document proposes a fourth approach, applicable to the top level domains (TLDs) only (see Section 1.3.1 for a discussion of the special issues that make TLDs both problematic and a special opportunity). That approach involves having the user interface of applications map non-ASCII names for TLDs to existing TLDs and could be used as an alternate or supplement to the strategies summarized above.
この文書では、トップレベルドメイン（TLDの）のみ（TLDの問題と特別な機会の両方を作る特殊な問題の議論については、セクション1.3.1を参照）に適用される第四の方法を、提案しています。そのアプローチは、アプリケーションのユーザーインターフェースは、既存のTLDにTLDのための非ASCII名をマップし、上記要約戦略の代替または補足として使用することができる有することを含みます。
An early focus of the "multilingual domain name" efforts was expressed in statements such as "users in my country, in which ASCII is rarely used, should be able to write an entire domain name in their own character set". In particular, since all top-level domain names, at present, follow the LDH rules, the modified naming rules discussed in [RFC1123], and the coding conventions specified in [RFC1591], all fully-qualified DNS names were effectively required to contain at least one ASCII label (the TLD name). Some advocates for internationalized names have considered the presence of any ASCII labels inappropriate. One should, instead, be able to write the name of the ccTLD for China in Chinese, the name of the ccTLD for Saudi Arabia in Arabic, the name for Spain in Spanish, and so on.
「多言語ドメイン名」の取り組みの初期の焦点は、このような「めったに使用され、独自の文字セットでドメイン名全体を書くことができるはずであるASCIIに私の国のユーザー、」などのステートメントで発現させました。具体的には、すべてのトップレベルドメイン名から、現在では、LDHのルールに従う、[RFC1123]で説明した修飾命名規則、および[RFC1591]で指定されたコーディング規則は、すべての完全修飾DNS名が効果的に含有することが必要でした少なくとも一つのASCIIラベル（TLD名）。国際化の名前のいくつかの支持者は、不適切な任意のASCIIラベルの存在と考えられてきました。一つは、代わりに、ように、スペイン語でスペインの名前を中国語で中国のためのccTLD、アラビア語でサウジアラビアのためのccTLDの名前の名前を書く、とすることができるはずです。
That much could be accomplished, given updated applications, by using a new TLD name with IDNA encoding. Of course, adding such a TLD would raise new questions: what to do about gTLDs, how to handle countries with several official languages (perhaps even using different scripts), how should name strings be chosen, and whether there should be an attempt to coordinate the contents of the local-language TLD zone and the traditional ISO 3166-coded one. A few of these issues are addressed below. But, if one examines (or even thinks about) user behavior and preferences, it is almost as important that one be able to write the name of the ccTLD for China in Arabic and that of Saudi Arabia in Chinese: true internationalization implies that, at least to the extent to which ambiguity and conflicts can be avoided, people should be able to use the languages and character sets they prefer. For the same reasons that one would like to have all-Chinese domain names available in China, it is important to have the capability to have an apparent Chinese-language TLD for a domain whose second level and beyond are Chinese characters, even when the TLD itself serves predominantly non-Chinese-speaking registrants and users.
それくらいIDNAエンコードで新しいTLD名を使用して、更新されたアプリケーション与え、達成することができます。もちろん、そのようなTLDを追加すると、新たな問題を提起します：のgTLDについて何をすべきか、いくつかの公式言語と国をどのように処理するか（おそらく別のスクリプトを使用して）、選択された文字列に名前を付けるべきか、座標しようとする試みがあるべきかローカル言語TLDゾーンと伝統的なISO 3166コード化された1の内容。これらの問題のいくつかを以下に扱われます。しかし、1が調べ（またはさらに約考えて）ユーザーの行動や好みならば、1つが、中国ではアラビア語で、中国のためのccTLDの名前とサウジアラビアのことを書くことができることが、ほぼ同様に重要である：真の国際化で、ということを意味します少なくとも曖昧さや競合を避けることができる程度に、人々は、彼らが好む言語と文字セットを使用することができるはずです。 1は中国で利用可能なすべての中国のドメイン名を持っていると思い、同じ理由から、第二レベル以降漢字があるドメインの見かけの中国語TLDを持っている能力を持つことが重要である、場合でも、TLDそれ自体は、主に非中国圏の登録者とユーザーを提供しています。
1.2.3. Countries with Multiple Languages and Countries with Multiple Names
1.2.3. 複数の名前を持つ複数の言語や国と国
From a user interface standpoint, writing ccTLD names in local characters is a problem. As discussed below in Section 1.3.2, the DNS itself does not easily permit a domain to be referred to by more than one name (or spelling or translation of a name). Countries with more than one official language would require that the country name be represented in each of those languages. And, just as it is important that a user in China be able to represent the name of the Chinese ccTLD in Chinese characters, she should be able to access a Chinese-language site in France using Chinese characters. That would require that she be able to write the name of the French ccTLD in Chinese characters rather than in a form based on a Roman character set.
ユーザーインターフェースの観点からは、地元の文字でのccTLD名を書くことは問題です。 1.3.2項で後述するように、DNS自体は簡単に複数の名前（または名前のスペルまたは翻訳）によって参照されるドメインを許可していません。複数の公用語を持つ国は、国の名はこれらの言語のそれぞれで表現されることを必要とします。そして、それは中国のユーザーが漢字で中国のccTLDの名前を表現できることが重要であるのと同様に、彼女は漢字を使用してフランスで中国語のサイトにアクセスすることができるはずです。それは彼女が漢字ではなくローマ字セットに基づくフォームでフランス語のccTLDの名前を書くことができることを必要とするであろう。
Over the years, computer users have gotten used to the fact that not every computer has a full set of characters available to every program. An extreme example is an Arabic speaker using a public kiosk computer in an airport in the United States: there is only a small chance that the web browser there will be able to input and render Arabic correctly. This has a direct effect on the multilingual TLD problem in that it is not possible to simply change a name of the ccTLDs in the DNS to be one of a given country's non-ASCII names without possibly preventing people from entering those names throughout the world.
長年にわたり、コンピュータユーザーはいないすべてのコンピュータがすべてのプログラムで使用可能な文字の完全なセットを持っているという事実のために使用頂いております。極端な例では、米国の空港で公共のキオスクコンピュータを使用してアラビア語スピーカーです：Webブラウザが入力することができ、正しくアラビア語をレンダリングするだけの小さなチャンスがあります。単に、おそらく世界中でそれらの名前を入力することから人々を妨げることなく、ある国の非ASCII名のいずれかであることをDNSでのccTLDの名前を変更することはできませんという点でこれは、多言語TLDの問題に直接影響を及ぼします。
The domain name system is firmly rooted in the idea of an "administrative hierarchy", with the entity responsible for a given node of the hierarchy responsible for policies applicable to its subhierarchies (Cf. [RFC1034], [RFC1035], and [RFC1591]). The model works quite well for the domain and subdomains of a particular enterprise. In an enterprise situation, the hierarchy can be organized to match the organizational structure; there are established ways to set policies; and there are, at least presumably, shared assumptions about overall goals and objectives among all registrants in the domain. It is more problematic when a domain is shared by unrelated entities that lack common policy assumptions because it is difficult to reach agreement on rules that should apply to all of the entities and subdomains of such a domain. In general, the unrelated entities situation always prevails for the labels registered in a TLD (second-level names). Exceptions occur in those TLDs for which the second level is structural (e.g., the .CO, .AC, .GOV conventions in many ccTLDs or in the historical geographical organization of .US [RFC1480]). In those cases, it exists for the labels within that structural level.
ドメインネームシステムはしっかりとそのsubhierarchiesに適用されるポリシーを担当する階層の特定のノードを担当するエンティティ（参照：[RFC1034]、[RFC1035]、および[RFC1591]で、「行政階層」の考え方に根ざしています）。モデルは、特定の企業のドメインやサブドメインのために非常に適しています。企業の状況では、階層は、組織構造に一致するように整理することができます。そこにポリシーを設定する方法を確立しています。少なくとも、おそらく、ドメイン内のすべての登録者の間で、全体的な目標と目的についての仮定を共有し、そこにあります。ドメインは、そのようなドメインのエンティティとサブドメインのすべてに適用すべきルールについて合意に達することは困難であるため、一般的な政策の前提が欠けている無関係なエンティティによって共有されているとき、それはより多くの問題があります。一般的に、無関係なエンティティの状況は常にTLD（第2レベルの名前）に登録されたラベルに優先されます。例外が第2レベルで構造されているもののTLDで起こる（例えば、多くのccTLDまたは.USの歴史的、地理的、組織内.CO、.AC、.GOV規則[RFC1480]）。これらの場合、その構造レベル内のラベルのために存在します。
TLDs may, but need not, have consistent registration policies for those second (or third) level names. Countries (or ccTLD administrators) have often adopted rules about what entities may register in their ccTLDs, and what forms the names may take. RFC 1591 outlined registration norms for most of the then-extant gTLDs; however, those norms have been largely ignored in recent years. Some recent "sponsored" and purpose-specific domains are based on quite specific rules about appropriate registrations. Homogeneous registration rules for the root are, by contrast, impossible: almost by definition, the subdomains registered in the root (TLDs) are diverse, and no single policy about types and formats of names applying to all root subdomains is feasible.
TLDはできるが、それらの第二（又は第三の）レベル名の一貫した登録ポリシーを持って、必要はありません。国（またはccTLDの管理者）は、多くの場合、エンティティが自分のccTLDで登録することができ、そして名前がかかる場合がありますものを形成するかについてのルールを採用しています。 RFC 1591は、当時現存のgTLDのほとんどを登録規範を概説しました。しかし、これらの規範は、主に、近年では無視されています。いくつかの「後援」最近の目的、特定のドメインは、適切な登録についてかなり具体的なルールに基づいています。ルートの均質登録規則は、対照的に、不可能です：ほとんど定義によって、ルート（トップレベルドメイン）に登録されたサブドメインは多様であり、そしてすべてのルートのサブドメインに適用する名前の種類および形式に関する単一のポリシーが実現可能ではありません。
In an environment different from the DNS, a rational way to permit assigning local-language names to a country code (or other) domain would be to set up an alias for the name, or to use some sort of "see instead" reference. But the DNS does not have facilities for either. Instead, it supports a "CNAME" record, whose label can refer only to a particular label and not to a subtree. For example, if A.B.C is a fully-qualified name, then a CNAME reference in B.C from X to A would make X.B.C appear to have the same values as A.B.C. However, a CNAME reference from Y to C in the root would not make A.B.Y referenceable (or even defined) at all. A second record type, DNAME [RFC2672], can provide an alias for a portion of the tree. But many believe that it is problematic technically. At a minimum, it can cause synchronization issues when references across zones occur, and its use has been discouraged within the IETF, except as a means of enabling a transition from one domain to another. Even if the design of yet another alias-type record type were contemplated, DNS technical constraints of query-response integrity and DNSSec zone signing (cf. [RFC4033], [RFC4034], and [RFC4035]) make it extremely unlikely that one could be defined that would meet the desired requirements for "see instead" or true synonym references.
DNSとは別の環境では、国コード（または他の）ドメインにローカル言語名を割り当て可能とする合理的な方法は、名前のエイリアスを設定するために、または「代わりに見る」参照のいくつかの並べ替えを使用することです。しかし、DNSは、どちらかのための設備を持っていません。代わりに、それは、そのラベルのサブツリーに特定のラベルのみを参照することができず、「CNAME」レコードをサポートしています。 A.B.Cは完全修飾名である場合、例えば、次にXからAへB.CにおけるCNAME参照はX.B.CがA.B.C.と同じ値を持つように見えるようになりますしかし、ルートにCまでYからCNAME基準は全くA.B.Yが参照可能（あるいは定義される）ことはないだろう。第二のレコードタイプ、DNAME [RFC2672]は、木の部分のエイリアスを提供することができます。しかし、多くは、それが技術的に問題があると考えています。ゾーン間の参照が発生したときに最低でも、それは同期の問題を引き起こす可能性があり、その使用は、別のドメインからの移行を可能にする手段として以外に、IETF内落胆されています。さらに別のエイリアス型レコード型の設計が考慮された場合でも、クエリ応答の整合性とDNSSECゾーン署名（参照：[RFC4033]、[RFC4034]、および[RFC4035]）、それは極めてまれ1ができたことを確認の技術的な制約をDNS 「代わりに見る」または真の同義語の参照のために所望の要件を満たすだろうと定義されます。
It has often been observed that, while many people talk about "internationalization", they often really mean, and want, "localization". "Internationalization", in this context, suggests making something globally accessible while incorporating a broad-range "universal" character set and conventions appropriate to all languages and cultures. "Localization", by contrast, involves having things work well in a particular locality or for a broad range of localities, although aspects of the style of operation might differ for each locality. Anything that actually involves the DNS must be global, and hence internationalized, since the DNS cannot meaningfully support different responses or query and matching models based, e.g., on the location of the user making a query. While the DNS cannot support localization internally, many of the features discussed earlier in this section are much more easily thought about in local terms -- whether localized to a geographical area, users of a language, or using some other criteria -- than in global ones.
多くの場合、多くの人が、「国際化」について話している間、彼らはしばしば、本当に意味、そして、「ローカリゼーション」をしたい、ということが観察されています。 「国際化」は、この文脈では、すべての言語や文化に適した広い範囲の「ユニバーサル」の文字セットと規則を取り入れながら、グローバルにアクセス可能なものを作る示唆しています。 「ローカライゼーション」、コントラストによって、操作のスタイルの側面が各地域で異なるかもしれませんが、物事は、特定の地域や地方の広い範囲のためにうまく機能したが含まれます。 DNSは有意義クエリを作成するユーザの位置に、例えば、ベース異なる応答またはクエリとマッチングモデルをサポートすることができないので、実際にDNSを含むものは、グローバル、ひいては国際なければなりません。 DNSは、内部的にローカライズをサポートすることはできませんが、このセクションで前述した機能の多くは、はるかに簡単にローカルで約考えている - 地理的領域に局在するかどうか、言語、または他のいくつかの基準を使用してのユーザー - グローバルでよりもの。
Traditionally, the IETF avoided becoming involved in standardization for actions that take place strictly on individual hosts on the network, instead confining itself to behavior that is observable "on the wire", i.e., in protocols between network hosts. Exceptions to this general principle have been made when different clients were required to utilize data or interpret values in compatible ways to preserve interoperability: the standards for email and web body formats, and IDNA itself, are examples of these exceptions. Regardless of what is required to be standardized, it is almost never required, and often unwise, that a user interface present "on the wire" formats to the user, at least by default (debugging options that show the wire formats are common and often quite useful). However, in most cases when the presentation format and the wire format differ, the client program must take precautions to ensure that the wire format can be reconstructed from user input, or to keep the wire format, while hidden, bound to the presentation mechanism so that it can be reconstructed. While it is rarely a goal in itself, it is often necessary that the user be at least vaguely aware that the wire ("real") format is different from the presentation one and that the wire format be available for debugging.
伝統的に、IETFは、代わりにネットワークホスト間のプロトコルで、すなわち、「ワイヤー上」観測可能である行動に自分自身を閉じ込める、ネットワーク上の個々のホスト上で厳密に行われたアクションのための標準化に巻き込ま避けます。電子メールやウェブボディフォーマットの規格は、およびIDNA自体は、これらの例外の例です：別のクライアントがデータを利用または相互運用性を維持するために互換性のある方法で値を解釈するために必要とされたときに、この一般原則の例外が行われています。関係なく、標準化されたことが要求されるものの、それはほとんど必要とされることはありません、としばしば賢明少なくともデフォルトでは、ユーザへのフォーマット、（ワイヤフォーマットを示し、多くの場合、一般的であり、デバッグオプション「ワイヤ上の」現在のユーザインタフェース非常に便利）。しかし、プレゼンテーション形式とワイヤフォーマットが異なる場合、ほとんどの場合、クライアントプログラムは、ワイヤフォーマットは、ユーザー入力から再構築することができ、あるいは隠されながら、ワイヤフォーマットを維持するために、そのプレゼンテーション機構に結合することを確実にするために予防策を取る必要がありますそれを再構築することができます。それは自分自身でめったにゴールではありませんが、ユーザが、ワイヤ（「リアル」）形式は、プレゼンテーションのものとは異なるとワイヤ形式は、デバッグのために利用可能であることであること。少なくとも漠然と認識していることがしばしば必要です
In fact, the DNS itself is an excellent example of the difference between the wire format and the user presentation format. Most Internet users do not realize that the wire format for DNS queries and responses does not include the "." character. Instead, each label is represented by a length in bytes of the label, followed by the label itself.
実際には、DNS自体は、ワイヤフォーマットおよびユーザ・プレゼンテーション・フォーマットとの間の差の優れた例です。ほとんどのインターネットユーザーは、DNSクエリと応答のためのワイヤフォーマットが含まれていないことを認識していません「」キャラクター。代わりに、各ラベルは、ラベル自体に続くラベルの長さ（バイト数）、で表されます。
As mentioned above, IDNA itself is entirely a client-side protocol. It works by performing some mappings and then encoding labels to be placed into the DNS in a special format called "punycode" [RFC3492]. When labels in that format are encountered, they are transformed, by the client, back into internationalized (normally Unicode [ISO10646]) characters. In the context of this document, the important observation about IDNA is that any application program that supports it is already doing considerable transformation work in the client; it is not simply presenting the "on the wire" formats to the user. It is also the case that, if an application implementation makes different mappings than those called for by IDNA, it is likely to be detected only when, and if, users complain about unexpected behavior. As long as the punycode strings sent to it are valid, the server cannot tell what mappings were applied to develop those strings.
上述したように、IDNA自体は完全にクライアント側のプロトコルです。これは、いくつかのマッピングを行った後、「Punycodeで」[RFC3492]と呼ばれる特殊な形式のDNSに配置されるようにラベルを符号化することによって動作します。その形式のラベルに遭遇した場合（通常のUnicode [ISO10646]）文字を国際化に、彼らは戻って、クライアントによって、変換されます。この文書の文脈では、IDNAに関する重要な観察は、それがすでにクライアントにはかなりの変換作業を行っているサポートする任意のアプリケーションプログラムです。それは単にユーザーに「ワイヤ上の」形式を提示されていません。また、アプリケーションの実装がIDNAによって要求されるものとは異なるマッピングを行う場合、ケースで、ユーザーが予期しない動作に文句を言うときにのみ、および場合に検出される可能性があります。限り、それに送られたPunycodeで文字列が有効であるとして、サーバーは、これらの文字列を開発するために適用されたものをマッピング伝えることはできません。
We suggest that, in addition to maintaining the code and tables required to support IDNA, authors of application programs may want to maintain a table that contains a list of TLDs and locally-desirable names for each one. For ccTLDs, these might be the names (or locally-standard abbreviations) by which the relevant countries are known locally (whether in ASCII characters or others). With some care on the part of the application designer (e.g., to ensure that local forms do not conflict with the actual TLD names), a particular TLD name input from the user could be either in local or standard form without special tagging or problems. When DNS names are received by these client programs, the TLD labels would be mapped to local form before IDNA is applied to the rest of the name; when names are received from users, local TLD names would be mapped to the global ones before applying IDNA or being used in other DNS processing.
私たちはIDNAをサポートするために必要なコードとテーブルを維持することに加えて、アプリケーション・プログラムの作者は、TLDをし、それぞれについて、ローカルで望ましい名前のリストを含むテーブルを維持したいことがあり、ことを示唆しています。 ccTLDのために、これらは、関係国が（かどうかASCII文字等で）ローカルに知られていることにより、名前（またはローカル標準の略語）かもしれません。アプリケーションの設計者（例えば、ローカルフォームは、実際のTLD名と競合しないことを確実にするため）の一部にいくつかの注意をもって、利用者からの特定のTLD名の入力は、特殊なタグ付けまたは問題なくローカルまたは標準形式である可能性があります。 DNS名がこれらのクライアントプログラムによって受信されると、TLDラベルはIDNAは、名前の残りの部分に適用される前に、ローカルフォームにマッピングされます。名前は、ユーザーから受信したとき、地元のTLD名はIDNAを適用する前に、グローバルなものにマッピングされるか、他のDNS処理に使用されています。
The notion of a top-level domain whose name matches, e.g., the name that is used for a country in that country or the name of a language in that language as, as mentioned above, is immediately appealing. But most of the reasons for it argue equally strongly for other TLDs being accessible from that language. A user in Korea who can access the national ccTLD in the Korean language and character set has every reason to expect that both generic top level domains and domains associated with other countries would be similarly accessible, especially if the second-level domains bear Korean names. A user native to Spain or Portugal, or in Latin America, would presumably have similar expectations, but would expect to use Spanish or Portuguese names, not Korean ones.
名前例えば、一致するトップレベルドメインは、上述したように、その国の国として、またはその言語における言語の名前のために使用されている名前の概念は、すぐに魅力的です。しかし、その理由のほとんどは、その言語からアクセス可能な他のTLDのために均等に強く主張しています。韓国語の言語と文字セットで全国のccTLDにアクセスすることができ、韓国のユーザーは、他の国に関連付けられている両方のジェネリックトップレベルドメインとドメインがセカンドレベルドメインは韓国語の名前を負担する場合は特に、同様にアクセスできるようになることを期待するためにあらゆる理由を持っています。スペインやポルトガルへ、またはラテンアメリカのユーザーのネイティブは、おそらく同様の期待を持っているだろうが、スペイン語、ポルトガル語の名前ではなく、韓国のものを使用することを期待します。
That level of local optimization is not realistic -- some would argue not possible -- with the DNS since it would ultimately require that every top level domain be replicated for each of the world's languages. That replication process would involve not just the top level domain itself; in principle, all of its subtrees would need to be completely replicated as well. Perhaps in practice, not all subtrees would require replication, but only those for which a language variation or translation was significant. But, while that restriction would change the scale of the problem, it would not alter its basic nature. The administrative hierarchy characteristics of the DNS (see Section 1.3.1) turn the replication process into an administrative nightmare: every administrator of a second-level domain in the world would be forced to maintain dozens, probably hundreds, of similar zone files for the replicates of the domain. Even if only the zones relevant to a particular country or language were replicated, the administrative and tracking problems to bind these to the appropriate top-level domain and keep all of the replicas synchronized would be extremely difficult at best. And many administrators of third- and fourth-level domains, and beyond, would be faced with similar problems.
局所的な最適化のレベルは現実的ではない - いくつかのことはできません主張 - DNSと、それは最終的に、すべてのトップレベルドメインは、世界の言語ごとに複製されることを必要とするからです。その複製プロセスだけではなく、トップレベルドメイン自体を伴うだろう。原則的には、そのサブツリーのすべてが完全に同様に複製される必要があろう。おそらく、実際には、いないすべてのサブツリーは、複製を必要とするが、言語の変化や翻訳は有意であったもののみれます。この制限は、問題の規模を変更するだろうがしかし、それは、その基本的な性質を変えないだろう。以下のための同様のゾーンファイルの数十、おそらく数百人を、維持することを余儀なくされるだろう世界第二レベルドメインのすべての管理者：DNSの管理階層特性は（第1.3.1項を参照）行政悪夢に複製プロセスを回しますドメインの複製。特定の国や言語に関連したゾーンのみが複製された場合でも、管理および追跡の問題は、適切なトップレベルドメインにこれらを結合して、最高の状態では極めて困難であろう同期レプリカのすべてを維持します。そして、サードと第4レベルドメインの管理者の多くは、以降、同様の問題に直面することでしょう。
By contrast, dealing with the names of TLDs as a localization problem, using local translation, is fairly simple, although it places some burden of understanding on the user (see Section 4). Each function represented by a TLD -- a country, generic registrations, or purpose-specific registrations -- could be represented in the local language and character set as needed. And, for countries with many languages -- or users living, working in, or visiting countries where their language is not dominant -- "local" could be defined in terms of the needs or wishes of each particular user.
それがユーザーに理解の一部負担がかかるものの、これとは対照的に、地元の翻訳を使用して、ローカライズの問題などのTLDの名前を扱う、（セクション4を参照）、非常に簡単です。国、ジェネリックの登録、または目的別の登録 - - TLDによって表される各機能は、必要に応じて現地の言語と文字セットで表現することができます。そして、多くの言語と国のために - またはユーザーの生活、で作業、またはその言語が支配的ではありません訪問国 - 「ローカル」の各特定のユーザーのニーズや要望の観点から定義することができます。
An additional benefit is that, if two countries called themselves by the same name in their local languages -- if, e.g., Western Slobbovia and Eastern Slobbovia both called themselves "Slobland" -- local conventions could be followed as long as users understood that only internal forms (in this case, the ISO 3166-based ccTLD name) could be exported outside the country (see Section 3.3).
もし、例えば、西洋Slobboviaと東Slobbovia両方が「Slobland」自分を呼ばれる - - 追加の利点は、二つの国が現地の言語で同じ名前で自分自身を呼び出した場合、ということであるユーザーがいることを理解されるようにローカルの規則がある限り続くことができる唯一の（この場合は、ISO 3166ベースのccTLD名）の内部形式は（3.3節を参照してください）国の外に輸出することができます。
Note that this proposal is to allow mapping of native-language strings to existing TLDs. It would almost certainly be ill-advised to stretch this idea too far and try to map strings that local users would be unlikely to guess into TLDs. For example, there are probably no languages in which the country known in English as "Finland" is called "FI". Thus, one would not want to create a mapping from two characters that look or sound like a Roman "F" and a Roman "I" to the ccTLD ".fi".
この提案は、既存のTLDへのネイティブ言語の文字列のマッピングを可能にするためであることに注意してください。これは、ほぼ確実にすぎこのアイデアを伸ばし、ローカルユーザーがTLDのに推測する可能性は低いだろう文字列をマップしようとするために無分別になります。たとえば、「フィンランド」として英語で知られている国が「FI」と呼ばれているいかなる言語はおそらくありません。このように、一つはccTLDの「.fi」にローマの「F」とローマの「I」のように見えるか、聞こえるの2つの文字からマッピングを作成したいとは思わないでしょう。
It follows from some of the comments above that, while there appears to be some immediate appeal from having (at least) two domains for each country, one using the ISO 3166-1 code [ISO3166] and another one using a name based on the national name in the national language, such a situation would create considerable problems for registrants in both domains. For registrants maintaining enterprise or organizational subdomains, ease of administration of a single family of zone files will usually make a registration in a single top-level domain preferable to replicated sets of them, at least as long as their functional requirements (such a local-language access) are met by the unified structure. For those registrants with no interest in any Internet function or protocols other than use of the HTTP/HTTPS-based web, this problem can be dealt with at the applications level by the use of redirects but, in the general case, that is not a feasible solution.
、一つに基づいて、ISO 3166-1コード[ISO3166]と名前を使用して別のものを使用して、それぞれの国の（少なくとも）二つのドメインを有することから、いくつかの即時魅力があるように見えるが、それは、その上記のコメントの一部から次国家名は国語で、このような状況では、両方のドメインの登録者のためにかなりの問題を作成します。企業や組織のサブドメインを維持する登録者のために、ゾーンファイルの単一の家族の管理のしやすさは、通常、少なくとも限り、その機能要件（例えばローカルからのように、それらの複製されたセットに好適な単一のトップレベルドメインの登録を行います言語アクセス）一体構造で満たされています。 HTTP / HTTPSベースのウェブの使用以外のインターネット機能の関心またはプロトコルなしのもの登録するために、この問題は、リダイレクトを使用することによってアプリケーションレベルで扱うことができるけれども、一般的なケースでは、それはありません実現可能なソリューション。
For countries with multiple national languages that are considered equal and legally equivalent, the advantages of a translation-based approach, rather than multiple registrations and replicated trees, would be even more significant. Actually installing and maintaining a separate TLD for each language would be an administrative nightmare, especially if it was intended that the associated zones be kept synchronized. The oft-suggested proposal to adopt an "exactly one extra domain for each country" rule would essentially require some of the multiple-official-language countries to violate their own constitutions. Conversely, having multiple domains for a given country, based on the number of official languages and without any expectation of synchronization, would give some countries an additional allocation of TLDs that others would certainly consider unfair.
等しいと法的に同等であると考えられる複数の国語、翻訳ベースのアプローチの利点はなく、複数の登録および複製された木が国のために、さらに重要になります。実際には言語ごとに個別のTLDをインストールし、維持することは、それが関連するゾーンが同期を維持することが意図されていた場合は特に、管理悪夢であろう。 「それぞれの国のために正確に一つの余分なドメイン」を採用するためにしばしば推奨の提案ルールは、基本的に、独自の憲法に違反する複数の公式言語の国のいくつかが必要になります。逆に、公式言語の数に及び、同期のいずれか期待せずに基づいて、指定された国のために複数のドメインを有する、いくつかの国に他の人が確かに不公平検討するのTLDの追加配分を与えるだろう。
Of course, having replicated domains might be popular with some registries and registrars, since replication would almost inevitably increase the total number of domains to be registered. Helping that group of registries and registrars, while hurting Internet users by adding administrative overhead and confusion, is not a goal of this document.
もちろん、複製はほとんど必然的に登録するドメインの合計数を増加させるため、ドメインは、いくつかのレジストリとレジストラに人気であるかもしれない複製しました。管理オーバーヘッドと混乱を追加することにより、インターネットユーザーを傷つけながら、レジストリとレジストラそのグループを支援し、この文書の目的ではありません。
While the IDNA tables (actually Nameprep [RFC3491] and Stringprep [RFC3454]) must be identical globally for IDNA to work reliably, the tables for mapping between local names and TLD names could be locally determined, and differ from one locale to another, as long as users understood that international interchange of names required using the standard forms. That understanding puts some additional burden of learning on users, although part of it could be assisted by software (see Section 4).
IDNAを確実に動作させるためIDNAテーブル（実際NAMEPREP [RFC3491]とのstringprepは[RFC3454]）がグローバルに同一でなければならないが、ローカル名とTLD名との間のマッピングのテーブルは局所的に決定することができ、そしてように、別のロケール異なりますユーザーは、名前の国際交流は、標準的なフォームを使用して、必要なことを理解限り。その一部が（セクション4を参照）は、ソフトウェアによって支援することができるが、その理解は、ユーザーに学習のいくつかの追加負担を置きます。
In any event, at least in the foreseeable future, it is likely that DNS names being passed among users in different countries, or using different languages, will be forced to be in punycode form to guarantee compatibility, since those users would not, in general, have the ability to read each other's scripts or have appropriate input facilities (keyboards, etc.) for then. So the marginal knowledge or effort needed to put TLD names into standard form and transmit them in that way would actually be fairly small.
これらのユーザーはいないだろうので、いずれにせよ、少なくとも予見可能な将来において、DNS名が異なる国のユーザー間で渡されている可能性がある、または異なる言語を使用して、一般的には、互換性を保証するためにPunycodeでの形態であることを強制されます、互いのスクリプトを読んだり、その後の適切な入力機能（キーボードなど）を持っている能力を持っています。だから、標準形式にTLD名を入れて、その方法でそれらを送信するために必要な限界知識や努力が、実際にかなり小さくなります。
The concept of using local translation does have one side effect that some portions of the Internet community might consider undesirable. The size and complexity of translation tables, and maintaining those tables, will be, to a considerable extent, a function of the number of top-level domains of interest, the frequency with which new domains are added, and the number of domains added at a time. A country or other locale that wished to maintain a complete set of translations (i.e., so that every TLD had a representation in the local language) would presumably find setting up a table for the current collection of a few hundred domains to be a task that would take some days. If the number of TLDs were relatively stable, with a relatively small number being added at infrequent intervals, the updates could probably be dealt with on an ad hoc basis. But, if large numbers of domains were added frequently, or if the total number of TLDs became very large, maintaining the table might require dedicated staff if each new TLD is to be accommodated. Worse, updating the tables stored on client machines might require update and synchronization protocols and all of the complexities that tend to go with them (see [RFC3696] for a discussion of some related issues in applications).
地元の翻訳を使用しての概念は、インターネットコミュニティのいくつかの部分が望ましくない検討するかもしれない1つの副作用を持っています。サイズおよび複雑変換テーブル、及びそれらのテーブルを維持することは、かなりの程度、関心のトップレベルドメインの数の関数、新しいドメインが追加される頻度、およびで添加ドメインの数に、あろう時間。 （すべてのTLDは、現地の言語での表現を持っていたように、すなわち、）翻訳の完全なセットを維持することを望んだ国または他のロケールは、おそらくその作業になるために数百のドメインの現在のコレクションのためのテーブルを設定見つけるだろう何日かかかるだろう。 TLDの数が比較的少ない数が低頻度の間隔で追加されていると、比較的安定していた場合、アップデートはおそらく、場当たり的に扱うことができます。ドメインの多くが頻繁に追加された場合のTLDの総数が非常に大きくなった場合には、それぞれの新しいTLDが収容される場合でも、または、テーブルを維持することは、専用のスタッフが必要になる場合があります。さらに悪いことに、更新や同期プロトコルとそれに行く傾向にある複雑さのすべてを必要とするかもしれないクライアントマシンに保存されているテーブルを更新する（アプリケーションではいくつかの関連問題の議論のための[RFC3696]を参照）。
In practice, there will be little requirement to translate every TLD into a local language. There are already existing TLDs for which there is no obvious translations in many languages (most notably, ".arpa") or where the translation will be far from obvious to typical users (for example, ".int" and ".aero"). Of course, these could be translated by function: ".arpa" to the local term for "infrastructure", ".int" with "international" or "international organization", ".aero" with "aeronautical" or "airlines", and so on; but it is not clear whether doing so would have significant value. For almost every language, there are dozens of ccTLDs for which there are no translations of the country names into the local language that would be known by anyone other than geographers. If new TLDs are added, there might not be a strong need (or even capability) to have language-specific equivalents for each.
実際には、現地の言語にすべてのTLDを翻訳するために少しの要件があるでしょう。多くの言語に明らかな翻訳が存在しないそのため、既存のTLDがある（特には、「.arpa 『）、またはどこ翻訳は、一般的なユーザーには自明（たとえば、』 .intファイル」と「.aero」のため）から遠くなります。もちろん、これらの機能により、翻訳することができます： 『航空』または 『航空会社』と 『国際的』または 『国際機関』、「.aero」と 『インフラ』、「.intファイル」のためのローカル用語に「.arpa」、等々;そうすることが重要な価値を持っているかどうかは明らかではありません。ほぼすべての言語については、地理学者以外の者によって知られているであろう地域の言語への国の名前のない訳がないそのためのccTLDの数十があります。新しいTLDのが追加されている場合は、それぞれの言語固有の同等物を持っているために強い必要性（あるいは機能）があるではないかもしれません。
An immediate question when proposals such as this one are considered is whether the names for the various TLDs that do not match the strings that are actually in the DNS should be standardized and, if so, by what mechanism. Standardization would promote communication within a country or among people sharing a language. However, it is likely to be very difficult to reach appropriate international agreements to which wide conformance could be expected. Exceptions might arise within particular countries or language groups but, even then, there might be advantages to users being able to specify additional synonymous names that are easy for them to remember. As with IDNA-based IDNs, users who wish to transmit information about domain names to people whose exact capabilities and software are unknown, and to do so with minimal risk of confusion, will probably confine themselves to the names that actually appear in the DNS, i.e., the "punycode" representations.
など、この一つとして提案が考慮される即時の質問は、そうだとすれば、DNSに実際にある文字列と一致していない様々なTLDの名前は何メカニズムによって、標準化する必要があるかどうかです。標準化は、国内や言語を共有する人々の間のコミュニケーションを促進します。しかし、広い適合を期待することができたために、適切な国際協定に到達するのは非常に困難である可能性が高いです。例外は、その後も、特定の国や言語グループ内で発生するかもしれませんが、彼らが覚えやすいです追加の同義語名を指定することができるというユーザーにはメリットがあるかもしれません。 IDNAベースのIDN、その正確な機能とソフトウェア不明である、と混乱のリスクが最小限にそうする人に、ドメイン名に関する情報を送信したいユーザと同じように、おそらく実際にDNSに表示される名前に自分自身を閉じ込めるなり、すなわち、「Punycodeで」表現。
In any event, neither standardization nor uniform use of either the system outlined here or of a specific collection of names is required to make the system work for those who would find it useful. Similarly, mechanisms for country-wide coordination, and examination of the appropriateness or inappropriateness of such mechanisms, is beyond the scope of this document.
いずれにせよ、どちらも標準化やシステムのいずれかの均一な使用はここまたは名前の特定のコレクションの概説それが役立つだろう人のためのシステムを機能させるために必要とされます。同様に、国全体のコーディネートのためのメカニズム、およびそのようなメカニズムの妥当性や不適切の検査は、このドキュメントの範囲を超えています。
Applications that implement the proposal in this document are likely to make the subsequent creation and acceptance of new IDNA-based TLDs significantly more difficult. If this proposal becomes widely adopted, local language names mapped as it suggests will be generally expected by users of those languages to mean the same as a current TLD. Creating a new, stand-alone IDNA-based TLD will then require more deliberation and care to avoid conflicts and, when executed, will require all the application software that maps the name to the existing TLD to change the mapping tables.
この文書の提案を実装するアプリケーションは、その後の創造と新しいIDNAベースのTLDの受け入れを著しく困難にする可能性があります。この提案は、広く採用になった場合、それが示唆するようにマッピングされたローカル言語名は、一般的に、現在のTLDと同じことを意味するためにこれらの言語のユーザが期待されます。新しい、スタンドアローンIDNAベースのTLDを作成すると、その後の衝突を避けるために、より多くの審議とケアが必要になりますと、実行されると、マッピングテーブルを変更するには、既存のTLDに名前をマップするすべてのアプリケーションソフトウェアが必要になります。
For several reasons, this problem may not be as serious in practice as it might first appear. For ccTLDs allocated according to the ISO 3166-1 list, there will presumably be no problem at all: not only are the 3166-1 alpha-2 codes strictly in ASCII, but general trends, such as those embodied in ICANN's "GAC Recommendations" against using country names or codes for any purpose not associated with those specific countries, make conflicts with internationalized names extremely unlikely. Because the DNS does not currently have a usable aliasing function (see Section 1.3.2), it is likely that new IDNA-based TLDs will be allocated only after there is considerable opportunity for countries and other individual entities to identify any problems they see with proposed new names.
いくつかの理由により、この問題は、それが最初に表示される可能性がありますと実際のように深刻ではないかもしれません。 ISO 3166-1リストに従って割り当てられたccTLDのために、おそらく全く問題ありません：ASCIIでの厳密3166-1アルファ2コードされているが、そのようなICANNの「GAC勧告」に具現されるような一般的な傾向だけでなく、これらの特定の国に関連付けられていない任意の目的のために国の名前やコードを使用しないことを、国際名前の競合は極めてまれ作ります。 DNSは、現在使用可能なエイリアシング機能を持っていないので、新しいIDNAベースのTLDは、彼らが見るすべての問題を識別するための国やその他の個々のエンティティのためにかなりの機会があった後にのみ割り当てられたされる可能性がある（1.3.2項を参照してください）新しい名前を提案しました。
It should be clear to anyone who has read this far that the mapping described in this document is limited to TLDs, not full domain names or keywords. In particular, nothing here should be construed as applying to anything other than TLDs, due at least in part to the limitations described in Section 3.1. Further, this document is only about the domain name system (DNS), not about any keyword system. The interactions between particular keyword systems and the proposals here are left as a (possibly very difficult) exercise for the reader or implementer of such systems. However, for the subset of such systems whose intent is to entirely hide DNS names or URIs from the user, their output would presumably be the LDH names that actually appeared in the DNS, i.e., in punycode form for IDNA names and without any application processing of the type contemplated here.
それは、この文書で説明したマッピングは、ドメイン名またはキーワードはフルではない、のTLDに制限されていることをここまで読んでたことのある人には明らかなはずです。特に、ここでは何も少なくとも部分的には3.1節で説明した制限のためのTLD以外のものに適用するものではありません。さらに、このドキュメントでは、ドメインネームシステム（DNS）について、いない任意のキーワードシステムについてです。特定のキーワードシステムとここで提案間の相互作用は、このようなシステムのリーダーまたは実装のための（おそらく非常に難しい）課題として残されています。しかし、意図ユーザからのDNS名またはURIを完全に非表示になるようなシステムのサブセットに対して、それらの出力は、おそらく実際にはDNSで、すなわち、IDNA名のPunycodeでの形態で、任意のアプリケーション処理なしに登場LDH名であろうここでの意図タイプの。
This specification is based on a pair of fairly explicit assumptions. The first is that the greatest and most important impact and value of any internationalization or localization technique is to permit users who share a language or culture to communicate with others who also share that language or culture. Communication among users from different cultures, using different languages or different scripts is inherently more difficult, and still more difficult if they cannot easily identify languages and scripts in common. The reason for those difficulties are age-old issues in language translation and differences among languages and scripts, not problems associated with the DNS or IDNs, however they are represented. That is the second assumption: when communication across language or cultural groups is required, the users who need to do it -- typically a much smaller number than those communicating within the same language and culture -- are going to need to rely on commonly-understood languages and scripts and will need to exert somewhat more care and effort than within their own groups.
この仕様はかなり明白な仮定のペアに基づいています。最初は、多言語やローカライズ技術の最大かつ最も重要な影響と値もその言語や文化を共有する他の人と通信するための言語や文化を共有するユーザーを可能にすることであるということです。彼らは簡単に共通の言語やスクリプトを識別することができない場合は、異なる言語や異なるスクリプトを使用して、異なる文化からのユーザーの間の通信は、本質的に困難であり、さらに困難です。これらの困難さの理由は、古来の言語翻訳における問題や言語やスクリプトの間で違いがあり、DNSかのIDNに関連する問題は、しかし、彼らは表現されません。すなわち、第2の仮定である：言語や文化のグループ間での通信が必要なとき、必要なユーザーはそれを行うには - 通常、同じ言語と文化内で通信するよりもはるかに小さい数は - commonly-に依存する必要があるとしています言語やスクリプトを理解し、自分のグループ内よりもいくらかの注意と努力をする必要があります。
As outlined in the sections above, the suggestions made in this document could clearly be turned into major problems by misuse or misunderstanding. For example, if two applications on the same host used different translation tables, a situation could easily result that would be very confusing to the user. However, in some cases, this would be only slightly worse than some of the alternatives. For example, if, on a given system, IDNs are expressed in native script, but ASCII TLD names are used, cutting and pasting from one application to another may not work as expected, unless both applications and the underlying operating system are all Unicode-based and use the same encoding model for Unicode. Some applications writers have already discovered, even without significant use of IDNs, that they need to support separate "copy string" and "copy link location", and the corresponding "paste" operations. Any use of IDNs or Internationalized Resource Identifiers (IRIs, see [RFC3987]) may require similar operations, or extensions to those operations, to force strings into internal ("punycode" or URI) form on the copy operation and to translate them back on paste. Were that done, the appropriate translations could be performed as part of the same process. If this author's hypothesis is correct -- that these operations are likely to be required on many systems whether this proposal is adopted or not -- then the additional translation operations are likely to be invisible to the user.
上記のセクションで概説したように、このドキュメントで作られた提案は、明らかに誤用や誤解で大きな問題になっていません。同じホスト上の2つのアプリケーションが異なる変換テーブルを使用した場合、状況は容易にそれはユーザーにとって非常に混乱するだろう可能性があります。しかし、いくつかのケースでは、これはわずかに悪化し選択肢のいくつかよりだろう。所与のシステム上で、場合に予想されるように、両方のアプリケーションと基礎となるオペレーティング・システムは、全てUnicode-ない限り、例えば、動作しない可能性が別のアプリケーションからカット＆ペースト、のIDNは、ネイティブスクリプト内で発現されるが、ASCIIのTLD名が使用されていますベースとUnicodeの同じ符号化モデルを使用します。一部のアプリケーションの作家はすでに、彼らは別の「コピー文字列」と「コピーリンクの場所」、および対応する「ペースト」操作をサポートする必要があること、さえのIDNの重要な使用せずに、発見しました。 IDNのか、国際化資源識別子（IRIは、[RFC3987]を参照）の使用は、同様の操作、またはこれらの操作の拡張が必要になることがあり、コピー操作上の内部（「Punycodeで」またはURI）フォームに文字列を強制的に、背面にそれらを変換しますペースト。行われ、適切な翻訳は、同じプロセスの一部として実行することができることでした。この著者の仮説が正しければ - これらの操作は、この提案が採用されているかどうか、多くのシステムで必要とされる可能性があること - 追加の翻訳作業は、ユーザーには見えない可能性が高いです。
In particular, precisely because the translated names proposed here are part of a presentation form, rather than the internal form names, they are inappropriate in a number of circumstances in which a globally-unique, internal-form name is actually required. It would be a poor, indeed dangerous, idea to use these names in security contexts such as names in certificates, access lists, or other contexts in which accurate comparisons are necessary.
具体的には、翻訳された名前は、ここで提案からこそ、プレゼンテーション形式ではなく、内部形式名の一部である、彼らはグローバルにユニークな、内部形式名が実際に必要とされる状況の数が不適切です。このような証明書では名前、アクセスリスト、または正確な比較が必要である、他の文脈などのセキュリティコンテキストでこれらの名前を使用するように貧しい、実際に危険な、アイデアだろう。
A more general issue exists when DNS or IRI references are transferred among users whose systems may be localized for different languages or conventions. In general, a user in one part of the world will not actually know how another user's systems are set up, precisely what software is being used, etc., nor should users be expected or forced to learn that information. But, if the user transmitting an internationalized reference doesn't know that the receiving system supports the same characters and fonts, and that the receiving user is prepared to deal with them, the prudent user will transmit the internal form of the reference in addition to, or even instead of, the native-character form. And, of course, if the reference is transmitted on paper, on a sign, in some coded character set other than Unicode, or even as an image, rather than as a Unicode string, the importance of supplementing it with the internal form becomes even more important. The addition of a translation requirement for TLD labels makes availability of internal forms in interchange significantly more important, but does not actually change the requirement to do so.
DNSまたはIRI参照がそのシステムの異なる言語や慣習に合わせてローカライズすることができるユーザーの間で転送されたときに、より一般的な問題が存在します。一般的には、世界の一部のユーザーが実際には別のユーザーのシステムでは、などを使用している正確にどのようなソフトウェア、設定されている、また、ユーザーが期待されるか、その情報を学習することを強制すべきかを知ることができません。国際化の参照を送信し、ユーザーが受信システムは、同じ文字とフォントをサポートしていること、および受信側ユーザーはそれらに対処する用意があることを知らない場合でも、慎重なユーザーは他に参照の内部形式を送信します、あるいは代わりに、ネイティブの文字の形。参照が紙に送信される場合と、当然、符号に、いくつかの符号化された文字のUnicode以外の設定、あるいは画像としてではなく、Unicode文字列として、内部形式でそれを補足することの重要性もなりますより重要。 TLDラベルの翻訳要件の追加は、交換における内部のフォームの可用性がはるかに重要になりますが、実際にそうするための要件は変更されません。
It may be helpful to note that, in a different networking model than that used in the Internet, both this proposal and IDNA itself are essentially "presentation layer" approaches rather than constructions that can be expected to work well in interchange.
インターネットで使用されるものとは異なるネットワークモデルで、ことに注意することは役立つかもしれない、両方のこの提案とIDNA自体は基本的に、「プレゼンテーション層」のアプローチではなく、交換にうまく動作するように期待することができる構造です。
This entire specification addresses issues in internationalization and especially the boundaries between internationalization and localization and between network protocols and client/user interface actions.
この全体の仕様では、国際化の課題に対処し、国際化と地域間のネットワーク・プロトコルとクライアント/ユーザー・インターフェース・アクション間の特に境界。
IDNA provides a client-based mechanism for presenting Unicode names in applications while passing only ASCII-based names on the wire. As such, it constitutes a major step along the path of introducing a client-based presentation layer into the Internet. Client-based presentation layer transformations introduce risks from non-conforming tables that can change meaning without external protection. For example, if a mapping table normally maps A onto C, and that table is altered by an attacker so that A maps onto D instead, much mischief can be committed. On the other hand, these are not the usual sort of network attacks: they may be thought of as falling into the "users can always cause harm to themselves" category. The local translation model outlined here does not significantly increase the risks over those associated with IDNA, but may provide some new avenues for exploiting them.
IDNAは、ワイヤ上だけASCIIベースの名前を渡しながら、アプリケーションでのUnicode名を提示するためのクライアントベースのメカニズムを提供します。このように、インターネットにクライアントベースのプレゼンテーション層を導入する経路に沿って主要なステップを構成しています。クライアントベースのプレゼンテーション層の変換は、外部の保護なしの意味を変更することができ、非適合表からのリスクを紹介します。例えば、マッピング・テーブルは、通常Cにマッピングし、そのテーブルではなく、Dへのマップは、はるかにいたずらをコミットすることができるように、攻撃者によって変更されます。一方、これらは、ネットワーク攻撃の通常の一種ではありません。彼らは、カテゴリ「常に自分自身に害を引き起こす可能性がありますユーザー」に陥ると考えることができます。ここで概説ローカル翻訳モデルを大幅にIDNAに関連したものよりもリスクは増加しませんが、それらを活用するためのいくつかの新しい道を提供することができます。
Both this approach and IDNA rely on having updated programs present information to the user in a very different form than the one in which it is transmitted on the wire. Unless the internal (wire) form is always used in interchange, or at least made available when DNS names are exchanged, there are possibilities for ambiguity and confusion about references. As with IDNA itself, if only the "wire" form is presented, the user will perceive that nothing of value has been done, i.e., that no internationalization or localization has occurred. So presentation of the "wire" form to eliminate the potential ambiguities is unlikely to be considered an acceptable solution, regardless of its security advantages.
このアプローチとIDNAの両方は、それがワイヤ上で送信されるものとは非常に異なる形でユーザに提示情報プログラムを更新したに依存しています。内部（ワイヤー）フォームは、常に交換に使用される、またはDNS名が交換されたときに、少なくとも利用可能にされていない限り、参照に関するあいまいさと混乱の可能性があります。唯一の「ワイヤ」形態が提示されている場合IDNA自体と同様に、ユーザには、国際または局在化が発生していないこと、すなわち、値の何も行われていないことを認識されよう。だから、潜在的なあいまいさを排除するための「ワイヤ」形式のプレゼンテーションは関係なく、そのセキュリティ上の利点の、受け入れ可能な解決策と見なされることはほとんどありません。
If the translation tables associated with the technique suggested here are obtained from a server, or translations are obtained from a remote machine using some protocol, the mechanisms used should ensure that the values received are authentic, i.e., that neither they, nor the query for them, have been intercepted and tampered with in any way.
技術に関連した変換テーブルがここで提案した場合、サーバから取得している、または翻訳は、いくつかのプロトコルを使用してリモートマシンから取得され、使用されるメカニズムは、受信した値が本物であることを確認する必要があり、すなわち、彼ら、またのためのクエリでもないこと彼らは、どのような方法で傍受され、改ざんされています。
This document was inspired by a number of conversations in ICANN, IETF, MINC, and private contexts about the future evolution and internationalization of top level domains. Unknown to the author, but unsurprisingly (the general concept should be obvious to anyone even slightly skilled in the relevant technologies), the concept has been apparently developed independently in other groups but, as far as this author knows, not written up for general comment. Discussions within, and about, the ICANN IDN Committee were particularly helpful, although several of the participants in that committee may be surprised about where those discussions led. Email correspondence with several people after the first version of this document was posted, notably Richard Hill, Paul Hoffman, Lee XiaoDong, and Soobok Lee, led to considerable clarification in the subsequent versions. The author is particularly grateful to Paul Hoffman for extensive comments and additional text for the third version and to Patrik Faltstrom, Joel Halpern, Sam Hartman, and Russ Housley for suggestions incorporated into the final one.
この文書は、ICANN、IETF、MINC、トップレベルドメインの将来の発展と国際化に関する民間の文脈における会話の数に触発されました。著者に未知の、しかし当然限り、この著者が知っているように、一般的なコメントをアップ書かれていない、という概念は明らかに、他のグループに独自に開発されてきたが（一般的な概念は、関連技術の少しでも業者には明らかです） 。その委員会の参加者のいくつかは、それらの議論が主導場所について驚くかもしれませんが、内、約議論は、ICANN IDN委員会は、特に有用でした。このドキュメントの最初のバージョンが掲載された後、いくつかの人々、特にリチャード・ヒル、ポール・ホフマン、リー暁東、およびSoobokリーとのメールの対応は、それ以降のバージョンでは、かなりの明確化につながりました。著者は最後の1に組み込まれた提案のための3番目のバージョン用とパトリックFaltstrom、ジョエル・ハルパーン、サム・ハートマン、とラスHousleyへの大規模なコメントや追加のテキストのポール・ホフマンに特に感謝しています。
The first version of this document was posted on October 21, 2002.
このドキュメントの最初のバージョンは2002年10月21日に掲載されました。
[ISO10646] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane", ISO Standard 10646-1, May 1993.
[ISO10646]国際標準化機構、「情報技術 - ユニバーサルマルチオクテット符号化文字集合（UCS） - 第1部：アーキテクチャと基本多言語面」、ISO規格10646-1、1993年5月。
[ISO3166] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO Standard 3166-1:1977, 1997.
標準化のために[ISO3166]国際機関、「国及びその下位区分の名前の表現のためのコード - 第1部：国コード」、ISO規格3166-1：1977、1997。
[MIME] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, June 1992.
[MIME] Borenstein、N.とN.フリード、「MIME（多目的インターネットメール拡張）：インターネットメッセージ本体の形式を指定し、説明するためのメカニズム」、RFC 1341、1992年6月。
Updated and replaced by Freed, N. and N. Borenstein,
"Multipurpose Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies", RFC2045, November
1996. Also, Moore, K., "Representation of Non-ASCII Text
in Internet Message Headers", RFC 1342, June 1992.
Updated and replaced by Moore, K., "MIME (Multipurpose
Internet Mail Extensions) Part Three: Message Header
Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[RFC1480] Cooper, A. and J. Postel, "The US Domain", RFC 1480, June 1993.
[RFC1480]クーパー、A.とJ.ポステル、 "米国ドメイン"、RFC 1480、1993年6月。
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[RFC1591]ポステル、J.、 "ドメインネームシステムの構造と委任"、RFC 1591、1994年3月。
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[RFC2672]クロフォード、M.、 "非ターミナルDNS名リダイレクション"、RFC 2672、1999年8月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、RFC 3454、2002年12月。
[RFC3467] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, February 2003.
[RFC3467] Klensin、J.、RFC 3467、2003年2月 "ドメインネームシステム（DNS）の役割"。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3491]ホフマン、P.とM.ブランシェ、 "NAMEPREP：国際化ドメイン名のためのstringprepプロフィール（IDN）"、RFC 3491、2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]コステロ、A.、 "ピュニコード：アプリケーションにおける国際化ドメイン名のUnicodeのブートストリングのエンコード（IDNA）"、RFC 3492、2003年3月。
[RFC3696] Klensin, J., "Application Techniques for Checking and Transformation of Names", RFC 3696, February 2004.
[RFC3696] Klensin、J.、 "確認と名の形質転換のためのアプリケーションテクニック"、RFC 3696、2004年2月。
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.
[RFC3932] Alvestrand、H.、 "IESGとRFC Editorのドキュメント：プロシージャ"、BCP 92、RFC 3932、2004年10月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] Duerst、M.およびM. Suignard、 "国際化リソース識別Fiers（IRI）"、RFC 3987、2005年1月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張機能のためのリソースレコード"、RFC 4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。
Author's Address
著者のアドレス
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョン・C Klensin 1770マサチューセッツアベニュー、＃322ケンブリッジ、MA 02140 USA
Phone: +1 617 491 5735 EMail: john-ietf@jck.com
電話：+1 617 491 5735 Eメール：john-ietf@jck.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。