Network Working Group J. Klensin
Request for Comments: 3467 February 2003
Category: Informational
Role of the Domain Name System (DNS)
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 (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document reviews the original function and purpose of the domain name system (DNS). It contrasts that history with some of the purposes for which the DNS has recently been applied and some of the newer demands being placed upon it or suggested for it. A framework for an alternative to placing these additional stresses on the DNS is then outlined. This document and that framework are not a proposed solution, only a strong suggestion that the time has come to begin thinking more broadly about the problems we are encountering and possible approaches to solving them.
このドキュメントでは、ドメインネームシステム（DNS）の本来の機能と目的をレビュー。これは、DNSが最近適用されており、新しい需要のいくつかはそれのためにその上に配置されるか、または提案される目的の一部でその歴史を対比します。 DNS上でこれらの追加の応力を配置する代替のためのフレームワークは、次に概説します。このドキュメントおよびそのフレームワークを提案したソリューション、時間がそれらを解決するため、我々が直面している問題と可能なアプローチについて、より広く考え始めるようになってきたことだけ強く示唆ではありません。
Table of Contents
目次
1. Introduction and History ..................................... 2
1.1 Context for DNS Development ............................... 3
1.2 Review of the DNS and Its Role as Designed ................ 4
1.3 The Web and User-visible Domain Names ..................... 6
1.4 Internet Applications Protocols and Their Evolution ....... 7
2. Signs of DNS Overloading ..................................... 8
3. Searching, Directories, and the DNS .......................... 12
3.1 Overview ................................................. 12
3.2 Some Details and Comments ................................. 14
4. Internationalization ......................................... 15
4.1 ASCII Isn't Just Because of English ....................... 16
4.2 The "ASCII Encoding" Approaches ........................... 17
4.3 "Stringprep" and Its Complexities ......................... 17
4.4 The Unicode Stability Problem ............................. 19
4.5 Audiences, End Users, and the User Interface Problem ...... 20
4.6 Business Cards and Other Natural Uses of Natural Languages. 22
4.7 ASCII Encodings and the Roman Keyboard Assumption ......... 22
4.8 Intra-DNS Approaches for "Multilingual Names" ............. 23
5. Search-based Systems: The Key Controversies .................. 23
6. Security Considerations ...................................... 24
7. References ................................................... 25
7.1 Normative References ...................................... 25
7.2 Explanatory and Informative References .................... 25
8. Acknowledgements ............................................. 30
9. Author's Address ............................................. 30
10. Full Copyright Statement ..................................... 31
The DNS was designed as a replacement for the older "host table" system. Both were intended to provide names for network resources at a more abstract level than network (IP) addresses (see, e.g., [RFC625], [RFC811], [RFC819], [RFC830], [RFC882]). In recent years, the DNS has become a database of convenience for the Internet, with many proposals to add new features. Only some of these proposals have been successful. Often the main (or only) motivation for using the DNS is because it exists and is widely deployed, not because its existing structure, facilities, and content are appropriate for the particular application of data involved. This document reviews the history of the DNS, including examination of some of those newer applications. It then argues that the overloading process is often inappropriate. Instead, it suggests that the DNS should be supplemented by systems better matched to the intended applications and outlines a framework and rationale for one such system.
DNSは、古い「ホストテーブル」システムのための代替として設計されました。両方のネットワークより抽象的なレベル（IP）アドレス（例えば、[RFC625]、[RFC811]、[RFC819]、[RFC830]、[RFC882]）におけるネットワーク資源の名前を提供することを目的としました。近年では、DNSは、新しい機能を追加するために多くの提案で、インターネットの利便性のデータベースとなっています。のみ、これらの提案のいくつかは成功しています。それが存在し、広くその既存の構造、機能、およびコンテンツが関係するデータの特定の用途に適していないため、展開されているので、多くの場合、DNSを使用する主な（または唯一）の動機です。この文書では、これらの新しいアプリケーションのいくつかの検査を含め、DNSの歴史をレビュー。その後、オーバーロードプロセスがしばしば不適切であると主張しています。その代わりに、DNSが意図する用途に合わせた、より良いシステムによって補完されなければならないことを示唆していると、そのようなシステムのためのフレームワークと根拠の概要を説明します。
Several of the comments that follow are somewhat revisionist. Good design and engineering often requires a level of intuition by the designers about things that will be necessary in the future; the reasons for some of these design decisions are not made explicit at the time because no one is able to articulate them. The discussion below reconstructs some of the decisions about the Internet's primary namespace (the "Class=IN" DNS) in the light of subsequent development and experience. In addition, the historical reasons for particular decisions about the Internet were often severely underdocumented contemporaneously and, not surprisingly, different participants have different recollections about what happened and what was considered important. Consequently, the quasi-historical story below is just one story. There may be (indeed, almost certainly are) other stories about how the DNS evolved to its present state, but those variants do not invalidate the inferences and conclusions.
続くコメントのいくつかは、やや修正主義です。グッドデザインとエンジニアリングは、多くの場合、将来的に必要になることについてのデザイナーによる直感のレベルが必要です。誰もがそれらを明確にすることができないため、これらの設計上の決定のいくつかの理由は、一度に明示されていません。以下の議論は、その後の発展と経験に照らして、インターネットの主要な名前空間（「クラス= IN」DNS）に関する決定の一部を再構築します。また、インターネットに関する特定の意思決定のための歴史的な理由は、多くの場合、深刻ではない、驚くほど、同時にunderdocumentedとして、別の参加者が重要であると考えられた何が起こったとどの程度異なるの思い出を持っています。その結果、下記の準歴史的な物語はただ一つの物語です。 （ほぼ確実に、実際にされている）DNSは、その現在の状態に進化しますが、これらの変異体は推論や結論を無効にしていない方法についての他の物語があるかもしれません。
This document presumes a general understanding of the terminology of RFC 1034 [RFC1034] or of any good DNS tutorial (see, e.g., [Albitz]).
この文書は、RFC 1034 [RFC1034]の用語の一般的な理解を前提とし、または任意の良いDNSチュートリアルの（参照、例えば、[Albitz]）。
During the entire post-startup-period life of the ARPANET and nearly the first decade or so of operation of the Internet, the list of host names and their mapping to and from addresses was maintained in a frequently-updated "host table" [RFC625], [RFC811], [RFC952]. The names themselves were restricted to a subset of ASCII [ASCII] chosen to avoid ambiguities in printed form, to permit interoperation with systems using other character codings (notably EBCDIC), and to avoid the "national use" code positions of ISO 646 [IS646]. These restrictions later became collectively known as the "LDH" rules for "letter-digit-hyphen", the permitted characters. The table was just a list with a common format that was eventually agreed upon; sites were expected to frequently obtain copies of, and install, new versions. The host tables themselves were introduced to:
ARPANETの全体始動後期間の生活とほぼ最初の十年の間、またはそうRFC625 [、ホスト名のリストとすると、頻繁に更新され、「ホストテーブル」に維持されたアドレスからのマッピングインターネットの動作]、[RFC811]、[RFC952]。名前自体は、ASCIIのサブセットに制限された[ASCII]他の文字コーディング（特にEBCDIC）を使用して、システムとの相互運用を可能にするために、およびISO 646 [IS646の「国内使用」のコードの位置を避けるために、印刷された形であいまいさを避けるために選択]。これらの制限は、後に一括して「文字・数字・ハイフン」のための「LDH」のルール、許可された文字として知られるようになりました。テーブルには、最終的に合意された共通のフォーマットでリストだけでした。サイトは頻繁に、新しいバージョンのコピーを入手し、インストールすることが期待されていました。ホストテーブル自体はに導入されました。
o Eliminate the requirement for people to remember host numbers (addresses). Despite apparent experience to the contrary in the conventional telephone system, numeric numbering systems, including the numeric host number strategy, did not (and do not) work well for more than a (large) handful of hosts.
Oホスト番号（アドレス）を覚えておくべき人々のための必要性を排除します。従来の電話システムでは逆に明らかな経験にもかかわらず、数値のホスト番号戦略を含む数値のナンバリングシステムでは、ありませんでした（としません）ホストの（大）一握り以上のために働きます。
o Provide stability when addresses changed. Since addresses -- to some degree in the ARPANET and more importantly in the contemporary Internet -- are a function of network topology and routing, they often had to be changed when connectivity or topology changed. The names could be kept stable even as addresses changed.
アドレスが変更されたときに、Oの安定性を提供します。アドレス以来 - 現代のインターネットでより重要なのARPANETとで、ある程度までは - ネットワークトポロジとルーティングの関数である、彼らはしばしば、接続またはトポロジが変更されたときに変更する必要がありました。アドレスが変更されたとしても名を安定に保つことができます。
o Provide the capability to have multiple addresses associated with a given host to reflect different types of connectivity and topology. Use of names, rather than explicit addresses, avoided the requirement that would otherwise exist for users and other hosts to track these multiple host numbers and addresses and the topological considerations for selecting one over others.
O接続性とトポロジの種類を反映するために、特定のホストに関連付けられた複数のアドレスを持っている機能を提供します。名前の使用は、むしろ明示的なアドレスよりも、そうでない場合は、他の上で1つを選択するために、これらの複数のホスト番号とアドレスとトポロジー的配慮を追跡するために、ユーザーと他のホストのために存在するであろう要件を回避しました。
After several years of using the host table approach, the community concluded that model did not scale adequately and that it would not adequately support new service variations. A number of discussions and meetings were held which drew several ideas and incomplete proposals together. The DNS was the result of that effort. It continued to evolve during the design and initial implementation period, with a number of documents recording the changes (see [RFC819], [RFC830], and [RFC1034]).
ホストテーブルのアプローチを使用して数年後、コミュニティは、モデルが十分に拡張しなかったことと、それが適切に新しいサービスのバリエーションをサポートしていないだろうと結論付けました。議論や会議の数は、一緒にいくつかのアイデアや不完全な提案を描いた開催されました。 DNSは、その努力の結果でした。これは、変更を記録する文書の数（[RFC819]、[RFC830]、および[RFC1034]を参照）を用いて、設計初期実装期間中に進化し続けました。
The goals for the DNS included:
DNSの目標が含まれます：
o Preservation of the capabilities of the host table arrangements (especially unique, unambiguous, host names),
Oホストテーブルアレンジメントの能力（特にユニークな、明確な、ホスト名）の保存、
o Provision for addition of additional services (e.g., the special record types for electronic mail routing which quickly followed introduction of the DNS), and
追加サービス（例えば、すぐにDNSの導入を踏襲し、電子メールのルーティングのための特別なレコードタイプ）を追加するためのOの提供、および
o Creation of a robust, hierarchical, distributed, name lookup system to accomplish the other goals.
O堅牢、階層、分散、名前検索システムの作成は、他の目標を達成します。
The DNS design also permitted distribution of name administration, rather than requiring that each host be entered into a single, central, table by a central administration.
DNS設計もむしろ各ホストを集中管理することにより、単一の、中央のテーブルに入力することを要求するよりも、名前投与の分布を可能にしました。
The DNS was designed to identify network resources. Although there was speculation about including, e.g., personal names and email addresses, it was not designed primarily to identify people, brands, etc. At the same time, the system was designed with the flexibility to accommodate new data types and structures, both through the addition of new record types to the initial "INternet" class, and, potentially, through the introduction of new classes. Since the appropriate identifiers and content of those future extensions could not be anticipated, the design provided that these fields could contain any (binary) information, not just the restricted text forms of the host table.
DNSは、ネットワークリソースを識別するために設計されました。例えば、個人の名前や電子メールアドレスなどの憶測があったが、それは同時になど、人々、ブランドを識別するために主に設計されていないと、システムは通過の両方、新しいデータ型や構造に適応するように柔軟に設計されました新しいクラスの導入による潜在的初期「インターネット」クラスに新しいレコードタイプの追加、および、、。適切な識別子と、それらの将来の拡張の内容は予想できなかったので、デザインは、これらのフィールドは、ホストテーブルの制限されたテキスト形式だけでなく、を任意の（バイナリ）の情報を含むことができることを提供します。
However, the DNS, as it is actually used, is intimately tied to the applications and application protocols that utilize it, often at a fairly low level.
しかし、DNSは、それが実際に使用されるよう、密接しばしばかなり低いレベルで、それを利用するアプリケーションやアプリケーションプロトコルに関連付けられています。
In particular, despite the ability of the protocols and data structures themselves to accommodate any binary representation, DNS names as used were historically not even unrestricted ASCII, but a very restricted subset of it, a subset that derives from the original host table naming rules. Selection of that subset was driven in part by human factors considerations, including a desire to eliminate possible ambiguities in an international context. Hence character codes that had international variations in interpretation were excluded, the underscore character and case distinctions were eliminated as being confusing (in the underscore's case, with the hyphen character) when written or read by people, and so on. These considerations appear to be very similar to those that resulted in similarly restricted character sets being used as protocol elements in many ITU and ISO protocols (cf. [X29]).
具体的には、プロトコルやデータ構造の能力にもかかわらず、それ自体はバイナリ表現に対応するために、使用されるDNS名は歴史的にもない無制限のASCIIが、それは非常に制限されたサブセット、命名規則、元のホストテーブルから派生したサブセットでした。そのサブセットの選択は、国際的な文脈での可能な曖昧さを排除する欲求を含むヒトの要因の考慮によって部分的に駆動されました。したがって、解釈の国際バリエーションを持っていた文字コードを除外した、下線文字とケース区別がように読み書き人々によって、そしてとき（アンダースコアの場合は、ハイフン文字で）混乱であるとして排除されました。これらの考察は、同様に制限された文字セットをもたらしたもの多くのITUおよびISOプロトコルにプロトコル要素として使用されている（参照[X29]）と非常に類似して見えます。
Another assumption was that there would be a high ratio of physical hosts to second level domains and, more generally, that the system would be deeply hierarchical, with most systems (and names) at the third level or below and a very large percentage of the total names representing physical hosts. There are domains that follow this model: many university and corporate domains use fairly deep hierarchies, as do a few country-oriented top level domains ("ccTLDs"). Historically, the "US." domain has been an excellent example of the deeply hierarchical approach. However, by 1998, comparison of several efforts to survey the DNS showed a count of SOA records that approached (and may have passed) the number of distinct hosts. Looked at differently, we appear to be moving toward a situation in which the number of delegated domains on the Internet is approaching or exceeding the number of hosts, or at least the number of hosts able to provide services to others on the network. This presumably results from synonyms or aliases that map a great many names onto a smaller number of hosts. While experience up to this time has shown that the DNS is robust enough -- given contemporary machines as servers and current bandwidth norms -- to be able to continue to operate reasonably well when those historical assumptions are not met (e.g., with a flat, structure under ".COM" containing well over ten million delegated subdomains [COMSIZE]), it is still useful to remember that the system could have been designed to work optimally with a flat structure (and very large zones) rather than a deeply hierarchical one, and was not.
別の仮定は、システムは、ほとんどのシステム（および名前）第3レベル以下での非常に大きな割合で、深く階層であろうことを、より一般的にセカンドレベルドメインと、に物理ホストの高い比率が存在するであろうということでした物理ホストを表す合計の名前。このモデルに従うドメインがありますいくつかの国指向のトップレベルドメイン（「のccTLD」）がそうであるように、多くの大学や企業のドメインは、かなり深い階層を使用しています。歴史的に、「米国の。」ドメインは、深い階層的アプローチの優れた例となっています。しかし、1998年、DNSを調査するためにいくつかの努力の比較が近づい（と合格している可能性があり）個別のホストの数をSOAレコードの数を示しました。異なって見え、我々はインターネット上の委任ドメインの数が近づいまたはホストの数を上回る、またはネットワーク上の他の人にサービスを提供できるホストの少なくとも数されている状況に向かって動いているように見えます。これは、おそらくホストの数が少ない上に、非常に多くの名をマップ同義語やエイリアスに起因します。サーバおよび現在の帯域幅の規範として、現代のマシンを与えられた - - この時点までの経験では、DNSは十分に堅牢であることを示しているが、これらの歴史的な仮定は、平らで、（例えば満たされていない時に、合理的にうまく動作し続けることができるように優に超える千万委任サブドメイン[COMSIZE]を含む「.COM」）の下の構造が、まだシステムがフラット構造（と、非常に大きなゾーン）のではなく、深く、階層1で最適に動作するように設計されている可能性があることを覚えてするのに便利です、そしてませんでした。
Similarly, despite some early speculation about entering people's names and email addresses into the DNS directly (e.g., see [RFC1034]), electronic mail addresses in the Internet have preserved the original, pre-DNS, "user (or mailbox) at location" conceptual format rather than a flatter or strictly dot-separated one. Location, in that instance, is a reference to a host. The sole exception, at least in the "IN" class, has been one field of the SOA record.
同様に、（例えば、[RFC1034]を参照）を直接DNSに人の名前とメールアドレスを入力することについてのいくつかの初期の憶測もかかわらず、インターネットの電子メールアドレスは、「場所で、ユーザー（またはメールボックス）」の元、事前にDNSを、保存されています概念的なフォーマットではなく、平坦な又は厳密にドットで区切られた1。場所は、そのインスタンスで、ホストへの参照です。唯一の例外は、少なくとも「IN」クラスでは、SOAレコードの一つのフィールドとなっています。
Both the DNS architecture itself and the two-level (host name and mailbox name) provisions for email and similar functions (e.g., see the finger protocol [FINGER]), also anticipated a relatively high ratio of users to actual hosts. Despite the observation in RFC 1034 that the DNS was expected to grow to be proportional to the number of users (section 2.3), it has never been clear that the DNS was seriously designed for, or could, scale to the order of magnitude of number of users (or, more recently, products or document objects), rather than that of physical hosts.
DNSアーキテクチャ自体や電子メールと同様の機能のための2つのレベル（ホスト名とメールボックス名）の規定（例えば、指プロトコル[FINGER]を参照）の両方が、また、実際のホストへのユーザーの比較的高い割合を期待しました。 DNSは、ユーザー（セクション2.3）の数に比例するように成長すると予想されたことをRFC 1034での観察にもかかわらず、DNSを真剣数の大きさの順に、スケールをするために設計された、またはでしたことは明らかではありませんでしたユーザー（または、より最近では、製品または文書オブジェクト）のではなく、物理ホストのそれよりも。
Just as was the case for the host table before it, the DNS provided critical uniqueness for names, and universal accessibility to them, as part of overall "single internet" and "end to end" models (cf.
ホストテーブルの場合には、その前にいたのと同じように、DNSは、全体的に「単一のインターネット」と「エンドツーエンド」のモデル（参照の一部として、それらに名前のために重要な独自性、およびユニバーサルアクセスを提供しました
[RFC2826]). However, there are many signs that, as new uses evolved and original assumptions were abused (if not violated outright), the system was being stretched to, or beyond, its practical limits.
[RFC2826]）。しかし、新たな用途が進化し、（あからさまな違反していない場合）、元の仮定が虐待を受けたとして、多くの兆候があり、システムは、その実用的な限界にまで伸長、またはを超えていました。
The original design effort that led to the DNS included examination of the directory technologies available at the time. The design group concluded that the DNS design, with its simplifying assumptions and restricted capabilities, would be feasible to deploy and make adequately robust, which the more comprehensive directory approaches were not. At the same time, some of the participants feared that the limitations might cause future problems; this document essentially takes the position that they were probably correct. On the other hand, directory technology and implementations have evolved significantly in the ensuing years: it may be time to revisit the assumptions, either in the context of the two- (or more) level mechanism contemplated by the rest of this document or, even more radically, as a path toward a DNS replacement.
DNSにつながったオリジナルデザインの努力は、現時点で入手可能なディレクトリ技術の検査が含まれています。デザイングループは、その前提を単純化し、制限された機能を備えたDNSの設計は、展開、およびより包括的なディレクトリのアプローチがされなかった、十分に堅牢にすることは可能であろうと結論付けました。同時に、参加者の一部は制限が将来の問題を引き起こす可能性が懸念しました。この文書では、基本的に彼らはおそらく正しかったという立場をとります。一方、ディレクトリ技術と実装はその後数年で大幅に進化している：どちらか、二（またはそれ以上）の文脈では、仮定を再検討するために時間がかかるかもしれないでもレベルこの文書の残りの部分によって意図機構や、以上のラジカル、DNS交換に向かってパスとして。
From the standpoint of the integrity of the domain name system -- and scaling of the Internet, including optimal accessibility to content -- the web design decision to use "A record" domain names directly in URLs, rather than some system of indirection, has proven to be a serious mistake in several respects. Convenience of typing, and the desire to make domain names out of easily-remembered product names, has led to a flattening of the DNS, with many people now perceiving that second-level names under COM (or in some countries, second- or third-level names under the relevant ccTLD) are all that is meaningful. This perception has been reinforced by some domain name registrars [REGISTRAR] who have been anxious to "sell" additional names. And, of course, the perception that one needed a second-level (or even top-level) domain per product, rather than having names associated with a (usually organizational) collection of network resources, has led to a rapid acceleration in the number of names being registered. That acceleration has, in turn, clearly benefited registrars charging on a per-name basis, "cybersquatters", and others in the business of "selling" names, but it has not obviously benefited the Internet as a whole.
最適なコンテンツへのアクセスを含め、インターネットのスケーリング、 - - ドメインネームシステムの整合性の観点からではなく間接のいくつかのシステムよりも、URLで直接「記録」のドメイン名を使用するには、Webデザインの決定、持っていますいくつかの点で重大なミスであることが証明。タイピングの利便性、そして簡単に覚えの製品名のうち、ドメイン名を作る願望は、多くの人々が今ではCOMの下の2番目のレベルの名前（またはいくつかの国では、2次または第三の知覚と、DNSの平坦化につながっています関連するccTLDの下のレベルの名前は）意味のあるものすべてです。この認識は、追加の名前を「売る」ことを切望していたいくつかのレジストラ[REGISTRAR]によって強化されています。そして、もちろん、1ではなく、ネットワークリソースの（通常は組織）のコレクションに関連付けられた名前を持つよりも、製品ごとのドメイン、セカンドレベル（あるいはトップレベルの）必要という認識は、数の急速な加速につながっています名前で登録されています。その加速度は、今度は、はっきりと「売り」の名前の業務にあたり、名前ベースで充電、レジストラ、「cybersquatters」、およびその他の恩恵を受けているが、それは明らかに、全体としてインターネットを恩恵を受けていません。
This emphasis on second-level domain names has also created a problem for the trademark community. Since the Internet is international, and names are being populated in a flat and unqualified space, similarly-named entities are in conflict even if there would ordinarily be no chance of confusing them in the marketplace. The problem appears to be unsolvable except by a choice between draconian measures. These might include significant changes to the legislation and conventions that govern disputes over "names" and "marks". Or they might result in a situation in which the "rights" to a name are typically not settled using the subtle and traditional product (or industry) type and geopolitical scope rules of the trademark system. Instead they have depended largely on political or economic power, e.g., the organization with the greatest resources to invest in defending (or attacking) names will ultimately win out. The latter raises not only important issues of equity, but also the risk of backlash as the numerous small players are forced to relinquish names they find attractive and to adopt less-desirable naming conventions.
セカンドレベルドメイン名のこの重点はまた、商標コミュニティのための問題を作成しました。インターネットは国際的で、かつ名前が平らで修飾されていないスペースに移入されているので、同じ名前のエンティティは、通常、市場でそれらを混乱の見込みはないだろうしても対立しています。問題は、厳格な措置の間で選択する以外に解決不可能なように見えます。これらは、「名前」と「マーク」をめぐる紛争を支配する重要な法律への変更と規則が含まれる場合があります。それとも、名前に「権利」とは一般的に微妙な、伝統的な製品（または業界）タイプと商標制度の地政学的なスコープ規則を使用して定住されていない状況になる可能性があります。代わりに、彼らは政治や経済力に大きく依存してきた、例えば、防御（または攻撃）に投資する最大のリソースを持つ組織の名前は、最終的には勝つだろう。多数の小さな選手たちは、彼らが魅力を感じるとあまり望ましい命名規則を採用する名前を放棄することを余儀なくされているとして、後者は重要な資本の問題でなく、バックラッシュのリスクだけでなく、発生します。
Independent of these sociopolitical problems, content distribution issues have made it clear that it should be possible for an organization to have copies of data it wishes to make available distributed around the network, with a user who asks for the information by name getting the topologically-closest copy. This is not possible with simple, as-designed, use of the DNS: DNS names identify target resources or, in the case of email "MX" records, a preferentially-ordered list of resources "closest" to a target (not to the source/user). Several technologies (and, in some cases, corresponding business models) have arisen to work around these problems, including intercepting and altering DNS requests so as to point to other locations.
これらの社会政治的な問題とは無関係に、コンテンツ配信の問題は、それが明確な組織がtopologically-を取得し、名前で情報を要求するユーザーと、それが利用可能なネットワークの周囲に分布行いたいデータのコピーを持ってすることが可能であることを行っています最寄りのコピー。設計されたように、これは、シンプルでは不可能である、DNSの使用：DNS名はターゲットに（しないように「最も近い」、電子メール「MX」レコードの場合には、リソースの優先順のリストをターゲットリソースを識別したり、ソース/ユーザー）。いくつかの技術（および、場合によっては、対応するビジネスモデル）が他の場所を指すようにDNS要求を傍受し、変更することを含め、これらの問題を回避するために生じています。
Additional implications are still being discovered and evaluated.
追加の意味合いは、まだ発見され、評価されています。
Approaches that involve interception of DNS queries and rewriting of DNS names (or otherwise altering the resolution process based on the topological location of the user) seem, however, to risk disrupting end-to-end applications in the general case and raise many of the issues discussed by the IAB in [IAB-OPES]. These problems occur even if the rewriting machinery is accompanied by additional workarounds for particular applications. For example, security associations and applications that need to identify "the same host" often run into problems if DNS names or other references are changed in the network without participation of the applications that are trying to invoke the associated services.
DNSクエリの傍受を伴い、（ユーザの位相的な位置に基づいて、解決プロセスを変更するか、そうでなければ）DNS名の書き換え思われるアプローチは、しかし、一般的な場合にエンド・ツー・エンドのアプリケーションを中断リスクとの多くを上昇させます[IAB-OPES]にIABによって議論された問題。これらの問題は、書き換え機械が特定のアプリケーションのための追加的な回避策を伴っている場合にも発生します。 DNS名または他の文献は、関連するサービスを呼び出すためにしようとしているアプリケーションの参加なしにネットワークに変更された場合たとえば、「同一ホスト」を特定する必要があるセキュリティアソシエーションおよびアプリケーションは、しばしば問題に実行します。
At the applications level, few of the protocols in active, widespread, use on the Internet reflect either contemporary knowledge in computer science or human factors or experience accumulated through deployment and use. Instead, protocols tend to be deployed at a just-past-prototype level, typically including the types of expedient compromises typical with prototypes. If they prove useful, the nature of the network permits very rapid dissemination (i.e., they fill a vacuum, even if a vacuum that no one previously knew existed). But, once the vacuum is filled, the installed base provides its own inertia: unless the design is so seriously faulty as to prevent effective use (or there is a widely-perceived sense of impending disaster unless the protocol is replaced), future developments must maintain backward compatibility and workarounds for problematic characteristics rather than benefiting from redesign in the light of experience. Applications that are "almost good enough" prevent development and deployment of high-quality replacements.
アプリケーションレベルでは、インターネット上で使用し、広範囲に、アクティブでプロトコルのいくつかは、コンピュータサイエンスの現代的な知識や展開と使用を通じて蓄積人的要因や経験のいずれかを反映しています。その代わり、プロトコルは、一般的にプロトタイプを持つ典型的な方便妥協の種類を含め、ジャスト・過去・プロトタイプレベルで展開される傾向があります。彼らは有用であることを証明した場合は、ネットワークの性質が許せば非常に急速な普及（すなわち、彼らは真空誰も以前に存在しなかったことを知っていた場合でも、空白を埋めます）。しかし、真空が満たされたら、インストールベースが自身の慣性を提供しています。デザインは効果的な使用を防止するように真剣に欠陥がある場合を除き（またはプロトコルが交換されない限り、差し迫った災害の広く認識される感覚がある）、将来の発展しなければなりませんむしろ経験に照らして再設計の恩恵を受けるより問題の特性のための後方互換性と回避策を維持します。 「十分にほとんど良い」されたアプリケーションは、高品質な代替品の開発と展開を防ぎます。
The DNS is both an illustration of, and an exception to, parts of this pessimistic interpretation. It was a second-generation development, with the host table system being seen as at the end of its useful life. There was a serious attempt made to reflect the computing state of the art at the time. However, deployment was much slower than expected (and very painful for many sites) and some fixed (although relaxed several times) deadlines from a central network administration were necessary for deployment to occur at all. Replacing it now, in order to add functionality, while it continues to perform its core functions at least reasonably well, would presumably be extremely difficult.
DNSは、例示、この悲観的解釈の部分、例外もあります。これは、耐用年数の終了時のように見られるホストテーブルシステムと、第二世代の開発でした。一度芸術のコンピューティング状態を反映するために作られた深刻な試みがありました。しかし、展開が予想よりもはるかに遅い（と多くのサイトのための非常に苦痛）としたいくつかの固定展開がまったく発生するため、中央ネットワーク管理から（リラックスした数回が）期限が必要でした。今それを交換する、それが合理的に、少なくともそのコア機能を実行するために続けている間、機能を追加するためには、おそらく非常に困難であろう。
There are many, perhaps obvious, examples of this. Despite many known deficiencies and weaknesses of definition, the "finger" and "whois" [WHOIS] protocols have not been replaced (despite many efforts to update or replace the latter [WHOIS-UPDATE]). The Telnet protocol and its many options drove out the SUPDUP [RFC734] one, which was arguably much better designed for a diverse collection of network hosts. A number of efforts to replace the email or file transfer protocols with models which their advocates considered much better have failed. And, more recently and below the applications level, there is some reason to believe that this resistance to change has been one of the factors impeding IPv6 deployment.
これは、おそらく明らかに、多くの例があります。多くの既知の欠陥および定義の弱さにもかかわらず、「指」と「WHOIS」[WHOIS]プロトコルが交換されていない（後者[WHOIS-UPDATE]を更新または交換するために多くの努力にもかかわらず）。 Telnetプロトコルとその多くのオプションが間違いなくはるかに優れたネットワークホストの多様なコレクションのために設計されたSUPDUP [RFC734] 1を、追い出しました。彼らの支持者は、はるかに良いと考えられたモデルで、電子メールやファイル転送プロトコルを置き換えるために多くの努力が失敗しています。そして、最近でアプリケーションレベルの下、変更するには、この抵抗がIPv6の展開を妨げる要因の一つとなっていることを信じるためにいくつかの理由があります。
Parts of the historical discussion above identify areas in which the DNS has become overloaded (semantically if not in the mechanical ability to resolve names). Despite this overloading, it appears that DNS performance and reliability are still within an acceptable range: there is little evidence of serious performance degradation. Recent proposals and mechanisms to better respond to overloading and scaling issues have all focused on patching or working around limitations that develop when the DNS is utilized for out-of-design functions, rather than on dramatic rethinking of either DNS design or those uses. The number of these issues that have arisen at much the same time may argue for just that type of rethinking, and not just for adding complexity and attempting to incrementally alter the design (see, for example, the discussion of simplicity in section 2 of [RFC3439]).
歴史的説明の部分は、上記（意味的に名前を解決するための機械的能力のない場合）DNSが過負荷となったの領域を特定します。深刻なパフォーマンスの低下の証拠はほとんどない。このオーバーロードにもかかわらず、DNSのパフォーマンスと信頼性が許容範囲内に残っていることが表示されます。より良い問題をオーバーロードし、スケーリングに対応するための最近の提案とメカニズムは、すべてのDNSがアウト・オブ・デザイン機能に利用されたときに開発制限を回避パッチ適用や作業に焦点を当てたのではなく、DNSの設計や、それらの用途のいずれかの劇的な再考にしています。ほぼ同じ時刻に発生したこれらの問題の数は再考のちょうどそのタイプのためだけではなく、複雑さを追加し、インクリメンタルデザインを変更しようとするために主張すること（[、例えば、2節では、簡単の説明を参照してくださいRFC3439]）。
For example:
例えば：
o While technical approaches such as larger and higher-powered servers and more bandwidth, and legal/political mechanisms such as dispute resolution policies, have arguably kept the problems from becoming critical, the DNS has not proven adequately responsive to business and individual needs to describe or identify things (such as product names and names of individuals) other than strict network resources.
このように大きいとより高性能サーバやより多くの帯域幅、および、そのような紛争解決の方針として法的/政治的メカニズムなどの技術的なアプローチは、間違いなく重要になってから問題を保持しているが、O、DNSは、記述するために、ビジネスや個人のニーズに適切に対応し証明されていませんまたは厳格なネットワークリソース以外（そのような個人の製品名や名前など）のものを識別します。
o While stacks have been modified to better handle multiple addresses on a physical interface and some protocols have been extended to include DNS names for determining context, the DNS does not deal especially well with many names associated with a given host (e.g., web hosting facilities with multiple domains on a server).
Oスタックは、より良い物理インターフェイス上で複数のアドレスを処理するように変更され、いくつかのプロトコルは、コンテキストを決定するためのDNS名を含むように拡張されてきたが、DNSは、特定のホスト（例えば、ウェブホスティング施設に関連した多くの名前で特によく対処していません）サーバー上に複数のドメインを持ちます。
o Efforts to add names deriving from languages or character sets based on other than simple ASCII and English-like names (see below), or even to utilize complex company or product names without the use of hierarchy, have created apparent requirements for names (labels) that are over 63 octets long. This requirement will undoubtedly increase over time; while there are workarounds to accommodate longer names, they impose their own restrictions and cause their own problems.
O階層を使用せずに、複雑な会社名や製品名を利用するとしても、単純なASCIIと英語のような名前以外に基づいて、言語や文字セットから派生名を追加するための努力（下記参照）、または、名の見かけ上の要件（ラベルを作成しました）長い63個のオクテットを超えているという。この要件は、間違いなく時間の経過とともに増加します。長い名前に対応するための回避策がありますが、彼らは自分の制限を課し、自分の問題を引き起こします。
o Increasing commercialization of the Internet, and visibility of domain names that are assumed to match names of companies or products, has turned the DNS and DNS names into a trademark battleground. The traditional trademark system in (at least) most countries makes careful distinctions about fields of applicability. When the space is flattened, without differentiation by either geography or industry sector, not only are there likely conflicts between "Joe's Pizza" (of Boston) and "Joe's Pizza" (of San Francisco) but between both and "Joe's Auto Repair" (of Los Angeles). All three would like to control "Joes.com" (and would prefer, if it were permitted by DNS naming rules, to also spell it as "Joe's.com" and have both resolve the same way) and may claim trademark rights to do so, even though conflict or confusion would not occur with traditional trademark principles.
インターネットの商用化、および企業や製品の名前と一致すると仮定されているドメイン名の可視性を増やすO、商標戦場にDNSおよびDNS名になっています。 （少なくとも）ほとんどの国の伝統的な商標制度は適用の分野について慎重に区別します。スペースが平坦化されると、地理や産業部門のいずれかによって区別せずに、だけではなく（ボストン）「ジョーのピザ」と「ジョーのピザ」（サンフランシスコの）間が、「Joeの自動修復」の両方の間に、おそらく競合が（ありますロサンゼルスの）。すべての3つは、「Joes.com」を制御したいと思います（と希望、それはDNSの命名規則により許可された場合、また「Joe's.com」として、それをスペルと同じように、両方持って解決に）と行うための商標権を主張することができますそう、紛争や混乱は、伝統的な商標の原則では発生しませんにもかかわらず。
o Many organizations wish to have different web sites under the same URL and domain name. Sometimes this is to create local variations -- the Widget Company might want to present different material to a UK user relative to a US one -- and sometimes it is to provide higher performance by supplying information from the server topologically closest to the user. If the name resolution mechanism is expected to provide this functionality, there are three possible models (which might be combined):
O多くの組織が同じURLとドメイン名の下に別のWebサイトを持つことを望みます。時には、これは地元のバリエーションを作成することです - ウィジェット当社は、米国の1に英国のユーザーの相対的に異なる材料を提示することができます - そして時にはそれがユーザーに位相幾何学的に最も近いサーバからの情報を供給することによって、より高いパフォーマンスを提供することです。名前解決機構は、この機能を提供することが期待されている場合は、（組み合わせることもあります）三つの可能なモデルがあります：
- supply information about multiple sites (or locations or references). Those sites would, in turn, provide information associated with the name and sufficient site-specific attributes to permit the application to make a sensible choice of destination, or
- 複数のサイト（または場所または参照）に関する情報を提供します。これらのサイトは、順番に、目的地の賢明な選択をするアプリケーションを可能にするために、名前と十分なサイト固有の属性に関連する情報を提供する、または
- accept client-site attributes and utilize them in the search process, or
- クライアントサイトの属性を受け入れ、検索処理でそれらを利用、または
- return different answers based on the location or identity of the requestor.
- 要求者の位置やアイデンティティに基づいて異なった答えを返します。
While there are some tricks that can provide partial simulations of these types of function, DNS responses cannot be reliably conditioned in this way.
機能これらのタイプの部分的なシミュレーションを提供することができますいくつかのトリックがありますが、DNS応答は確実に、このように調整することができません。
These, and similar, issues of performance or content choices can, of course, be thought of as not involving the DNS at all. For example, the commonly-cited alternate approach of coupling these issues to HTTP content negotiation (cf. [RFC2295]), requires that an HTTP connection first be opened to some "common" or "primary" host so that preferences can be negotiated and then the client redirected or sent alternate data. At least from the standpoint of improving performance by accessing a "closer" location, both initially and thereafter, this approach sacrifices the desired result before the client initiates any action. It could even be argued that some of the characteristics of common content negotiation approaches are workarounds for the non-optimal use of the DNS in web URLs.
これらの、および同様、パフォーマンスやコンテンツの選択の問題は、もちろん、などすべてのDNSが関与しないと考えることができます。例えばHTTPコンテンツネゴシエーション（参照[RFC2295]）にこれらの問題を結合する、一般に引用代替アプローチ、嗜好をネゴシエートできるようにHTTP接続が最初にいくつかの「共通」または「一次」ホストに開放されることを必要とその後、クライアントは、リダイレクトまたは代替データを送りました。クライアントは、任意のアクションを開始する前に、両方の最初とその後、「近い」位置にアクセスすることによって性能を向上させる観点から、少なくとも、このアプローチは、所望の結果を犠牲にします。それも、共通のコンテンツネゴシエーションのアプローチの特徴のいくつかは、ウェブのURLでDNSの非最適な使用のための回避策であることを主張することができます。
o Many existing and proposed systems for "finding things on the Internet" require a true search capability in which near matches can be reported to the user (or to some user agent with an appropriate rule-set) and to which queries may be ambiguous or fuzzy. The DNS, by contrast, can accommodate only one set of (quite rigid) matching rules. Proposals to permit different rules in different localities (e.g., matching rules that are TLD- or zone-specific) help to identify the problem. But they cannot be applied directly to the DNS without either abandoning the desired level of flexibility or isolating different parts of the Internet from each other (or both). Fuzzy or ambiguous searches are desirable for resolution of names that might have spelling variations and for names that can be resolved into different sets of glyphs depending on context. Especially when internationalization is considered, variant name problems go beyond simple differences in representation of a character or ordering of a string. Instead, avoiding user astonishment and confusion requires consideration of relationships such as languages that can be written with different alphabets, Kanji-Hiragana relationships, Simplified and Traditional Chinese, etc. See [Seng] for a discussion and suggestions for addressing a subset of these issues in the context of characters based on Chinese ones. But that document essentially illustrates the difficulty of providing the type of flexible matching that would be anticipated by users; instead, it tries to protect against the worst types of confusion (and opportunities for fraud).
O多くの既存のと近い試合をユーザーに報告することができる真の検索機能を必要とし、「インターネット上のものを見つける」ためのシステムを提案している（または適切なルールセットを持ついくつかのユーザーエージェント）との曖昧かもしれ照会していますかファジー。 DNSは、対照的に、ルールに一致する（かなり剛性）の一組のみを収容することができます。異なる地域で異なるルールを可能にする提案（TLD-またはゾーン固有である例えば、マッチングルールは）問題を識別するのに役立ちます。しかし、彼らは柔軟性の所望のレベルを放棄または互いに（または両方）からインターネットの異なる部分を分離することなく、いずれかのDNSに直接適用することはできません。ファジーまたは曖昧検索は、スペルのバリエーションを持っているし、コンテキストに応じてグリフの異なるセットに分割することができる名の可能性がある名前の解決のために望ましいものです。国際化を考慮した場合、特に、バリアント名の問題は、文字列の文字または順序の表現で簡単な違いを越えて行きます。代わりに、利用者の驚きと混乱を回避することは、これらの問題の一部に対処するための議論や提案を[セン]を参照してくださいなど異なるアルファベット、漢字、ひらがな関係、簡体字中国語、繁体字中国語、と書くことができるような言語としての関係を考慮する必要が中国のものに基づいて、文字のコンテキストインチしかし、その文書では、基本的にユーザーが予期されるフレキシブルマッチングのタイプを提供することの難しさを示しています。代わりに、それは（詐欺や機会）最悪の混乱の種類から保護しようとします。
o The historical DNS, and applications that make assumptions about how it works, impose significant risk (or forces technical kludges and consequent odd restrictions), when one considers adding mechanisms for use with various multi-character-set and multilingual "internationalization" systems. See the IAB's discussion of some of these issues [RFC2825] for more information.
歴史的なDNS O、およびそれがどのように機能するかについての仮定を行うアプリケーションでは、1は、様々なマルチ文字セットと多言語の「国際化」のシステムで使用するためのメカニズムを追加することを考えると、大きなリスク（または力、技術クラッジとその結果として奇数の制限）を課します。詳細については、これらの問題[RFC2825]の一部のIABの説明を参照してください。
o In order to provide proper functionality to the Internet, the DNS must have a single unique root (the IAB provides more discussion of this issue [RFC2826]). There are many desires for local treatment of names or character sets that cannot be accommodated without either multiple roots (e.g., a separate root for multilingual names, proposed at various times by MINC [MINC] and others), or mechanisms that would have similar effects in terms of Internet fragmentation and isolation.
O、インターネットへの適切な機能を提供するために、DNSは（IABは、この問題のより多くの議論[RFC2826]を提供）単一のユニークなルートを持っている必要があります。 （例えば、MINC [MINC]と他の人が様々な時間に提案し、多言語名の別のルート、）複数のルートのいずれかなしに収容することができません名前や文字セットの局所治療、または同様の効果を持っているでしょうメカニズムの多くの欲望がありますインターネットの断片化と分離の観点インチ
o For some purposes, it is desirable to be able to search not only an index entry (labels or fully-qualified names in the DNS case), but their values or targets (DNS data). One might, for example, want to locate all of the host (and virtual host) names which cause mail to be directed to a given server via MX records. The DNS does not support this capability (see the discussion in [IQUERY]) and it can be simulated only by extracting all of the relevant records (perhaps by zone transfer if the source permits doing so, but that permission is becoming less frequently available) and then searching a file built from those records.
Oいくつかの目的のために、それだけではなく、インデックスエントリ（DNSケース内のラベルまたは完全修飾名）を検索することができることが望ましいが、その値または目標（DNSデータ）。一つは、例えば、ホスト（仮想ホスト）メールはMXレコードを経由して特定のサーバーに向けることになり名前のすべてを検索する場合があります。 DNSは、この機能をサポートしていません（[IQUERY]での議論を参照）、それだけで、関連するすべてのレコードを抽出することによってシミュレートすることができます（ソース許可がそうするならば、おそらくゾーン転送ではなく、その権限はそれほど頻繁に利用可能となってきています）その後、それらのレコードから作成されたファイルを検索します。
o Finally, as additional types of personal or identifying information are added to the DNS, issues arise with protection of that information. There are increasing calls to make different information available based on the credentials and authorization of the source of the inquiry. As with information keyed to site locations or proximity (as discussed above), the DNS protocols make providing these differentiated services quite difficult if not impossible.
個人または識別情報の追加タイプがDNSに追加されるO最後に、問題は、その情報の保護を生じます。問い合わせ元の資格情報と承認に基づいてさまざまな情報を利用できるようにする上げる呼び出しがあります。サイトの場所または近接するキー情報（上述したように）と同様に、DNSプロトコルは非常に困難不可能ではないこれらの差別化されたサービスを提供します。
In each of these cases, it is, or might be, possible to devise ways to trick the DNS system into supporting mechanisms that were not designed into it. Several ingenious solutions have been proposed in many of these areas already, and some have been deployed into the marketplace with some success. But the price of each of these changes is added complexity and, with it, added risk of unexpected and destabilizing problems.
これらの場合の各々において、それは、または、それに設計されていないメカニズムをサポートするにDNSシステムをだますための方法を考案することが可能かもしれません。いくつかの独創的なソリューションは、すでにこれらの分野の多くで提案されており、一部はある程度の成功を収めて市場に展開されています。しかし、これらの変化のそれぞれの価格は複雑さを追加して、それをされ、予期しないと不安定化の問題のリスクを追加しました。
Several of the above problems are addressed well by a good directory system (supported by the LDAP protocol or some protocol more precisely suited to these specific applications) or searching environment (such as common web search engines) although not by the DNS. Given the difficulty of deploying new applications discussed above, an important question is whether the tricks and kludges are bad enough, or will become bad enough as usage grows, that new solutions are needed and can be deployed.
ていないが、上記の問題のいくつかは、DNSで（LDAPプロトコルまたはより正確には、これらの特定の用途に適したいくつかのプロトコルでサポートされている）良いディレクトリシステムや（などの一般的なウェブ検索エンジンなど）を検索環境によってうまく対処しています。上記の新しいアプリケーションを導入することの難しさを考えると、重要な問題は、トリックやクラッジは十分に悪い、または利用が大きくなるにつれて、新たなソリューションが必要とされており、展開することができることを、十分に悪いになりますかどうかです。
The constraints of the DNS and the discussion above suggest the introduction of an intermediate protocol mechanism, referred to below as a "search layer" or "searchable system". The terms "directory" and "directory system" are used interchangeably with "searchable system" in this document, although the latter is far more precise. Search layer proposals would use a two (or more) stage lookup, not unlike several of the proposals for internationalized names in the DNS (see section 4), but all operations but the final one would involve searching other systems, rather than looking up identifiers in the DNS itself. As explained below, this would permit relaxation of several constraints, leading to a more capable and comprehensive overall system.
DNSと議論の制約は、上記の「サーチ層」または「検索システム」と称し、中間プロトコルメカニズムの導入を示唆しています。後者ははるかに正確であるが、用語「ディレクトリ」と「ディレクトリシステム」は、この文書の「検索可能なシステム」と同義的に使用されています。検索層の提案（セクション4を参照）ではないDNSにおける国際化の名前のための提案のいくつかとは異なり、2つ（またはそれ以上）のステージのルックアップを使用しますが、すべての操作が、最終的な一つは、他のシステムを検索するのではなく、識別子を見上げ伴うだろうDNS自体インチ以下に説明するように、これはより有能かつ包括的なシステム全体につながる、いくつかの制約の緩和を可能にします。
Ultimately, many of the issues with domain names arise as the result of efforts to use the DNS as a directory. While, at the time this document was written, sufficient pressure or demand had not occurred to justify a change, it was already quite clear that, as a directory system, the DNS is a good deal less than ideal. This document suggests that there actually is a requirement for a directory system, and that the right solution to a searchable system requirement is a searchable system, not a series of DNS patches, kludges, or workarounds.
最終的には、ドメイン名を持つ問題の多くは、ディレクトリとしてDNSを使用するための努力の結果として生じます。 、この文書が書かれた時点で、十分な圧力や需要が変更を正当化するために発生していなかったが、ディレクトリシステムとして、DNSが理想よりかなり小さい、というすでにかなり明らかでした。この文書では、実際には、ディレクトリシステムのための要件があること、および検索可能なシステム要件に適切なソリューションを検索可能なシステムではなく、DNSのパッチ、クラッジ、または回避策のシリーズであることを示唆しています。
The following points illustrate particular aspects of this conclusion.
次のポイントは、この結論の特定の態様を例示します。
o A directory system would not require imposition of particular length limits on names.
Oディレクトリシステムは、名前の特定の長さの制限を課すことを必要としません。
o A directory system could permit explicit association of attributes, e.g., language and country, with a name, without having to utilize trick encodings to incorporate that information in DNS labels (or creating artificial hierarchy for doing so).
Oディレクトリシステムは、DNSラベルにその情報を組み込むためにトリックエンコーディングを利用すること（あるいはそうするために人工的な階層を作成）せずに、名前と属性の明確な関連性、例えば、言語と国を、許可することができます。
o There is considerable experience (albeit not much of it very successful) in doing fuzzy and "sonex" (similar-sounding) matching in directory systems. Moreover, it is plausible to think about different matching rules for different areas and sets of names so that these can be adapted to local cultural requirements. Specifically, it might be possible to have a single form of a name in a directory, but to have great flexibility about what queries matched that name (and even have different variations in different areas). Of course, the more flexibility that a system provides, the greater the possibility of real or imagined trademark conflicts. But the opportunity would exist to design a directory structure that dealt with those issues in an intelligent way, while DNS constraints almost certainly make a general and equitable DNS-only solution impossible.
Oやっ内（非常に成功したことの多くではないが）かなりの経験があるファジーと「sonex」ディレクトリシステムに一致する（類似した響き）。また、これらの地域の文化の要件に適合させることができるように、異なる領域と名のセットごとに異なる一致規則を考えるようにもっともらしいです。具体的には、ディレクトリ内の名前の単一のフォームを持つことが可能かもしれないが、マッチしたその名前を照会するかについて大きな柔軟性を持っている（とでもさまざまな分野でのさまざまなバリエーションを持っている）します。もちろん、システムが提供するより多くの柔軟性、本物か想像商標の競合の可能性が大きいです。しかし、機会がDNS制約がほぼ確実に一般的で公平なDNSのみのソリューションを不可能にしながら、インテリジェントな方法でこれらの問題に対処したディレクトリ構造を設計するために存在します。
o If a directory system is used to translate to DNS names, and then DNS names are looked up in the normal fashion, it may be possible to relax several of the constraints that have been traditional (and perhaps necessary) with the DNS. For example, reverse-mapping of addresses to directory names may not be a requirement even if mapping of addresses to DNS names continues to be, since the DNS name(s) would (continue to) uniquely identify the host.
O場合、ディレクトリシステムは、DNS名に変換するために使用され、その後、DNS名は、通常の方法で検索され、DNSで、伝統的な（そしておそらく必要な）されている制約のいくつかを緩和することが可能です。例えば、ディレクトリ名とアドレスの逆マッピングは、DNS名（s）は（継続）一意のホストを識別することになるので、DNS名へのアドレスのマッピングは、であり続けても必要ではないかもしれません。
o Solutions to multilingual transcription problems that are common in "normal life" (e.g., two-sided business cards to be sure that recipients trying to contact a person can access romanized spellings and numbers if the original language is not comprehensible to them) can be easily handled in a directory system by inserting both sets of entries.
（例えば、両面名刺は、受信者が元の言語は彼らが理解でない場合はローマ字綴りと数字にアクセスできる人に連絡しようとしていることを確認するために）「普通の生活」で共通している多言語の転写問題にOソリューション可能簡単エントリの両方のセットを挿入することによって、ディレクトリシステムで扱います。
o A directory system could be designed that would return, not a single name, but a set of names paired with network-locational information or other context-establishing attributes. This type of information might be of considerable use in resolving the "nearest (or best) server for a particular named resource" problems that are a significant concern for organizations hosting web and other sites that are accessed from a wide range of locations and subnets.
ディレクトリシステムoを単一の名前、戻ってくることはないように設計することができますが、ネットワーク位置情報または他のコンテキスト確立の属性と対になって名前のセット。この種の情報は、場所やサブネットの広い範囲からアクセスされたウェブをホスティングしている組織や他のサイトのための重要な関心事である「最も近い（または最高の）特定の名前付きリソース用サーバ」の問題を解決するにはかなりの使用であるかもしれません。
o Names bound to countries and languages might help to manage trademark realities, while, as discussed in section 1.3 above, use of the DNS in trademark-significant contexts tends to require worldwide "flattening" of the trademark system.
O国と言語にバインドされた名前は、上記のセクション1.3で説明したように、一方で、商標の現実を管理するのに役立つかもしれない、商標、重要なコンテキストでDNSを使用することは、世界的な商標制度の「平坦化」を必要とする傾向があります。
Many of these issues are a consequence of another property of the DNS: names must be unique across the Internet. The need to have a system of unique identifiers is fairly obvious (see [RFC2826]). However, if that requirement were to be eliminated in a search or directory system that was visible to users instead of the DNS, many difficult problems -- of both an engineering and a policy nature -- would be likely to vanish.
これらの問題の多くは、DNSの別の特性の結果である：名前は、インターネット全体で一意でなければなりません。一意の識別子のシステムを持っている必要がありますが、かなり明白である（[RFC2826]を参照）。エンジニアリングと政策自然の両方の - - その要件ではなく、DNSのユーザーが、多くの困難な問題に見えた検索やディレクトリシステムで排除されるならばしかし、消える可能性が高いだろう。
Almost any internationalization proposal for names that are in, or map into, the DNS will require changing DNS resolver API calls ("gethostbyname" or equivalent), or adding some pre-resolution preparation mechanism, in almost all Internet applications -- whether to cause the API to take a different character set (no matter how it is then mapped into the bits used in the DNS or another system), to accept or return more arguments with qualifying or identifying information, or otherwise. Once applications must be opened to make such changes, it is a relatively small matter to switch from calling into the DNS to calling a directory service and then the DNS (in many situations, both actions could be accomplished in a single API call).
である、またはにマップ名のほぼすべての国際化提案は、DNSは、ほぼすべてのインターネットアプリケーションでは、DNSリゾルバAPI呼び出しを変更する（「のgethostbyname」または同等のもの）、またはいくつかの事前解像度準備機構を追加する必要があります - 原因とするかどうかそうでない場合は、別の文字セット（それはその後、DNSまたは他のシステムで使用されるビットにマッピングされているかに関係なく）を取るために資格や識別情報で複数の引数を受け入れるか返すために、またはAPI。アプリケーションは、このような変更を行うために開設されなければならないと、ディレクトリサービスの呼び出しにDNSへの呼び出しから切り替えるために、比較的小さな問題であり、その後、DNSは、（多くの状況では、両方のアクションは、単一のAPIコールで達成することができます）。
A directory approach can be consistent both with "flat" models and multi-attribute ones. The DNS requires strict hierarchies, limiting its ability to differentiate among names by their properties. By contrast, modern directories can utilize independently-searched attributes and other structured schema to provide flexibilities not present in a strictly hierarchical system.
ディレクトリのアプローチは、両方の「フラット」モデルとマルチ属性のものと一致することができます。 DNSは、そのプロパティで名前を区別する能力を制限し、厳格な階層が必要です。これとは対照的に、近代的なディレクトリは厳密に階層システムに存在しない柔軟性を提供するために、独立して、検索属性や他の構造化スキーマを利用することができます。
There is a strong historical argument for a single directory structure (implying a need for mechanisms for registration, delegation, etc.). But a single structure is not a strict requirement, especially if in-depth case analysis and design work leads to the conclusion that reverse-mapping to directory names is not a requirement (see section 5). If a single structure is not needed, then, unlike the DNS, there would be no requirement for a global organization to authorize or delegate operation of portions of the structure.
（登録、委任などのためのメカニズムの必要性を示唆し）、単一のディレクトリ構造のための強力な歴史的な引数があります。しかし、単一の構造は、詳細な事例分析と設計作業は、ディレクトリ名にマッピングし、逆の結論につながる場合は特に、厳格な要件ではないこと（セクション5を参照）の要件ではありません。単一の構造が必要とされていない場合は、その後、DNSとは異なり、認可または構造の一部の委任操作するグローバルな組織のための要件ではないだろう。
The "no single structure" concept could be taken further by moving away from simple "names" in favor of, e.g., multiattribute, multihierarchical, faceted systems in which most of the facets use restricted vocabularies. (These terms are fairly standard in the information retrieval and classification system literature, see, e.g., [IS5127].) Such systems could be designed to avoid the need for procedures to ensure uniqueness across, or even within, providers and databases of the faceted entities for which the search is to be performed. (See [DNS-Search] for further discussion.)
「いいえ、単一構造」概念は、の賛成でシンプルな「名前」から離れて移動することによって、さらに取ることができ、例えば、多属性、ファセットのほとんどは語彙を使用制限した多階層、多面的なシステム。 （これらの用語は、例えば、[IS5127]、情報検索及び分類システム文献においてかなり標準的である参照。）このようなシステムは、ファセットのプロバイダとデータベースの手順は、一意性を横切って確実にするための必要性を回避するように設計された、あるいは内ことができます検索が実行されるため、エンティティ。 （さらなる議論のための[DNS-検索]を参照してください。）
While the discussion above includes very general comments about attributes, it appears that only a very small number of attributes would be needed. The list would almost certainly include country and language for internationalization purposes. It might require "charset" if we cannot agree on a character set and encoding, although there are strong arguments for simply using ISO 10646 (also known as Unicode or "UCS" (for Universal Character Set) [UNICODE], [IS10646] coding in interchange. Trademark issues might motivate "commercial" and "non-commercial" (or other) attributes if they would be helpful in bypassing trademark problems. And applications to resource location, such as those contemplated for Uniform Resource Identifiers (URIs) [RFC2396, RFC3305] or the Service Location Protocol [RFC2608], might argue for a few other attributes (as outlined above).
上記の議論は、属性についての非常に一般的なコメントを含んでいるが、属性のごく少数が必要であろうと思われます。リストには、ほぼ確実に国際化の目的のために、国や言語が含まれるであろう。これは単に、ISO 10646を使用するための強力な引数がありますが、我々は、文字セットとエンコーディングに同意できない場合は、[UNICODE]（も）ユニバーサル文字セットのために（Unicodeまたは「UCS」として知られている「文字セット」を必要[IS10646]コーディングかもしれませんインターチェンジで。商標の問題は、彼らが商標の問題をバイパスするのに役立つだろう場合は、「商用」と「非商用」（または他の）属性動機かもしれません。そしてアプリケーションは、このようなユニフォームリソース識別子（URI）[RFC2396のために企図されるような、場所を資源に、RFC3305]又は（上記で概説したように）サービスロケーションプロトコル[RFC2608]は、いくつかの他の属性に主張するかもしれません。
Much of the thinking underlying this document was driven by considerations of internationalizing the DNS or, more specifically, providing access to the functions of the DNS from languages and naming systems that cannot be accurately expressed in the traditional DNS subset of ASCII. Much of the relevant work was done in the IETF's "Internationalized Domain Names" Working Group (IDN-WG), although this document also draws on extensive parallel discussions in other forums. This section contains an evaluation of what was learned as an "internationalized DNS" or "multilingual DNS" was explored and suggests future steps based on that evaluation.
このドキュメントの基礎となる思考の多くは、DNSの国際化や、より具体的に、正確にASCIIの伝統的なDNSのサブセットで表現できない言語やネーミングシステムからのDNSの機能へのアクセスを提供するの配慮によるものでした。この文書はまた、他のフォーラムで豊富な並列議論を描くが、関連する作業の多くは、IETFの「国際化ドメイン名」ワーキンググループ（IDN-WG）で行いました。このセクションでは、「国際DNS」または「多言語DNS」として学んだことの評価を調査した含まれており、その評価に基づいて、将来のステップを示唆しています。
When the IDN-WG was initiated, it was obvious to several of the participants that its first important task was an undocumented one: to increase the understanding of the complexities of the problem sufficiently that naive solutions could be rejected and people could go to work on the harder problems. The IDN-WG clearly accomplished that task. The beliefs that the problems were simple, and in the corresponding simplistic approaches and their promises of quick and painless deployment, effectively disappeared as the WG's efforts matured.
IDN-WGが開始されたとき、それはその最初の重要なタスクは、文書化されていないものであったことを、参加者のいくつかには明らかだった。十分に素朴な解決策を拒否することができ、人々が上の仕事に行くことができると、問題の複雑さの理解を高めるために難しい問題。 IDN-WGは明らかにそのタスクを達成しました。問題は単純で、かつ、対応する単純なアプローチや、迅速かつ無痛展開の彼らの約束で、効果的に成熟したWGの取り組みとして姿を消したことを確信。
Some of the lessons learned from increased understanding and the dissipation of naive beliefs should be taken as cautions by the wider community: the problems are not simple. Specifically, extracting small elements for solution rather than looking at whole systems, may result in obscuring the problems but not solving any problem that is worth the trouble.
増加理解と素朴な信念の損失から学んだ教訓のいくつかは、より広い社会の注意として取られるべきである：問題は単純ではありません。具体的には、解決のための小さな要素を抽出するのではなく、全体のシステムを見て、問題を曖昧なく、トラブルの価値があるすべての問題を解決ない結果になるかも知れません。
The hostname rules chosen in the mid-70s weren't just "ASCII because English uses ASCII", although that was a starting point. We have discovered that almost every other script (and even ASCII if we permit the rest of the characters specified in the ISO 646 International Reference Version) is more complex than hostname-restricted-ASCII (the "LDH" form, see section 1.1). And ASCII isn't sufficient to completely represent English -- there are several words in the language that are correctly spelled only with characters or diacritical marks that do not appear in ASCII. With a broader selection of scripts, in some examples, case mapping works from one case to the other but is not reversible. In others, there are conventions about alternate ways to represent characters (in the language, not [only] in character coding) that work most of the time, but not always. And there are issues in coding, with Unicode/10646 providing different ways to represent the same character ("character", rather than "glyph", is used deliberately here). And, in still others, there are questions as to whether two glyphs "match", which may be a distance-function question, not one with a binary answer. The IETF approach to these problems is to require pre-matching canonicalization (see the "stringprep" discussion below).
「英語はASCIIを使用しているため、ASCII」それが出発点だったが、70年代半ばに選ばれたホスト名のルールは、ちょうどありませんでした。私たちは、ほぼすべての他のスクリプト（とさえASCII我々はISO 646国際リファレンスバージョンで指定された文字の残りの部分が許可されている場合）、ホスト名制限-ASCIIよりも複雑であるが（「LDH」フォームには、セクション1.1を参照）ことを発見しました。そして、ASCIIは完全に英語を表現するのに十分ではない - いくつかの単語を正しくASCIIに表示されていない文字や発音区別符号のみで綴られている言語です。スクリプトのより広範な選択では、いくつかの例では、ケースマッピングは、他の1つのケースから動作しますが、可逆的ではありません。他では、常にではないほとんどの時間を動作しますが、（ない[のみ]文字符号化では、言語の）文字を表現する別の方法についての規則があります。ユニコード/ 10646は、（意図的にここで使用され、むしろ「グリフ」よりも、「文字」）と同じ文字を表現するさまざまな方法を提供するとと、コーディングに問題があります。そして、まだ他の人には、距離関数の問題ではなく、バイナリの答えであってもよいかどうかを2つのグリフ「一致」のような質問が、あります。これらの問題に対するIETFアプローチは（以下「文字列準備」の議論を参照されたい）、プリマッチング正規化を必要とすることです。
The IETF has resisted the temptations to either try to specify an entirely new coded character set, or to pick and choose Unicode/10646 characters on a per-character basis rather than by using well-defined blocks. While it may appear that a character set designed to meet Internet-specific needs would be very attractive, the IETF has never had the expertise, resources, and representation from critically-important communities to actually take on that job. Perhaps more important, a new effort might have chosen to make some of the many complex tradeoffs differently than the Unicode committee did, producing a code with somewhat different characteristics. But there is no evidence that doing so would produce a code with fewer problems and side-effects. It is much more likely that making tradeoffs differently would simply result in a different set of problems, which would be equally or more difficult.
IETFは全く新しいコード化文字セットを指定しようとするか、または文字単位ではなく、明確に定義されたブロックを使用してユニコード/ 10646文字を選択し、選択する誘惑に抵抗しました。それは、インターネット特有のニーズを満たすように設計された文字セットは非常に魅力的であろうと思われるかもしれないが、IETFは、実際にその仕事を引き受けるために批判的に、重要なコミュニティからの専門知識、リソース、および表現がありませんでした。おそらくもっと重要なのは、新しい取り組みが多少異なる特性を持つコードを生成する、異なったUnicodeの委員会が行ったよりも多くの複雑なトレードオフのいくつかを作ることを選択した可能性があります。しかし、そうすることが少ない問題や副作用を持つコードを生成するという証拠はありません。異なったトレードオフを行うことは、単純に均等以上のことは困難であろう問題の異なるセットをもたらすだろうとずっとそうです。
While the DNS can handle arbitrary binary strings without known internal problems (see [RFC2181]), some restrictions are imposed by the requirement that text be interpreted in a case-independent way ([RFC1034], [RFC1035]). More important, most internet applications assume the hostname-restricted "LDH" syntax that is specified in the host table RFCs and as "prudent" in RFC 1035. If those assumptions are not met, many conforming implementations of those applications may exhibit behavior that would surprise implementors and users. To avoid these potential problems, IETF internationalization work has focused on "ASCII-Compatible Encodings" (ACE). These encodings preserve the LDH conventions in the DNS itself. Implementations of applications that have not been upgraded utilize the encoded forms, while newer ones can be written to recognize the special codings and map them into non-ASCII characters. These approaches are, however, not problem-free even if human interface issues are ignored. Among other issues, they rely on what is ultimately a heuristic to determine whether a DNS label is to be considered as an internationalized name (i.e., encoded Unicode) or interpreted as an actual LDH name in its own right. And, while all determinations of whether a particular query matches a stored object are traditionally made by DNS servers, the ACE systems, when combined with the complexities of international scripts and names, require that much of the matching work be separated into a separate, client-side, canonicalization or "preparation" process before the DNS matching mechanisms are invoked [STRINGPREP].
DNSは、既知の内部問題なく任意のバイナリ文字列を扱うことができるが（参照[RFC2181]）、いくつかの制限は、テキストがケースに依存しない方法で解釈される要件によって課される（[RFC1034]、[RFC1035]）。さらに重要なのは、ほとんどのインターネットアプリケーションは、ホストテーブルのRFCで指定されたホスト名限定「LDH」構文を想定し、これらの前提条件が満たされない場合は、RFC 1035で「慎重な」として、これらのアプリケーションの多くの準拠実装はその希望の挙動を示すことができます驚きの実装およびユーザー。これらの潜在的な問題を回避するために、IETF国際化の作業は、「ASCII互換エンコーディング」（ACE）に焦点を当てています。これらのエンコーディングは、DNS自体にLDHの規則を保存します。新しいものは、特別なコーディングを認識し、非ASCII文字にそれらをマッピングするために書き込むことができますがアップグレードされていないアプリケーションの実装は、エンコードされたフォームを利用しています。これらのアプローチは、ヒューマンインタフェースの問題が無視された場合でも、しかし、問題は、無料ではありません。他の問題の中で、彼らは最終的にDNSラベルは国際名（即ち、エンコードされたUnicode）とみなす又はそれ自体が実際のLDH名として解釈されるべきであるかどうかを決定するためのヒューリスティックが何であるかに依存しています。そして、特定のクエリが格納されたオブジェクトと一致するかどうかのすべての決定は、伝統的に国際的なスクリプトと名前の複雑さと組み合わせたときに、DNSサーバ、ACEシステムによって作られた照合作業の多くは別の、クライアントに分離されることを必要としている間DNSマッチングメカニズム前側の、正規化または「準備」プロセスは[STRINGPREP]呼び出されます。
As outlined above, the model for avoiding problems associated with putting non-ASCII names in the DNS and elsewhere evolved into the principle that strings are to be placed into the DNS only after being passed through a string preparation function that eliminates or rejects spurious character codes, maps some characters onto others, performs some sequence canonicalization, and generally creates forms that can be accurately compared. The impact of this process on hostname-restricted ASCII (i.e., "LDH") strings is trivial and essentially adds only overhead. For other scripts, the impact is, of necessity, quite significant.
上で概説したように、他の場所でDNSに非ASCII名を入れてに関連する問題を回避するためのモデルは、排除または偽の文字コードを拒否した文字列の作成機能を通過した後に文字列がDNSに配置されるようにしているという原則に進化し、他にいくつかの文字をマッピングし、いくつかの配列の正規化を行い、一般的に正確に比較することができるフォームを作成します。ホスト名制限ASCII（すなわち、「LDH」）の文字列で、このプロセスの影響は自明であり、本質的にオーバーヘッドが追加されます。他のスクリプトの場合は、影響は、必然的に、非常に重要です。
Although the general notion underlying stringprep is simple, the many details are quite subtle and the associated tradeoffs are complex. A design team worked on it for months, with considerable effort placed into clarifying and fine-tuning the protocol and tables. Despite general agreement that the IETF would avoid getting into the business of defining character sets, character codings, and the associated conventions, the group several times considered and rejected special treatment of code positions to more nearly match the distinctions made by Unicode with user perceptions about similarities and differences between characters. But there were intense temptations (and pressures) to incorporate language-specific or country-specific rules. Those temptations, even when resisted, were indicative of parts of the ongoing controversy or of the basic unsuitability of the DNS for fully internationalized names that are visible, comprehensible, and predictable for end users.
文字列前の基礎となる一般的な概念はシンプルですが、多くの詳細は非常に微妙であり、関連するトレードオフは複雑です。かなりの努力が明確化し、プロトコルとテーブルを微調整に置いて設計チームは、数ヶ月のためにそれに取り組みました。 IETFは、文字セット、キャラクターコーディング、および関連する規則を定義するビジネスに入らないようにすることを一般的な合意にもかかわらず、グループは数倍と考えられ、より近いに関するユーザーの認識をUnicodeで作られた区別を一致させるために、コードの位置の特別な治療を拒否しました文字間の類似点と相違点。しかし、強烈な誘惑（および圧力）言語固有または国固有のルールを組み込むことがありました。これらの誘惑には、抵抗した場合でも、継続的な論争のか、目に見える分かり、およびエンドユーザーのための予測可能で完全に国際名のDNSの基本的な不適合の部品を示しました。
There have also been controversies about how far one should go in these processes of preparation and transformation and, ultimately, about the validity of various analogies. For example, each of the following operations has been claimed to be similar to case-mapping in ASCII:
また、1は、様々なアナロジーの妥当性については、最終的には、準備と変換のこれらのプロセスに行くとすべきか遠くに関する論争がありました。例えば、次の操作の各々は、ASCIIにおけるケースマッピングと同様であることが主張されています。
o stripping of vowels in Arabic or Hebrew
アラビア語やヘブライ語の母音のストリッピングO
o matching of "look-alike" characters such as upper-case Alpha in Greek and upper-case A in Roman-based alphabets
ギリシャ語で、このような大文字アルファとして「そっくり」の文字のOマッチングとローマベースのアルファベットで大文字のA
o matching of Traditional and Simplified Chinese characters that represent the same words,
同じ言葉を表す繁体字および簡体字中国語の文字のOマッチング、
o matching of Serbo-Croatian words whether written in Roman-derived or Cyrillic characters
- ローマの派生やキリル文字で書かれているかどうかセルビア・クロアチア語の単語のOマッチング
A decision to support any of these operations would have implications for other scripts or languages and would increase the overall complexity of the process. For example, unless language-specific information is somehow available, performing matching between Traditional and Simplified Chinese has impacts on Japanese and Korean uses of the same "traditional" characters (e.g., it would not be appropriate to map Kanji into Simplified Chinese).
これらの操作をサポートするという決定は、他のスクリプトや言語のための意味合いを持っているでしょうし、プロセスの全体的な複雑さを増すだろう。言語固有の情報が何らかの形で利用可能でない場合、例えば、間のマッチングを行う繁体、簡体字中国語同じ「伝統的な」文字（例えば、簡体字中国語に漢字をマッピングすることは適切ではないであろう）の日本と韓国の用途への影響を有しています。
Even were the IDN-WG's other work to have been abandoned completely or if it were to fail in the marketplace, the stringprep and nameprep work will continue to be extremely useful, both in identifying issues and problem code points and in providing a reasonable set of basic rules. Where problems remain, they are arguably not with nameprep, but with the DNS-imposed requirement that its results, as with all other parts of the matching and comparison process, yield a binary "match or no match" answer, rather than, e.g., a value on a similarity scale that can be evaluated by the user or by user-driven heuristic functions.
でも、IDN-WGの他の作業が完全に放棄されたとしたか、それが市場で失敗した場合、文字列前とNAMEPREP作業は、問題と、問題のコードポイントを識別するのにとの合理的なセットを提供するには、両方の、非常に有用であり続けるだろう基本的なルール。問題が残っている場合、それらは例えば、NAMEPREPと、しかしマッチングと比較プロセスのすべての他の部分と同様の結果は、バイナリ「一致か不一致」の回答を得DNS-課さ要件に間違いなくはない、というよりも、ユーザまたはユーザ主導ヒューリスティック関数によって評価することができる類似のスケール上の値。
ISO 10646 basically defines only code points, and not rules for using or comparing the characters. This is part of a long-standing tradition with the work of what is now ISO/IEC JTC1/SC2: they have performed code point assignments and have typically treated the ways in which characters are used as beyond their scope. Consequently, they have not dealt effectively with the broader range of internationalization issues. By contrast, the Unicode Technical Committee (UTC) has defined, in annexes and technical reports (see, e.g., [UTR15]), some additional rules for canonicalization and comparison. Many of those rules and conventions have been factored into the "stringprep" and "nameprep" work, but it is not straightforward to make or define them in a fashion that is sufficiently precise and permanent to be relied on by the DNS.
ISO 10646は、基本的にのみコードポイント、及び文字を使用するか比較するためのない規則を定義します。これは、今、ISO / IEC JTC1 / SC2で何の仕事に長年の伝統の一部です：彼らはコードポイントの割り当てを行っていると、通常の文字は、その範囲を超えて使用される方法を治療しています。その結果、彼らは国際化の問題の広い範囲で効果的に対処していません。対照的に、ユニコード会（UTC）は、附属書及び技術報告書（[UTR15]、例えば、参照）で、正規化と比較するためのいくつかの追加の規則を定義しています。これらのルールや規則の多くは、「文字列前」と「NAMEPREP」仕事に織り込まれているが、作るか、またはDNSによって依拠されるのに十分に正確かつ永続的である方法でそれらを定義することは簡単ではありません。
Perhaps more important, the discussions leading to nameprep also identified several areas in which the UTC definitions are inadequate, at least without additional information, to make matching precise and unambiguous. In some of these cases, the Unicode Standard permits several alternate approaches, none of which are an exact and obvious match to DNS needs. That has left these sensitive choices up to IETF, which lacks sufficient in-depth expertise, much less any mechanism for deciding to optimize one language at the expense of another.
おそらくもっと重要な、またNAMEPREPにつながる議論がUTCの定義が正確かつ明確な一致にするために、少なくとも追加の情報なしに、不十分である、いくつかの領域を特定しました。これらの場合のいくつかでは、ユニコード規格は、DNSのニーズに正確かつ明らかに一致しているいずれもいくつかの代替的なアプローチを可能にします。それは十分なの深い専門知識、他を犠牲にして1つの言語を最適化することを決定するためにはるかに少ない任意のメカニズムを欠いIETF、までこれらの敏感な選択肢を残しています。
For example, it is tempting to define some rules on the basis of membership in particular scripts, or for punctuation characters, but there is no precise definition of what characters belong to which script or which ones are, or are not, punctuation. The existence of these areas of vagueness raises two issues: whether trying to do precise matching at the character set level is actually possible (addressed below) and whether driving toward more precision could create issues that cause instability in the implementation and resolution models for the DNS.
たとえば、特定のスクリプトで、または句読点のメンバーシップに基づいていくつかのルールを定義することは魅力的ですが、文字は、句読点をどのスクリプトまたはものがあるに属し、かそうでないかの全く正確な定義はありません。 （下記の対処）文字セットレベルで正確なマッチングをやろうとすることは実際に可能であるかどうかを、より精密に向かって駆動するかどうかDNSの実装および解像度モデルで不安定になる問題を作成することができます。あいまいさのこれらの領域の存在は二つの問題を提起します。
The Unicode definition also evolves. Version 3.2 appeared shortly after work on this document was initiated. It added some characters and functionality and included a few minor incompatible code point changes. IETF has secured an agreement about constraints on future changes, but it remains to be seen how that agreement will work out in practice. The prognosis actually appears poor at this stage, since UTC chose to ballot a recent possible change which should have been prohibited by the agreement (the outcome of the ballot is not relevant, only that the ballot was issued rather than having the result be a foregone conclusion). However, some members of the community consider some of the changes between Unicode 3.0 and 3.1 and between 3.1 and 3.2, as well as this recent ballot, to be evidence of instability and that these instabilities are better handled in a system that can be more flexible about handling of characters, scripts, and ancillary information than the DNS.
Unicodeの定義も進化します。この文書の作業が開始された後にバージョン3.2が間もなく登場しました。これは、一部の文字や機能が追加され、いくつかのマイナーな互換性のないコードポイントの変更が含まれています。 IETFは、将来の変更の制約についての合意を確保しているが、それはその合意が実際にうまくいくかはまだ分かりません。予後は実際にUTCは協定（投票の結果によって禁止されている必要があり、最近の可能性の変化は、投票が、結果は当然のことのではなく発行されたことだけが、関係ありません投票に選んだことから、この段階では貧しい表示されます結論）。しかし、コミュニティの一部のメンバーは、不安定性の証拠であることをユニコード3.0と3.1の間と3.1と3.2の間の変更だけでなく、今回の投票、のいくつかを検討し、これらの不安定性は、より良い、より柔軟にできるシステムで扱われていることをDNSより文字、スクリプト、および補助情報の取り扱いについて。
In addition, because the systems implications of internationalization are considered out of scope in SC2, ISO/IEC JTC1 has assigned some of those issues to its SC22/WG20 (the Internationalization working group within the subcommittee that deals with programming languages, systems, and environments). WG20 has historically dealt with internationalization issues thoughtfully and in depth, but its status has several times been in doubt in recent years. However, assignment of these matters to WG20 increases the risk of eventual ISO internationalization standards that specify different behavior than the UTC specifications.
国際化のシステムへの影響はSC2に適用範囲外であるのでまた、ISO / IEC JTC1は、プログラミング言語、システム、および環境を扱う小委員会内でのSC22 / WG20（国際ワーキンググループにそれらの問題のいくつかを割り当てています）。 WG20は、歴史的に思慮深く、深さは国際化の問題を扱っていますが、その状況は近年の疑いで数回となっています。しかし、WG20にこれらの問題の割り当ては、UTCの仕様とは異なる動作を指定する最終的なISOの国際標準規格のリスクを増大させます。
Part of what has "caused" the DNS internationalization problem, as well as the DNS trademark problem and several others, is that we have stopped thinking about "identifiers for objects" -- which normal people are not expected to see -- and started thinking about "names" -- strings that are expected not only to be readable, but to have linguistically-sensible and culturally-dependent meaning to non-specialist users.
普通の人が見に期待されていない - - と考え始めDNSの国際化の問題だけでなく、DNSの商標問題や他のいくつかの「原因」した内容の一部は、私たちは「オブジェクトの識別子」について考えて停止したことです文字列の読み出しを可能にするにはなく、非専門家のユーザーに言語的、賢明かつ文化的に依存意味を持っているだけでなく、期待されている - 「名前」について。
Within the IETF, the IDN-WG, and sometimes other groups, avoided addressing the implications of that transition by taking "outside our scope -- someone else's problem" approaches or by suggesting that people will just become accustomed to whatever conventions are adopted. The realities of user and vendor behavior suggest that these approaches will not serve the Internet community well in the long term:
アプローチや人々が採用されているものは何でも規則に慣れるだろうことを示唆していることで - IETF、IDN-WG、そして時には他のグループの中で、「他の誰かの問題を私たちの範囲外」取ることによって、その変化の影響を回避取り組みます。ユーザーとベンダーの行動の現実は、これらのアプローチは、長期的にもインターネットコミュニティにサービスを提供しないことをお勧め：
o If we want to make it a problem in a different part of the user interface structure, we need to figure out where it goes in order to have proof of concept of our solution. Unlike vendors whose sole [business] model is the selling or registering of names, the IETF must produce solutions that actually work, in the applications context as seen by the end user.
我々はそれのユーザインターフェース構造の別の部分で問題にしたい場合は、O、我々はそれが私たちのソリューションの概念実証を持っているために、どこに行くかを把握する必要があります。名前の販売または登録され、その唯一の[ビジネス]モデルのベンダーとは異なり、IETFは、エンドユーザーが見られるように、実際のアプリケーションのコンテキスト内で、作業溶液を生成しなければなりません。
o The principle that "they will get used to our conventions and adapt" is fine if we are writing rules for programming languages or an API. But the conventions under discussion are not part of a semi-mathematical system, they are deeply ingrained in culture. No matter how often an English-speaking American is told that the Internet requires that the correct spelling of "colour" be used, he or she isn't going to be convinced. Getting a French-speaker in Lyon to use exactly the same lexical conventions as a French- speaker in Quebec in order to accommodate the decisions of the IETF or of a registrar or registry is just not likely. "Montreal" is either a misspelling or an anglicization of a similar word with an acute accent mark over the "e" (i.e., using the Unicode character U+00E9 or one of its equivalents). But global agreement on a rule that will determine whether the two forms should match -- and that won't astonish end users and speakers of one language or the other -- is as unlikely as agreement on whether "misspelling" or "anglicization" is the greater travesty.
我々はプログラミング言語やAPIのルールを作成している場合は、「彼らは私たちの規則に使用し、適応してしまいます」という原則oを結構です。しかし、検討中の規則は、半数学のシステムの一部ではない、彼らは文化に深く根付いています。どんなに英語圏のアメリカ人がインターネットを「色」の正しいスペルが使用されている必要がありますと言われている頻度を、彼または彼女が納得するつもりはないされていません。 IETFのか、レジストラまたはレジストリの意思決定に対応するために、正確にケベック州のフランス語 - スピーカーと同じ字句規則を使用するためにリヨンにフランスのスピーカーを取得するだけでない可能性があります。 「モントリオール」（すなわち、ユニコード文字U + 00E9またはその等価物のいずれかを使用して）、「E」上急性アクセント記号付きスペルミスまたは類似の単語のanglicizationのいずれかです。しかし、二つの形式が一致する必要があるかどうかを判断するルールのグローバルな合意 - それは一つの言語や他のエンドユーザーとスピーカーを驚かないだろうが - 「スペルミス」または「anglicization」であるかどうかについての合意のようにほとんどありません大きい茶番。
More generally, it is not clear that the outcome of any conceivable nameprep-like process is going to be good enough for practical, user-level, use. In the use of human languages by humans, there are many cases in which things that do not match are nonetheless interpreted as matching. The Norwegian/Danish character that appears in U+00F8 (visually, a lower case 'o' overstruck with a forward slash) and the "o-umlaut" German character that appears in U+00F6 (visually, a lower case 'o' with diaeresis (or umlaut)) are clearly different and no matching program should yield an "equal" comparison. But they are more similar to each other than either of them is to, e.g., "e". Humans are able to mentally make the correction in context, and do so easily, and they can be surprised if computers cannot do so. Worse, there is a Swedish character whose appearance is identical to the German o-umlaut, and which shares code point U+00F6, but that, if the languages are known and the sounds of the letters or meanings of words including the character are considered, actually should match the Norwegian/Danish use of U+00F8.
より一般的には、考えられるあらゆるNAMEPREPのようなプロセスの結果は、実用的な、ユーザレベル、使用するために十分であることを行っていることは明らかではありません。人間による人間の言語の使用では、一致しないものがそれにもかかわらず、マッチングとして解釈されている場合が多いです。視覚的に（U + 00F6に表示されますU + 00F8に表示されますデンマーク/ノルウェー文字（視覚的に、小文字の「O」重ね打ちスラッシュ付き）と「O-ウムラウト」ドイツ語の文字、小文字の「O」分音符号（またはウムラウト））を用いて明らかに異なっており、該当するプログラムは「等しい」の比較をもたらすべきではありません。しかし、彼らはそれらのいずれかが、例えば、「E」、にあるよりも、お互いに類似しています。人間は精神的文脈で補正を行い、そう簡単に行うことができます、そしてコンピュータがそうすることができない場合、彼らはびっくりすることができます。さらに悪いことに、そこにその外観ドイツのOウムラウトと同じであるスウェーデンの文字であり、コードポイントU + 00F6を共有するが、言語が知られている場合には、文字や文字を含む単語の意味の音が検討されています、実際にはU + 00F8のデンマーク/ノルウェーの使用と一致する必要があります。
This text uses examples in Roman scripts because it is being written in English and those examples are relatively easy to render. But one of the important lessons of the discussions about domain name internationalization in recent years is that problems similar to those described above exist in almost every language and script. Each one has its idiosyncrasies, and each set of idiosyncracies is tied to common usage and cultural issues that are very familiar in the relevant group, and often deeply held as cultural values. As long as a schoolchild in the US can get a bad grade on a spelling test for using a perfectly valid British spelling, or one in France or Germany can get a poor grade for leaving off a diacritical mark, there are issues with the relevant language. Similarly, if children in Egypt or Israel are taught that it is acceptable to write a word with or without vowels or stress marks, but that, if those marks are included, they must be the correct ones, or a user in Korea is potentially offended or astonished by out-of-order sequences of Jamo, systems based on character-at-a-time processing and simplistic matching, with no contextual information, are not going to satisfy user needs.
それは英語で書かれていると、それらの例は、レンダリングすることが比較的容易であるため、このテキストはローマ字の例を使用しています。しかし、近年では、ドメイン名の国際化に関する議論の重要な教訓の一つは、上述したものと同様の問題は、ほぼすべての言語やスクリプトに存在することです。それぞれがその特異性を持ち、かつ特質の各セットは、関連するグループでは非常に精通している一般的な使い方や文化的な問題に結びついている、としばしば深く文化的価値として開催されました。米国の小学生が、ダイアクリティカルマークをオフに残すための貧弱な成績を得ることができ、フランスやドイツでは完全に有効な英国のスペリング、または1つを使用するためのスペルテストで悪い成績を得ることができる限り、該当する言語の問題があります。同様に、エジプトやイスラエルの子供たちは、母音やストレスマークの有無にかかわらず単語を書くために許容可能であることを教えられている場合が、これらのマークが含まれている場合は、ことを、彼らは正しいものでなければならない、あるいは韓国のユーザーが潜在的に怒られますまたは文字で-時間処理し、単純なマッチングに基づいて、字母のアウト・オブ・オーダーシーケンス、システムによって驚き、なしコンテキスト情報と、ユーザのニーズを満足するつもりはありません。
Users are demanding solutions that deal with language and culture. Systems of identifier symbol-strings that serve specialists or computers are, at best, a solution to a rather different (and, at the time this document was written, somewhat ill-defined), problem. The recent efforts have made it ever more clear that, if we ignore the distinction between the user requirements and narrowly-defined identifiers, we are solving an insufficient problem. And, conversely, the approaches that have been proposed to approximate solutions to the user requirement may be far more complex than simple identifiers require.
ユーザーは、言語や文化に対処するソリューションを求めています。せいぜい、ある専門家やコンピュータにサービスを提供識別記号 - 文字列、かなり異なる（および、この文書が書かれた時点で、やや不明確）に対する解決策、問題のシステム。最近の努力は、我々は、ユーザの要件と狭義の識別子の区別を無視するならば、我々は不十分な問題を解決している、ということがこれまで以上に明確になりました。そして、逆に、ユーザーの要求に近似解に提案されているアプローチは、単純な識別子が必要よりもはるかに複雑です。
Over the last few centuries, local conventions have been established in various parts of the world for dealing with multilingual situations. It may be helpful to examine some of these. For example, if one visits a country where the language is different from ones own, business cards are often printed on two sides, one side in each language. The conventions are not completely consistent and the technique assumes that recipients will be tolerant. Translations of names or places are attempted in some situations and transliterations in others. Since it is widely understood that exact translations or transliterations are often not possible, people typically smile at errors, appreciate the effort, and move on.
過去数世紀にわたって、地元の慣習では、多言語状況に対処するため、世界のさまざまな部分で確立されています。これらのいくつかを検討するために役立つかもしれません。 1言語がもの自身の異なる国を訪問する場合、例えば、名刺には、多くの場合、それぞれの言語で両面、片面に印刷されています。規則は完全に一致していないと技術は、受信者が寛容になることを前提としています。名前や場所の翻訳は、他の一部の状況や音訳で試行されています。広く、正確な翻訳や音訳がしばしば可能ではないことが理解されているので、人々は一般的に、エラーで笑顔の努力に感謝し、上に移動します。
The DNS situation differs from these practices in at least two ways. Since a global solution is required, the business card would need a number of sides approximating the number of languages in the world, which is probably impossible without violating laws of physics. More important, the opportunities for tolerance don't exist: the DNS requires a exact match or the lookup fails.
DNSの状況は、少なくとも2つの方法でこれらのプラクティスとは異なります。グローバルソリューションが必要とされているので、名刺は、物理学の法則に違反することなく、おそらく不可能である、世界の言語の数を近似する辺の数を、必要があるでしょう。さらに重要なことは、寛容の機会が存在しません：DNSは、完全一致を必要とするか、または検索が失敗します。
Part of the argument for ACE-based solutions is that they provide an escape for multilingual environments when applications have not been upgraded. When an older application encounters an ACE-based name, the assumption is that the (admittedly ugly) ASCII-coded string will be displayed and can be typed in. This argument is reasonable from the standpoint of mixtures of Roman-based alphabets, but may not be relevant if user-level systems and devices are involved that do not support the entry of Roman-based characters or which cannot conveniently render such characters. Such systems are few in the world today, but the number can reasonably be expected to rise as the Internet is increasingly used by populations whose primary concern is with local issues, local information, and local languages. It is, for example, fairly easy to imagine populations who use Arabic or Thai scripts and who do not have routine access to scripts or input devices based on Roman-derived alphabets.
ACEベースのソリューションのための引数の一部は、アプリケーションがアップグレードされていないときには、多言語環境での脱出を提供するということです。古いアプリケーションがACEベースの名前に遭遇すると、仮定は、この引数はローマンベースのアルファベットとの混合物の観点から妥当である。（確かに醜い）ASCIIコード化された文字列が表示され、で入力することができるということであるかもしれないが、ユーザレベルのシステムやデバイスが含まれている場合は、ローマベースの文字の入力をサポートしていないことや、便利な文字を描画することができない関連性がありません。このようなシステムは、今日の世界でも数少ないですが、数が合理的に、インターネットはますますその主な関心事地域の問題、地域情報、および現地語である集団によって使用されるように上昇すると予想することができます。アラビア語やタイのスクリプトを使用し、誰がローマ由来のアルファベットに基づいたスクリプトや入力デバイスへのルーチンのアクセスを持っていない集団を想像する、例えば、非常に簡単です。
It appears, from the cases above and others, that none of the intra-DNS-based solutions for "multilingual names" are workable. They rest on too many assumptions that do not appear to be feasible -- that people will adapt deeply-entrenched language habits to conventions laid down to make the lives of computers easy; that we can make "freeze it now, no need for changes in these areas" decisions about Unicode and nameprep; that ACE will smooth over applications problems, even in environments without the ability to key or render Roman-based glyphs (or where user experience is such that such glyphs cannot easily be distinguished from each other); that the Unicode Consortium will never decide to repair an error in a way that creates a risk of DNS incompatibility; that we can either deploy EDNS [RFC2671] or that long names are not really important; that Japanese and Chinese computer users (and others) will either give up their local or IS 2022-based character coding solutions (for which addition of a large fraction of a million new code points to Unicode is almost certainly a necessary, but probably not sufficient, condition) or build leakproof and completely accurate boundary conversion mechanisms; that out of band or contextual information will always be sufficient for the "map glyph onto script" problem; and so on. In each case, it is likely that about 80% or 90% of cases will work satisfactorily, but it is unlikely that such partial solutions will be good enough. For example, suppose someone can spell her name 90% correctly, or a company name is matched correctly 80% of the time but the other 20% of attempts identify a competitor: are either likely to be considered adequate?
「多言語名」のイントラ-DNSベースのソリューションのいずれも実行可能ではないことを、上記の例などから、表示されます。彼らは実現可能ではないようで、あまりにも多くの仮定に載る - 人々が簡単にコンピュータの生活を作るために起工規約に深く定着した言語習慣を適応すること。私たちが作ることができる「今すぐそれを凍結し、これらの分野における変更の必要はありません」UnicodeとNAMEPREPに関する決定。そのACEローマベースグリフのキーまたはレンダリングする能力がなくても環境では、アプリケーションの問題を上に平滑化されます（またはユーザの経験は、そのようなグリフが互いに容易に区別することができないようです）。ユニコードコンソーシアムは、DNSの非互換性のリスクを作成する方法でのエラーを修復することを決定しないこと。我々はEDNS [RFC2671]を展開することができますいずれか、またはその長い名前は本当に重要ではないこと。その日本と中国のコンピュータユーザー（およびその他）は地元あきらめるかのソリューションをコーディング2022ベースの文字が（これはUnicodeに万人の新しいコード・ポイントの大部分を追加するため、ほぼ確実に必要であるが、十分ではない、おそらくしますか、条件）、または漏れのない、完全に正確な境界変換メカニズムを構築します。バンドまたはコンテキスト情報のうち、それは常に問題「スクリプトへのマップグリフ」のために十分であろう。等々。それぞれのケースでは、約80％または90％の症例が十分に機能する可能性があるが、そのような部分的な解決策が十分になることはほとんどありません。例えば、90％正しく誰かが彼女の名前を綴ることができたとし、または会社名が正しく一致している時間の80％が、試みの他の20％が競争相手を識別：おそらく十分であると考えられるべきであるのいずれか？
For many years, a common response to requirements to locate people or resources on the Internet has been to invoke the term "directory". While an in-depth analysis of the reasons would require a separate document, the history of failure of these invocations has given "directory" efforts a bad reputation. The effort proposed here is different from those predecessors for several reasons, perhaps the most important of which is that it focuses on a fairly-well-understood set of problems and needs, rather than on finding uses for a particular technology.
長年にわたり、インターネット上の人やリソースを検索するための要件に共通の応答は、用語「ディレクトリ」を起動することでした。その理由の詳細な分析は、別の文書を必要とするが、これらの呼び出しの失敗の歴史は、「ディレクトリ」の取り組みに悪い評判を与えています。努力がここで提案、それが問題やニーズのかなり-よく理解セットではなく、特定の技術のための用途を見つけることに焦点を当てていることで、いくつかの理由のためにそれらの前任者とは別の、おそらく最も重要となっています。
As suggested in some of the text above, it is an open question as to whether the needs of the community would be best served by a single (even if functionally, and perhaps administratively, distributed) directory with universal applicability, a single directory that supports locally-tailored search (and, most important, matching) functions, or multiple, locally-determined, directories. Each has its attractions. Any but the first would essentially prevent reverse-mapping (determination of the user-visible name of the host or resource from target information such as an address or DNS name). But reverse mapping has become less useful over the years --at least to users -- as more and more names have been associated with many host addresses and as CIDR [CIDR] has proven problematic for mapping smaller address blocks to meaningful names.
上記のテキストの一部で示唆したように、それは地域社会のニーズが最高の汎用性を持つ単一の（でも、機能的であれば、おそらく管理上、分散型）ディレクトリ、サポートする単一のディレクトリによって提供されるかどうかに関して、未解決の問題ですローカルに合わせた検索（そして、最も重要な、マッチング）機能、または複数は、ディレクトリをローカルに決定します。それぞれがその魅力を持っています。いずれかが、最初は、本質的に逆マッピング（例えば、アドレスまたはDNS名などの対象情報からホストまたはリソースのユーザー可視名の決意）を防止します。より多くの名前が多くのホストアドレスを持つとCIDR [CIDR]と関連していたとして意味のある名前にマッピングする小さなアドレスブロックのための問題であることが証明された - しかし、逆マッピングは--at少なくともユーザーへの年間ではあまり有用となっています。
Locally-tailored searches and mappings would permit national variations on interpretation of which strings matched which other ones, an arrangement that is especially important when different localities apply different rules to, e.g., matching of characters with and without diacriticals. But, of course, this implies that a URL may evaluate properly or not depending on either settings on a client machine or the network connectivity of the user. That is not, in general, a desirable situation, since it implies that users could not, in the general case, share URLs (or other host references) and that a particular user might not be able to carry references from one host or location to another.
ローカルに合わせた検索およびマッピングは、異なる地域が持つとdiacriticalsのない文字の、例えば、マッチングに異なるルールを適用する場合に特に重要である配置をどの他のものに一致解釈の文字列の国民のバリエーションを可能にします。しかし、もちろん、これはURLが適切かどうか、クライアントマシンまたはユーザーのネットワーク接続上のいずれかの設定に応じて評価してもよいことを意味しています。それは一般的な場合、共有のURL（または他のホスト参照）において、ユーザがなかったことを意味するので、それは、一般に、望ましい状況ではなく、特定のユーザが1つのホストまたは場所から参照を運ぶことができない可能性があること別の。
And, of course, completely separate directories would permit translation and transliteration functions to be embedded in the directory, giving much of the Internet a different appearance depending on which directory was chosen. The attractions of this are obvious, but, unless things were very carefully designed to preserve uniqueness and precise identities at the right points (which may or may not be possible), such a system would have many of the difficulties associated with multiple DNS roots.
そして、もちろん、完全に別のディレクトリには、インターネットの多くに選ばれたディレクトリに応じて、異なる外観を与える、ディレクトリに埋め込まれる翻訳や音訳の機能を可能にします。このアトラクションは明白ですが、物事は非常に慎重に（またはしない可能性のあることがあります）右の点で独自性と正確なアイデンティティを保持するように設計されていない限り、このようなシステムは、複数のDNSルートに関連する困難の多くを持っているでしょう。
Finally, a system of separate directories and databases, if coupled with removal of the DNS-imposed requirement for unique names, would largely eliminate the need for a single worldwide authority to manage the top of the naming hierarchy.
最後に、別のディレクトリやデータベースのシステムは、一意の名前のためのDNS-課さ要件の除去と相まって場合、大部分が命名階層の最上位を管理するための単一の世界的権威の必要性を排除するであろう。
The set of proposals implied by this document suggests an interesting set of security issues (i.e., nothing important is ever easy). A directory system used for locating network resources would presumably need to be as carefully protected against unauthorized changes as the DNS itself. There also might be new opportunities for problems in an arrangement involving two or more (sub)layers, especially if such a system were designed without central authority or uniqueness of names. It is uncertain how much greater those risks would be as compared to a DNS lookup sequence that involved looking up one name, getting back information, and then doing additional lookups potentially in different subtrees. That multistage lookup will often be the case with, e.g., NAPTR records [RFC 2915] unless additional restrictions are imposed. But additional steps, systems, and databases almost certainly involve some additional risks of compromise.
この文書によって暗黙の提案のセットには、セキュリティ上の問題（すなわち、重要なものは、これまで簡単ではありません）の興味深いセットを示唆しています。ネットワークリソースの場所を特定するために使用されるディレクトリ・システムは、おそらくのように慎重にDNS自体として無許可の変更から保護される必要があるであろう。また、このようなシステムは、中央の権威や名前のユニークさせずに設計されていた場合は特に、二つ以上の（サブ）層を含む構造上の問題のために新たな機会があるかもしれません。情報を取り戻す、1名を検索関与DNSルックアップ配列と比較して、別のサブツリーに潜在的に追加的な検索を行うと、これらのリスクがあることだろうかはるかに大きい不確実です。それ多段検索は、多くの場合、とのケースになります例えば、NAPTRレコード追加の制限が課せられている場合を除き、[RFC 2915]。しかし、追加の手順、システム、およびデータベースは、ほぼ確実に妥協のいくつかの追加のリスクを伴います。
None
無し
[Albitz] Any of the editions of Albitz, P. and C. Liu, DNS and BIND, O'Reilly and Associates, 1992, 1997, 1998, 2001.
[Albitz] Albitz、P.とC.劉、DNSおよびBIND、O'Reilly and Associates社発行、1992年、1997年、1998年、2001年版のいずれかが。
[ASCII] American National Standards Institute (formerly United States of America Standards Institute), X3.4, 1968, "USA Code for Information Interchange". ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet. Some time after ASCII was first formulated as a standard, ISO adopted international standard 646, which uses ASCII as a base. IS 646 actually contained two code tables: an "International Reference Version" (often referenced as ISO 646-IRV) which was essentially identical to the ASCII of the time, and a "Basic Version" (ISO 646-BV), which designates a number of character positions for national use.
[ASCII]米国規格協会（アメリカ規格協会の旧米国）、X3.4、1968、「情報交換用米国コード」。 ANSI X3.4-1968は若干の修正を加えた新しいバージョンに置き換えられていますが、1968年版では、インターネットのための決定的なまま。 ASCIIが最初の規格として策定された後にいくつかの時間は、ISOはベースとしてASCIIを使用して、国際標準646を採用しました。 「国際リファレンスバージョン」を指定した時間のASCIIと本質的に同一であった、と「ベーシックバージョン」（ISO 646-BV）、（多くの場合、ISO 646-IRVとして参照）：IS 646は、実際には2つのコードテーブルが含まれてい全国での使用のための文字位置の数。
[CIDR] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[CIDR]フラー、V.、李、T.、ゆう、J.及びK. Varadhan、 "クラスレスドメイン間ルーティング（CIDR）：アドレス割り当ておよび集約戦略"、RFC 1519、1993年9月。
Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
ADDR.ARPA delegation", RFC 2317, March 1998.
[COM-SIZE] Size information supplied by Verisign Global Registry Services (the zone administrator, or "registry operator", for COM, see [REGISTRAR], below) to ICANN, third quarter 2002.
[COM-SIZE]ベリサイングローバル・レジストリサービスによって供給されるサイズ情報、第三四半期2002 ICANNに（COMのゾーン管理者、または "レジストリオペレータ"、以下、[REGISTRAR]を参照）。
[DNS-Search] Klensin, J., "A Search-based access model for the DNS", Work in Progress.
[DNS-検索] Klensin、J.、 "DNS検索ベースのアクセスモデル"、ProgressのWork。
[FINGER] Zimmerman, D., "The Finger User Information Protocol", RFC 1288, December 1991.
[FINGER]ジマーマン、D.、 "指のユーザー情報プロトコル"、RFC 1288、1991年12月。
Harrenstien, K., "NAME/FINGER Protocol", RFC 742,
December 1977.
[IAB-OPES] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[IAB-OPES]フロイド、S.とL. Daigle氏、 "オープン・プラグイン可能なエッジサービスのためのIAB建築・ポリシーに関する注意事項"、RFC 3238、2002年1月。
[IQUERY] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 2002.
[IQUERY]ローレンス、D.、RFC 3425、2002年11月 "IQUERYを時代遅れ"。
[IS646] ISO/IEC 646:1991 Information technology -- ISO 7-bit coded character set for information interchange
[IS646] ISO / IEC 646：1991情報技術 - 情報交換のためのISO 7ビット符号化文字集合
[IS10646] ISO/IEC 10646-1:2000 Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane and ISO/IEC 10646-2:2001 Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 2: Supplementary Planes
[IS10646] ISO / IEC 10646-1：2000情報技術 - ユニバーサルマルチオクテット符号化文字セット（UCS） - 第1部：アーキテクチャと基本多言語面およびISO / IEC 10646-2：2001情報技術 - 複数のユニバーサル-Octetコード化文字セット（UCS） - 第2部：補足プレーン
[MINC] The Multilingual Internet Names Consortium, http://www.minc.org/ has been an early advocate for the importance of expansion of DNS names to accommodate non-ASCII characters. Some of their specific proposals, while helping people to understand the problems better, were not compatible with the design of the DNS.
[MINC]多言語インターネット名・コンソーシアム、http://www.minc.org/は、非ASCII文字に対応するために、DNS名の拡大の重要性に対する早期提唱してきました。人々がよりよく問題を理解するために支援しながら彼らの具体的な提案のいくつかは、DNSの設計と互換性がありませんでした。
[NAPTR] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000.
【NAPTR] Mealling、M.およびR.ダニエル、 "命名権限ポインタ（NAPTR）DNSリソースレコード"、RFC 2915、2000年9月。
Mealling, M., "Dynamic Delegation Discovery System
(DDDS) Part One: The Comprehensive DDDS", RFC 3401,
October 2002.
Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート2：アルゴリズム"、RFC 3402、2002年10月。
Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート3：ドメインネームシステム（DNS）データベース"、RFC 3403、2002年10月。
[REGISTRAR] In an early stage of the process that created the Internet Corporation for Assigned Names and Numbers (ICANN), a "Green Paper" was released by the US Government. That paper introduced new terminology and some concepts not needed by traditional DNS operations. The term "registry" was applied to the actual operator and database holder of a domain (typically at the top level, since the Green Paper was little concerned with anything else), while organizations that marketed names and made them available to "registrants" were known as "registrars". In the classic DNS model, the function of "zone administrator" encompassed both registry and registrar roles, although that model did not anticipate a commercial market in names.
[REGISTRAR]割り当てられた名前と番号のためのインターネットコーポレーション（ICANN）を作成したプロセスの初期段階では、「グリーンペーパーは、」米国政府が発表しました。この論文は、新しい用語や伝統的なDNS操作が必要としないいくつかの概念を導入しました。 （グリーンペーパーは何も他と少し心配していたことから、一般的にトップレベルで）名前を販売し、それらを「登録」が利用できるように、組織があったが用語「レジストリ」は、ドメインの実際のオペレータとデータベースホルダーに適用されました「レジストラ」として知られています。そのモデルは、名前の商業市場を予想していなかったが、古典的なDNSのモデルでは、「ゾーン管理者」の機能は、レジストリとレジストラの役割の両方を包含されます。
[RFC625] Kudlick, M. and E. Feinler, "On-line hostnames service", RFC 625, March 1974.
[RFC625] Kudlick、M.とE. Feinler、 "オンラインのホスト名サービス"、RFC 625、1974年3月。
[RFC734] Crispin, M., "SUPDUP Protocol", RFC 734, October 1977.
[RFC734]クリスピン、M.、 "SUPDUPプロトコル"、RFC 734、1977年10月。
[RFC811] Harrenstien, K., White, V. and E. Feinler, "Hostnames Server", RFC 811, March 1982.
[RFC811] Harrenstien、K.、ホワイト、V.およびE. Feinler、 "ホスト名サーバー"、RFC 811、1982年3月。
[RFC819] Su, Z. and J. Postel, "Domain naming convention for Internet user applications", RFC 819, August 1982.
[RFC819]蘇、Z.およびJ.ポステルは、RFC 819、1982年8月、 "ドメインは、インターネットユーザアプリケーションのための命名規則"。
[RFC830] Su, Z., "Distributed system for Internet name service", RFC 830, October 1982.
[RFC830]蘇、Z.、RFC 830、1982年10月 "インターネットネームサービスのための分散システム"。
[RFC882] Mockapetris, P., "Domain names: Concepts and facilities", RFC 882, November 1983.
[RFC882] Mockapetris、P.、 "ドメイン名：概念と機能"、RFC 882、1983年11月。
[RFC883] Mockapetris, P., "Domain names: Implementation specification", RFC 883, November 1983.
[RFC883] Mockapetris、P.、 "ドメイン名：実装仕様"、RFC 883、1983年11月。
[RFC952] Harrenstien, K, Stahl, M. and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985.
[RFC952] Harrenstien、K、スタール、M.およびE. Feinler、 "DoDのインターネットホストテーブル仕様"、RFC 952、1985年10月。
[RFC953] Harrenstien, K., Stahl, M. and E. Feinler, "HOSTNAME SERVER", RFC 953, October 1985.
[RFC953] Harrenstien、K.、スタール、M.およびE. Feinler、 "ホストサーバー"、RFC 953、1985年10月。
[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月。
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[RFC1591]ポステル、J.、 "ドメインネームシステムの構造と委任"、RFC 1591、1994年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
"DNS仕様の明確化" [RFC2181]エルツ、R.とR.ブッシュ、RFC 2181、1997年7月。
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998
[RFC2295] Holtman、K.とA. MUTZ、 "HTTPにおける透明コンテントネゴシエーション"、RFC 2295、1998年3月
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年6月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]いるVixie、P.、 "DNS用拡張メカニズム（EDNS0）"、RFC 2671、1999年8月。
[RFC2825] IAB, Daigle, L., Ed., "A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols", RFC 2825, May 2000.
[RFC2825] IAB、Daigle氏、L.、エド、 "もつれたウェブ：I18N、ドメイン名、およびその他のインターネット・プロトコルの問題"。、RFC 2825、2000年5月。
[RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000.
[RFC2826] IAB、 "ユニークなDNS根のIAB技術コメント"、RFC 2826、2000年5月。
[RFC2972] Popp, N., Mealling, M., Masinter, L. and K. Sollins, "Context and Goals for Common Name Resolution", RFC 2972, October 2000.
[RFC2972] Poppの、N.、Mealling、M.、Masinter、LおよびK. Sollins、 "一般的な名前解決のための文脈と目標"、RFC 2972、2000年10月。
[RFC3305] Mealling, M. and R. Denenberg, Eds., "Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations", RFC 3305, August 2002.
[RFC3305] Mealling、M.とR. Denenberg、編、 "共同W3C / IETF URI計画インタレストグループからのレポート：ユニフォームリソース識別子（URI）、URL、およびユニフォームリソース名（URNの）：明確化と提言"。、 RFC 3305、2002年8月。
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, December 2002.
[RFC3439]ブッシュ、R.およびD.マイヤー、 "一部のインターネットの建築ガイドラインと哲学"、RFC 3439、2002年12月。
[Seng] Seng, J., et al., Eds., "Internationalized Domain Names: Registration and Administration Guideline for Chinese, Japanese, and Korean", Work in Progress.
[セン]セン、J.ら、編、「国際化ドメイン名：登録と中国語、日本語、韓国語のための管理ガイドライン」。。、進行中の作業。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings (stringprep)", RFC 3454, December 2002.
【STRINGPREP]ホフマン、P.及びM.ブランシェ、RFC 3454、2002年12月 "国際化された文字列（文字列準備）の調製"。
The particular profile used for placing
internationalized strings in the DNS is called
"nameprep", described in Hoffman, P. and M. Blanchet,
"Nameprep: A Stringprep Profile for Internationalized
Domain Names", Work in Progress.
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[TELNET]ポステル、J.、およびJ.レイノルズ、 "テルネットプロトコル仕様"、STD 8、RFC 854、1983年5月。
Postel, J. and J. Reynolds, "Telnet Option
Specifications", STD 8, RFC 855, May 1983.
[UNICODE] The Unicode Consortium, The Unicode Standard, Version 3.0, Addison-Wesley: Reading, MA, 2000. Update to version 3.1, 2001. Update to version 3.2, 2002.
[UNICODE]のUnicodeコンソーシアム、Unicode標準、バージョン3.0、アディソン・ウェスリー：バージョン3.2、2002年に読書、MA、バージョン3.1へアップデート2000年、2001年の更新。
[UTR15] Davis, M. and M. Duerst, "Unicode Standard Annex #15: Unicode Normalization Forms", Unicode Consortium, March 2002. An integral part of The Unicode Standard, Version 3.1.1. Available at (http://www.unicode.org/reports/tr15/tr15-21.html).
【UTR15]デイビス、M.およびM. Duerst、 "Unicode規格付属書＃15：Unicode正規化フォーム"、ユニコードコンソーシアム、2002年3月ユニコード規格、バージョン3.1.1の不可欠な部分。 （http://www.unicode.org/reports/tr15/tr15-21.html）でご利用いただけます。
[WHOIS] Harrenstien, K, Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985.
[WHOIS] Harrenstien、K、スタール、M.およびE. Feinler、 "NICNAME / WHOIS"、RFC 954、1985年10月。
[WHOIS-UPDATE] Gargano, J. and K. Weiss, "Whois and Network Information Lookup Service, Whois++", RFC 1834, August 1995.
[WHOIS-UPDATE]ガルガーノ、J.およびK.ワイス、 "Whoisのとネットワーク情報検索サービス、Whoisの++"、RFC 1834、1995年8月。
Weider, C., Fullton, J. and S. Spero, "Architecture of
the Whois++ Index Service", RFC 1913, February 1996.
Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, June 1997;
ウィリアムソン、S.、Kosters、M.、Blacka、D.、シン、J.及びK. Zeilstra、 "紹介フーイズ（RWhois）プロトコルV1.5"、RFC 2167、1997年6月。
Daigle, L. and P. Faltstrom, "The application/whoispp-query Content-Type", RFC 2957, October 2000.
Daigle氏、L.およびP. Faltstrom、 "アプリケーション/ whoispp-クエリのContent-Type"、RFC 2957、2000年10月。
Daigle, L. and P. Falstrom, "The application/whoispp-response Content-type", RFC 2958, October 2000.
Daigle氏、L.およびP. Falstrom、 "アプリケーション/ whoispp応答のコンテンツタイプ"、RFC 2958、2000年10月。
[X29] International Telecommuncations Union, "Recommendation X.29: Procedures for the exchange of control information and user data between a Packet Assembly/Disassembly (PAD) facility and a packet mode DTE or another PAD", December 1997.
[X29]国際Telecommuncations連合、「勧告X.29：パケット組み立て/分解（PAD）施設及びパケットモードDTEまたは別のパッドとの間の制御情報とユーザデータを交換するための手順」、1997年12月。
Many people have contributed to versions of this document or the thinking that went into it. The author would particularly like to thank Harald Alvestrand, Rob Austein, Bob Braden, Vinton Cerf, Matt Crawford, Leslie Daigle, Patrik Faltstrom, Eric A. Hall, Ted Hardie, Paul Hoffman, Erik Nordmark, and Zita Wenzel for making specific suggestions and/or challenging the assumptions and presentation of earlier versions and suggesting ways to improve them.
多くの人々は、この文書またはそれに入った思考のバージョンに貢献してきました。著者は特に、特定の提案を行うためのハラルドAlvestrand、ロブAusteinと、ボブブレーデン、ヴィントンサーフ、マット・クロフォード、レスリーDaigle氏、パトリックFaltstrom、エリックA.ホール、テッドハーディー、ポール・ホフマン、エリックNordmarkと、とジータヴェンツェルに感謝したいと/または仮定およびそれ以前のバージョンのプレゼンテーションに挑戦し、それらを改善する方法を示唆しています。
John C. Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140
ジョンC. Klensin 1770マサチューセッツアベニュー、＃322ケンブリッジ、MA 02140
EMail: klensin+srch@jck.com
メールアドレス：klensin+srch@jck.com
A mailing list has been initiated for discussion of the topics discussed in this document, and closely-related issues, at ietf-irnss@lists.elistx.com. See http://lists.elistx.com/archives/ for subscription and archival information.
メーリングリストはietf-irnss@lists.elistx.comで、この文書で説明する内容、及び密接に関連する問題の議論のために開始されました。サブスクリプションおよびアーカイブについてはhttp://lists.elistx.com/archives/を参照してください。
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。