[要約] RFC 4185は、DNSトップレベルドメイン（TLD）名における国内および地域の文字に関するガイドラインです。その目的は、異なる言語や文字セットをサポートするために、国内および地域の文字をTLD名に使用する方法を提供することです。
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).
Copyright（c）The Internet Society（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は、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄し、公開する決定はIETFワークとの競合に関するIESGレビューとは別にIETFレビューに基づいていないことに注意してください。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。詳細については、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.
言語を共有する人は、通常、その言語を書くために通常使用されるキャラクターを使用して、その中でコミュニケーションをとることを好みます。1992年[MIME]のMIMEの導入以来、電子メールメッセージボディと選択されたヘッダーで相互に合わせの文字と言語を使用するための標準があり、WebはMIMEを使用して、その創業以来多言語テキストを許可しています。プライベートコンベンションを使用して、非ローマンキャラクターコンテンツの実際の使用がさらに早くなりました。ただし、ドメイン名は電子メールアドレスとURLでユーザーに公開されます。通常、ドメイン名も露出する対応する配置は、他のアプリケーションプロトコルに対して行われます。露出したドメイン名と国際化要件の組み合わせにより、非常に制限的なASCIIサブセット「HostName」（または「Letter-Digit-Hyphen」（「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: 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].
「DNSの変更」としてではなく、「さまざまな言語やキャラクターセットからのDNSへのアクセスをユーザーに提供する」という要件が見られると、IETFおよび他の場所で3セットの提案が現れました。それらは次のとおりでした。1。ユーザー可視された文字列をASCII互換フォームに再現するクライアントソフトウェアで処理を実行し、DNSプロトコルを安全に渡してDNSに保存できます。これは、たとえば、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. DNSを変更して、ASCII以外の名前や文字列により修正します。いくつかの異なる手法を使用して、これを行うためのさまざまな提案がありました。これらのいくつかは、さまざまなベンダーによって独自のベースで実装されています。それらのどれも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）のみに適用される4番目のアプローチを提案します。このアプローチでは、アプリケーションのユーザーインターフェイスをTLDの非ASCII名を既存のTLDにマッピングすることを含み、上記の戦略の代替または補足として使用できます。
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名が含まれるために、すべての完全に認定されたDNS名が必要であるため、少なくとも1つの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コードゾーンの内容。これらの問題のいくつかを以下に説明します。しかし、ユーザーの行動と好みを調べる（または考えている）場合、アラビア語の中国のCCTLDの名前を中国のCCTLDの名前を書くことができることがほぼ重要です。少なくとも、曖昧さと対立を避けることができる程度まで、人々は好む言語とキャラクターセットを使用できるはずです。中国ですべて中国語のドメイン名を持ちたいのと同じ理由で、TLDが漢字である場合でも、第2レベル以降が漢字であるドメインの見かけの中国語TLDを持つ能力を持つことが重要ですそれ自体は、主に中国語を話す登録者とユーザーにサービスを提供しています。
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ブラウザーがアラビア語を正しく入力してレンダリングできる可能性はわずかです。これは、多言語のTLD問題に直接的な影響を及ぼします。これは、DNSのCCTLDSの名前を単純に変更して、世界中の人々がそれらの名前を入力することを妨げることなく、特定の国の非ASCII名の1つに変更することはできないからです。
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.
ドメイン名システムは、「管理階層」のアイデアにしっかりと根ざしており、そのエンティティは、その亜科に適用可能なポリシーに責任を負う階層の特定のノードを担当しています（[RFC1034]、[RFC1035]、および[RFC1591]）。このモデルは、特定の企業のドメインとサブドメインに対して非常にうまく機能します。企業の状況では、組織構造に合わせて階層を編成できます。ポリシーを設定する確立された方法があります。そして、少なくとも、ドメイン内のすべての登録者の間で全体的な目標と目標に関する共有の仮定があります。ドメインが、そのようなドメインのすべてのエンティティとサブドメインに適用されるべき規則に合意することが困難であるため、一般的なポリシーの仮定を欠く無関係なエンティティによって共有される場合、より問題があります。一般に、無関係なエンティティの状況は、TLD（第2レベルの名前）に登録されているラベルについて常に勝ちます。例外は、第2レベルが構造的であるTLDで発生します（たとえば、.co、.ac、.govの規則、または.us [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.
TLDSは、これらの2番目（または3番目の）レベル名の一貫した登録ポリシーを持つ場合がありますが、必要ありません。国（またはCCTLD管理者）は、多くの場合、エンティティがCCTLDに登録する可能性のあるルール、および名前がどのような形で取るかについてのルールを採用しています。RFC 1591は、当時のGTLDのほとんどの登録基準を概説しました。しかし、これらの規範は近年ほとんど無視されています。いくつかの最近の「スポンサー」および目的固有のドメインは、適切な登録に関する非常に具体的なルールに基づいています。対照的に、ルートの均一な登録規則は不可能です。ほぼ定義上、ルート（TLD）に登録されているサブドメインは多様であり、すべてのルートサブドメインに適用される名前のタイプと形式に関する単一のポリシーは実現可能です。
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と同じ値を持つように見えます。ただし、ルート内のYからCへのcName参照は、A.B.yを参照可能（または定義された）にしません。2番目のレコードタイプのDNAME [RFC2672]は、ツリーの一部にエイリアスを提供できます。しかし、多くの人はそれが技術的には問題であると信じています。少なくとも、ゾーン間の参照が発生したときに同期の問題を引き起こす可能性があり、あるドメインから別のドメインへの移行を可能にする手段を除き、IETF内でその使用が推奨されています。さらに別のエイリアスタイプのレコードタイプの設計が検討されたとしても、Query-Response IntegrityおよびDNSSECゾーンの署名のDNS技術的制約（[RFC4033]、[RFC4034]、および[RFC4035]）は、それを非常に不可能にすることができます。「代わりにSEE」または真の同義語参照の目的の要件を満たすことを定義します。
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を含むものはすべてグローバルである必要があります。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は、ネットワーク上の個々のホストで厳密に行われるアクションの標準化に関与することを避け、代わりに「ワイヤー上」、つまりネットワークホスト間のプロトコルで観察可能な動作に限定していました。この一般原則の例外は、相互運用性を維持するために互換性のある方法でデータを使用したり、値を解釈するために異なるクライアントが必要である場合に行われました。電子メールとWebボディ形式の標準、および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に関する重要な観察は、それをサポートするアプリケーションプログラムは、すでにクライアントでかなりの変換作業を行っているということです。ユーザーに「On the Wire」形式を単に提示するだけではありません。また、アプリケーションの実装がIDNAによって呼び出されたマッピングとは異なるマッピングを行う場合、ユーザーが予期しない動作について不平を言う場合にのみ検出される可能性があります。送信されたプニュコード文字列が有効である限り、サーバーはそれらの文字列を開発するためにどのマッピングが適用されたかを知ることができません。
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のリストとローカルデザインの名前を含むテーブルを維持することをお勧めします。CCTLDSの場合、これらは、関連する国がローカルで知られている名前（または地元の標準の略語）である可能性があります（ASCIIキャラクターなど）。アプリケーションデザイナーの側（たとえば、ローカルフォームが実際のTLD名と競合しないようにするため）の側面にある程度注意が払われているため、ユーザーからの特定のTLD名前が特別なタグや問題なしにローカルまたは標準形式のいずれかである可能性があります。これらのクライアントプログラムによってDNS名が受信されると、IDNAが残りの名前に適用される前に、TLDラベルがローカルフォームにマッピングされます。ユーザーから名前を受信すると、IDNAを適用するか、他のDNS処理で使用する前に、ローカルTLD名がグローバルにマッピングされます。
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にアクセスできる韓国のユーザーは、特に第2レベルのドメインが韓国の名前を持つ場合、他の国に関連する一般的なトップレベルのドメインとドメインの両方が同様にアクセスできることを期待するあらゆる理由を持っています。スペインまたはポルトガルにネイティブ、またはラテンアメリカにあるユーザーは、おそらく同様の期待を持っているでしょうが、韓国語ではなくスペイン語やポルトガルの名前を使用することを期待しています。
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の管理階層特性（セクション1.3.1を参照）は、複製プロセスを管理の悪夢に変えます。ドメインの複製。特定の国または言語に関連するゾーンのみが複製されたとしても、管理および追跡の問題を適切なトップレベルのドメインに結合し、すべてのレプリカを同期させることは、せいぜい非常に困難です。また、第3レベルおよび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).
追加の利点は、2つの国が地元の言語で同じ名前で自分自身を呼んだ場合 - たとえば、西スロブビアと東スロブビアがどちらも自分自身を「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へのネイティブ言語文字列のマッピングを許可することに注意してください。このアイデアを伸ばしすぎて、ローカルユーザーがTLDSに推測する可能性が低い文字列をマッピングしようとすることは、ほぼ確実に賢明ではありません。たとえば、英語で「フィンランド」として知られている国が「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.
上記のコメントのいくつかから、各国に（少なくとも）2つのドメインを持っていることから、1つはISO 3166-1コード[ISO3166]を使用し、もう1つはに基づいた名前を使用していることから、すぐに魅力があるように見えますが、国語の国民名、このような状況は、両方のドメインの登録者にかなりの問題を引き起こすでしょう。企業または組織のサブドメインを維持する登録者の場合、単一のファミリーのゾーンファイルの管理の容易さは通常、単一のトップレベルドメインでの登録を、少なくともそれらの機能要件（そのようなローカル - そのようなローカル）を複製したセットよりも好ましいものにします。言語アクセス）は、統一された構造によって満たされます。HTTP/HTTPSベースのWebの使用以外のインターネット機能やプロトコルに関心のない登録者の場合、この問題はリダイレクトを使用することでアプリケーションレベルで対処できますが、一般的な場合は、それはそうではありません。実行可能なソリューション。
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をインストールして維持することは、管理の悪夢になります。「各国の1つの追加ドメイン」規則を採用するという頻繁に提案された提案は、基本的に、複数の言語国の一部が自分の憲法に違反することを要求するでしょう。逆に、公用語の数に基づいて、同期を期待することなく、特定の国に複数のドメインを持つことは、一部の国には、他の国が確かに不公平と見なす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テーブル（実際にはnameprep [rfc3491]およびstringprep [rfc3454]）は、IDNAが確実に動作するためにグローバルに同一でなければなりませんが、ローカル名と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名が渡されたり、異なる言語を使用したりすることは、一般的にはユーザーがそうではないため、互換性を保証するためにプニグル型の形になることを余儀なくされる可能性があります。、お互いのスクリプトを読んだり、その後の適切な入力施設（キーボードなど）を持っていることができます。したがって、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).
ローカル翻訳を使用するという概念には、インターネットコミュニティの一部が望ましくないと考えるかもしれない副作用があります。翻訳テーブルのサイズと複雑さ、およびそれらのテーブルの維持は、かなりの程度まで、関心のあるトップレベルのドメインの数、新しいドメインが追加される頻度、および追加されるドメインの数の関数となります時間。翻訳の完全なセットを維持したい国またはその他のロケール（つまり、すべての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をローカル言語に変換するための要件はほとんどありません。すでに多くの言語に明らかな翻訳がない（最も顕著な「.ARPA」）、または翻訳が典型的なユーザー（たとえば、 ".int" and ".aero"）には程遠い場所では、すでに既存のTLDがあります。。もちろん、これらは機能によって翻訳できます：「.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ベースのIDNSと同様に、ドメイン名に関する情報を正確な機能とソフトウェアが不明であり、混乱のリスクを最小限に抑える人に送信したいユーザーは、おそらくDNSに実際に表示される名前に限定されます。すなわち、「パニコード」表現。
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リストに従って割り当てられたCCTLDSの場合、おそらくまったく問題はありません。3166-1アルファ-2コードは、ASCIIで厳密にコードするだけでなく、ICANNの「GAC推奨」に具体化された傾向などの一般的な傾向があります。これらの特定の国に関連付けられていない目的のために国名またはコードを使用することに対して、国際化された名前との対立は非常にありそうにありません。DNSには現在使用可能なエイリアシング関数がないため（セクション1.3.2を参照）、新しいIDNAベースのTLDSは、国や他の個々のエンティティが表示される問題を特定してもかなりの機会がある後にのみ割り当てられる可能性があります。提案された新しい名前。
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に実際に表示されたLDH名、つまりIDNA名の場合、アプリケーション処理なしのPunycode形式であると考えられます。ここで検討されているタイプの。
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.
この仕様は、かなり明示的な仮定のペアに基づいています。1つ目は、国際化やローカリゼーションのテクニックの最大かつ最も重要な影響と価値は、言語や文化を共有するユーザーがその言語や文化を共有する他の人とコミュニケーションをとることを許可することです。異なる文化のユーザー間のコミュニケーション、異なる言語や異なるスクリプトを使用することは本質的に難しく、言語やスクリプトを共通する言語やスクリプトを簡単に識別できない場合はさらに困難です。これらの困難の理由は、言語翻訳における古くからの問題と、言語やスクリプト間の違いであり、DNSやIDNに関連する問題ではありませんが、それらは表されます。それが2番目の仮定です。言語や文化グループ間のコミュニケーションが必要な場合、それを行う必要があるユーザー - 通常、同じ言語と文化内で通信するものよりもはるかに少ない数字 - は一般的に依存する必要があります - 言語とスクリプトを理解し、自分のグループよりもやや注意と努力をする必要があります。
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つのアプリケーションが異なる翻訳テーブルを使用した場合、ユーザーにとって非常に混乱する状況が簡単に生じる可能性があります。ただし、場合によっては、これはいくつかの選択肢よりもわずかに悪いだけです。たとえば、特定のシステムでIDNがネイティブスクリプトで表現されているが、ASCII TLD名が使用されている場合、アプリケーションと基礎となるオペレーティングシステムの両方がすべてユニコードでない限り、あるアプリケーションから別のアプリケーションへの切断と貼り付けは期待どおりに機能しない場合があります。Unicodeに同じエンコードモデルに基づいて使用します。一部のアプリケーションライターは、IDNを大幅に使用しなくても、個別の「コピー文字列」と「コピーリンクの場所」、および対応する「貼り付け」操作をサポートする必要があることをすでに発見しています。IDNまたは国際化されたリソース識別子（IRIS、[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の参照が、システムが異なる言語や慣習にローカライズされる可能性のあるユーザー間で転送される場合、より一般的な問題が存在します。一般に、世界の一部のユーザーは、他のユーザーのシステムがどのように設定されているか、正確にどのソフトウェアが使用されているかなどを実際に知りません。しかし、国際化された参照を送信するユーザーが、受信システムが同じ文字とフォントをサポートしていること、および受信ユーザーがそれらに対処する準備ができていることを知らない場合、慎重なユーザーは参照の内部形式を送信します、または、ネイティブキャラクターの形でさえあります。そして、もちろん、参照が紙、サイン、ユニコード以外のコード化された文字セット、またはユニコード文字列としてではなく画像としてさえも送信された場合、内部形式でそれを補うことの重要性は偶数になりますより重要。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名を提示するためのクライアントベースのメカニズムを提供します。そのため、クライアントベースのプレゼンテーションレイヤーをインターネットに導入する道に沿った大きなステップを構成します。クライアントベースのプレゼンテーションレイヤー変換は、外部保護なしで意味を変える可能性のある不適合テーブルからリスクを導入します。たとえば、マッピングテーブルが通常Aを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委員会内の議論は特に役立ちましたが、その委員会の参加者の何人かは、それらの議論がどこにリードしたかについて驚くかもしれません。このドキュメントの最初のバージョンが投稿された後、複数の人々との通信、特にリチャード・ヒル、ポール・ホフマン、リー・シアドン、スボック・リーが、その後のバージョンでかなりの明確化をもたらしました。著者は、3番目のバージョンの広範なコメントと追加のテキストについて、ポール・ホフマンに特に感謝しています。
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。and N. Freed、「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.
N. and N. Borenstein、「Multipurpose Internet Mail Extensions（MIME）パート1：インターネットメッセージボディの形式」、RFC2045、1996年11月。インターネットメッセージヘッダー」、RFC 1342、1992年6月。Moore、K。、「Mime（多目的インターネットメールエクステンション）パート3：RFC 2047、1996年11月のメッセージヘッダー拡張機能」
[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] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC1480] Cooper, A. and J. Postel, "The US Domain", RFC 1480, June 1993.
[RFC1480] Cooper、A。およびJ. Postel、「The Us Domain」、RFC 1480、1993年6月。
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[RFC1591] Postel、J。、「ドメイン名システム構造と委任」、RFC 1591、1994年3月。
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[RFC2672] Crawford、M。、「非末端DNS名リダイレクト」、RFC 2672、1999年8月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454] Hoffman、P。およびM. Blanchet、「国際化された文字列の準備（「StringPrep」）」、RFC 3454、2002年12月。
[RFC3467] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, February 2003.
[RFC3467]クレンシン、J。、「ドメイン名システムの役割（DNS）」、RFC 3467、2003年2月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3491] Hoffman、P。およびM. Blanchet、「NamePrep：Internationalized Domain Name（IDN）のStringPrepプロファイル」、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] Costello、A。、「Punycode：Applications（IDNA）の国際化ドメイン名のUnicodeのブートストリングエンコーディング」、RFC 3492、2003年3月。
[RFC3696] Klensin, J., "Application Techniques for Checking and Transformation of Names", RFC 3696, February 2004.
[RFC3696]クレンシン、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エディタードキュメント：手順」、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、「国際化されたリソース識別子（IRIS）」、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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張のプロトコル変更」、RFC 4035、2005年3月。
Author's Address
著者の連絡先
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョンCクレンシン1770マサチューセッツアベニュー、＃322ケンブリッジ、マサチューセッツ州02140 USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。