[要約] RFC 3467は、DNSの役割と目的について説明したものであり、DNSの重要性と機能を理解するためのガイドラインです。
Network Working Group J. Klensin
Request for Comments: 3467 February 2003
Category: Informational
Role of the Domain Name System (DNS)
ドメイン名システムの役割（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.
Copyright（c）The Internet Society（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は、古い「ホストテーブル」システムの代替として設計されました。どちらもネットワーク（[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.
以下のコメントのいくつかは、多少修正主義者です。優れたデザインとエンジニアリングは、多くの場合、将来必要になるものについてデザイナーからのレベルの直感を必要とします。これらの設計上の決定のいくつかの理由は、誰もそれらを明確にすることができないため、当時明示的ではありません。以下の議論では、その後の開発と経験に照らして、インターネットの主要な名前空間（「class = in "dns）に関する決定のいくつかを再構築します。さらに、インターネットに関する特定の決定の歴史的な理由は、しばしば同時に重度の下院で記述されており、驚くことではなく、異なる参加者が何が起こったのか、何が重要だと考えられたかについて異なる回想を持っています。その結果、以下の準歴史的ストーリーは1つのストーリーにすぎません。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の出発後期間全体とインターネットの操作のほぼ10年ほどの間に、ホスト名のリストとアドレスとの間のマッピングは、頻繁に設定された「ホストテーブル」[RFC625に維持されました。]、[RFC811]、[RFC952]。名前自体は、印刷された形のあいまいさを避け、他の文字コーディングを使用してシステムとの相互操作を許可し、ISO 646の「国家使用」コードポジションを回避するために選択されたASCII [ASCII]のサブセットに限定されていました[IS6466]。これらの制限は、後に許可されたキャラクターである「Letter-Digit-Hyphen」の「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 さまざまなタイプの接続性とトポロジを反映するために、特定のホストに関連付けられた複数のアドレスを持つ機能を提供します。明示的なアドレスではなく、名前の使用は、ユーザーや他のホストがこれらの複数のホスト番号とアドレスを追跡するために存在する要件を回避しました。
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
o 追加サービスの追加の規定（たとえば、DNSの導入に続く電子メールルーティングの特別なレコードタイプ）、および
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.
別の仮定は、第2レベルのドメインに対する物理ホストの比率が高いことと、より一般的には、システムが深く階層的であり、ほとんどのシステム（および名前）が第3レベル以下で、非常に大きな割合であることを示しています。物理ホストを表す合計名。このモデルに従うドメインがあります。多くの大学や企業ドメインは、いくつかの国指向のトップレベルドメイン（「CCTLDS」）と同様に、かなり深い階層を使用しています。歴史的に、「私たち」。ドメインは、深く階層的なアプローチの優れた例です。ただし、1998年までに、DNSを調査するためのいくつかの努力の比較により、異なるホストの数に近づいた（そして合格した可能性がある）SOAレコードのカウントが示されました。別の方法で見ると、私たちは、インターネット上の委任されたドメインの数がホストの数に近づいているか、それを超えている状況、または少なくともネットワーク上の他の人にサービスを提供できるホストの数に移行しているように見えます。これは、おそらく、非常に多くの名前を少数のホストにマッピングする同義語またはエイリアスから生じると思われます。これまでの経験は、DNSがサーバーと現在の帯域幅の規範として現代の機械を考えると、十分に堅牢であることを示しています。1,000万件を超える委任されたサブドメイン[comsize]）を含む「.com」の下の構造、システムが深く階層的なゾーンではなく、フラット構造（および非常に大きなゾーン）で最適に動作するように設計されている可能性があることを覚えておくと便利です。、そしてそうではありませんでした。
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.
同様に、人々の名前と電子メールアドレスをDNSに直接入力することについてのいくつかの早期の推測にもかかわらず（例：[RFC1034]を参照）、インターネットの電子メールアドレスは、オリジナルのPre-DNS「ユーザー（またはメールボックス）」を保持しています。平らまたは厳密にドットセパートされたものではなく、概念的な形式。その場合、場所はホストへの参照です。少なくとも「in」クラスの唯一の例外は、SOAレコードの1つの分野です。
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 Protocol [Finger]を参照）も、実際のホストに対するユーザーの比較的高い比率を予想していました。DNSがユーザー数に比例すると予想されているRFC 1034での観察にもかかわらず（セクション2.3）、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は、「単一のインターネット」と「エンドツーエンド」モデルの一部として、名前に対して重要な一意性と普遍的なアクセシビリティを提供しました（cf.
[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デザインの決定は、いくつかの点で深刻な間違いであることが証明されています。タイピングの利便性と、簡単に記憶された製品名からドメイン名を作成したいという欲求は、DNSの平坦化につながり、多くの人々が現在、COM（または一部の国、2番目または3番目の国でその2番目の名前を認識しています。 - 関連するcctldの下のレベルの名前）は意味があります。この認識は、追加名を「販売」することを切望しているドメイン名レジストラ[レジストラ]によって強化されています。そして、もちろん、ネットワークリソースの（通常組織的な）コレクションに関連付けられた名前を持つのではなく、製品ごとに2番目のレベルの（またはトップレベル）ドメインが必要だという認識は、数の急速な加速をもたらしました。登録されている名前の。その加速により、名前ごとに請求するレジストラが「サイバースコッター」、および名前を「販売」するビジネスの他の人に明らかに利益を得ましたが、インターネット全体に明らかに利益を得ていません。
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.
これらの社会政治的問題とは無関係に、コンテンツの分布の問題により、組織がネットワーク内で利用可能に分配したいデータのコピーを持つことが可能であるべきであることが明らかになりました。最も近いコピー。これは、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は、この悲観的な解釈の一部のイラストであり、例外です。これは第2世代の開発であり、ホストテーブルシステムはその耐用年数の終わりに見られていました。当時のコンピューティング最先端を反映しようとする深刻な試みがありました。ただし、展開は予想よりもはるかに遅く（多くのサイトで非常に苦痛）、展開が発生するためには中央ネットワーク管理からの締め切りが必要でした（数回リラックスしていますが）。機能を追加するために、少なくとも合理的にうまく機能し続けている間、機能を追加するために、おそらく非常に困難な場合があります。
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の展開を妨げる要因の1つであると信じる理由があります。
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は特定のホストに関連付けられた多くの名前を特にうまく処理しません（例えば、Webホスティングファシリティサーバー上の複数のドメイン）。
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名が商標の戦場に変わりました。（少なくとも）ほとんどの国の従来の商標システムは、適用の分野について慎重に区別しています。地理や産業部門のいずれにおいても差別化されずにスペースが平らになった場合、「ジョーのピザ」（ボストンの）と「ジョーのピザ」（サンフランシスコの）の間に紛争があるだけでなく、両方と「ジョーの自動修理」（ジョーの自動車修理」（ロサンゼルスの）。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サイトを持ちたいと考えています。これは、ローカルバリエーションを作成することです。ウィジェット会社は、米国のユーザーと比較して英国のユーザーに異なる素材を提示することをお勧めします。また、ユーザーに最も近いサーバーから情報を提供することにより、より高いパフォーマンスを提供することもあります。名前解像度メカニズムがこの機能を提供すると予想される場合、3つの可能なモデル（組み合わせる可能性があります）があります。
- 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接続を最初に「共通」または「プライマリ」ホストに開いて、好みを交渉して交渉し、次に、クライアントが代替データをリダイレクトまたは送信しました。少なくとも、「より近い」場所にアクセスすることでパフォーマンスを改善する観点からは、最初とその後の両方で、このアプローチは、クライアントがアクションを開始する前に望ましい結果を犠牲にします。一般的なコンテンツネゴシエーションアプローチの特性のいくつかは、Web 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は、1つの（非常に硬い）一致するルールのセットのみに対応できます。さまざまな地域でさまざまなルールを許可する提案（たとえば、TLDまたはゾーン固有のルールを一致させる）は、問題を特定するのに役立ちます。ただし、望ましいレベルの柔軟性を放棄したり、インターネットのさまざまな部分を互いに（またはその両方）分離することなく、DNSに直接適用することはできません。ファジーまたはあいまいな検索は、スペルのバリエーションを持つ可能性のある名前の解決や、コンテキストに応じてさまざまなグリフのセットに解決できる名前の解決に望ましい。特に、国際化を考慮すると、バリアント名の問題は、文字の表現または文字列の注文における単純な違いを超えています。代わりに、ユーザーの驚きと混乱を回避するには、さまざまなアルファベット、漢字関係、単純化された伝統的な中国語などで書くことができる言語などの関係を考慮する必要があります。これらの問題のサブセットに対処するための議論と提案については[seng]を参照してください中国のキャラクターに基づく文脈において。しかし、そのドキュメントは、ユーザーが予想される柔軟なマッチングの種類を提供することの難しさを本質的に示しています。代わりに、最悪の種類の混乱（および詐欺の機会）から保護しようとします。
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.
o さまざまなマルチキャラクターセットおよび多言語「国際化」システムで使用するメカニズムを追加するメカニズムを追加することを考慮した場合、それがどのように機能するかについて仮定を立てる歴史的なDNS、およびそれが重大なリスク（またはその結果として生じる奇妙な制限）を課すアプリケーション。詳細については、これらの問題のいくつかに関するIABの議論[RFC2825]を参照してください。
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]、[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.
o 最後に、追加の種類の個人情報または識別情報がDNSに追加されると、その情報の保護により問題が発生します。照会のソースの資格と承認に基づいて、さまざまな情報を利用できるようにするための呼び出しが増えています。サイトの場所や近接性（上記で説明したように）に鍵をかけている情報と同様に、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.
上記の問題のいくつかは、優れたディレクトリシステム（LDAPプロトコルまたはこれらの特定のアプリケーションにより正確に適したプロトコルでサポートされている）または検索環境（一般的なWeb検索エンジンなど）によって適切に対処されていますが、DNSではありません。上記の新しいアプリケーションを展開することの難しさを考えると、重要な質問は、トリックとKludgesが十分に悪いか、使用が成長するにつれて十分に悪くなるかどうか、新しいソリューションが必要であり、展開できるかどうかです。
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の制約と上記の議論は、以下に「検索レイヤー」または「検索可能なシステム」と呼ばれる中間プロトコルメカニズムの導入を示唆しています。「ディレクトリ」と「ディレクトリシステム」という用語は、このドキュメントの「検索可能なシステム」と同じ意味で使用されますが、後者ははるかに正確です。検索レイヤーの提案は、DNSの国際化された名前の提案のいくつかとは異なり、2つ（またはそれ以上）のステージルックアップを使用します（セクション4を参照）が、最終操作以外のすべての操作には、識別子を検索するのではなく、他のシステムの検索が含まれます。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パッチ、Kludges、または回避策ではなく、検索可能なシステムであることを示唆しています。
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 ディレクトリシステムでファジーと「ソネックス」（同様のサウンド）マッチングを行う際に、かなりの経験があります（あまり成功していませんが）。さらに、さまざまな領域や名前のセットのさまざまなマッチングルールについて考えることができ、これらを地元の文化的要件に適合させることができます。具体的には、ディレクトリに単一のフォームの名前を持つことが可能かもしれませんが、その名前と一致するクエリについて大きな柔軟性を持つことができます（そして、異なる領域で異なるバリエーションさえ持っています）。もちろん、システムが提供する柔軟性が高いほど、実際の商標または想像上の商標紛争の可能性が高くなります。しかし、これらの問題をインテリジェントな方法で扱うディレクトリ構造を設計する機会は存在しますが、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名がホストを一意に識別する（続行）するため、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 単一の名前ではなく、ネットワークロケーション情報またはその他のコンテキスト確立属性とペアになった名前のセットを返すディレクトリシステムを設計できます。このタイプの情報は、Webをホストしている組織や幅広い場所やサブネットからアクセスされる他のサイトにとって重要な懸念事項である特定の名前のリソースの「最も近い（または最良の）サーバー」の問題を解決するのに非常に役立つ可能性があります。
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にある、またはMapの名前のほぼすべての国際化提案では、DNS Resolver API呼び出し（「GethostbyName」または同等）の変更が必要です。APIは、別の文字セットを取得します（どのようにDNSまたは別のシステムで使用されるビットにマッピングされても）。このような変更を加えるためにアプリケーションを開いた後、DNSへの呼び出しからディレクトリサービスの呼び出しに切り替えることは比較的小さな問題であり、次にDNS（多くの状況では、両方のアクションを1回の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-Search]を参照してください。）
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).
上記の議論には属性に関する非常に一般的なコメントが含まれていますが、非常に少数の属性のみが必要であると思われます。このリストには、ほぼ確実に国際化の目的で国と言語が含まれます。キャラクターセットとエンコードに同意できない場合は「charset」が必要になる場合がありますが、単にISO 10646（Unicodeまたは "UCS"（普遍的な文字セットの場合）とも呼ばれます[Unicode]、[IS10646]コーディングを使用するための強力な議論があります。インターチェンジでは、商標問題は、商標の問題をバイパスするのに役立つ場合、「コマーシャル」および「非営利」（または他の）の属性を動機付ける可能性があります。、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の国際化の考慮事項、またはより具体的には、言語からのDNSの機能へのアクセスを提供し、ASCIIの従来の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).
70年代半ばに選ばれたホスト名のルールは、英語がASCIIを使用するため、ASCIIだけではありませんでしたが、それは出発点でした。ISO 646国際参照バージョンで指定されている残りの文字を許可する場合、他のほぼすべてのスクリプト（およびASCIIでさえ）がHostname-Restricted-Ascii（「LDH」フォーム、セクション1.1を参照）よりも複雑であることを発見しました。また、ASCIIは英語を完全に表現するのに十分ではありません。言語には、ASCIIには表示されない文字や異文性マークでのみ正しく綴られている言葉がいくつかあります。より幅広いスクリプトの選択により、例では、ケースマッピングが1つのケースから別のケースに機能しますが、可逆的ではありません。他の人には、ほとんどの場合ではなく、常にではなく機能するキャラクター（文字コーディングのみではなく）を表現する代替方法についての規則があります。また、コーディングには問題があります。Unicode/10646は、同じ文字を表現するさまざまな方法を提供します（「Glyph」ではなく「文字」が意図的にここで使用されます）。そして、さらに他の人には、2つのグリフが「一致する」かどうかについての質問があります。これらの問題に対するIETFアプローチは、事前に一致する標準化を必要とすることです（以下の「stringprep」の説明を参照）。
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は、完全に新しいコード化された文字セットを指定しようとするか、明確に定義されたブロックを使用するのではなく、CharacterベースでUnicode/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 Internationalizationの作業は、「ASCII互換のエンコーディング」（ACE）に焦点を当てています。これらのエンコーディングは、DNS自体のLDH規則を保持します。アップグレードされていないアプリケーションの実装は、エンコードされたフォームを使用しますが、新しいものを作成して、特別なコーディングを認識して非ASCII文字にマッピングできます。ただし、これらのアプローチは、人間のインターフェイスの問題が無視されていても、問題のないものではありません。他の問題の中でも、彼らは、DNSラベルが国際化された名前（つまり、エンコードされたユニコード）と見なされるか、それ自体が実際の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.
StringPrepの根底にある一般的な概念は単純ですが、多くの詳細は非常に微妙であり、関連するトレードオフは複雑です。デザインチームは、プロトコルとテーブルを明確にして微調整するためにかなりの努力を払って、数ヶ月間それに取り組みました。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:
また、準備と変換のこれらのプロセスにおいてどこまで進むべきか、そして最終的にはさまざまな類推の妥当性についても論争がありました。たとえば、次の各操作は、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の他の作業は完全に放棄されたか、市場で失敗した場合でも、StringPrepとNamePrepの作業は、問題と問題コードポイントを特定し、合理的な一連のセットを提供することで、引き続き非常に有用です。基本的なルール。問題が残っている場合、それらは間違いなくNAMEPREPではなく、一致および比較プロセスの他のすべての部分と同様に、その結果がバイナリの「一致または一致しない」答えを得るという結果を課しています。ユーザーまたはユーザー駆動型ヒューリスティック関数が評価できる類似性スケールの値。
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の作品に伴う長年の伝統の一部です。コードポイント割り当てを実行し、通常、キャラクターが範囲を超えて使用される方法を扱いました。その結果、彼らはより広範な国際化の問題に効果的に対処していません。対照的に、Unicode Technical Committee（UTC）は、付属書および技術レポート（例えば[UTR15]を参照）で、標準化と比較のためのいくつかの追加のルールを定義しています。これらのルールと慣習の多くは、「stringprep」および「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の定義が不十分であるため、正確かつ明確にするいくつかの領域を特定しました。これらの場合には、Unicode標準では、いくつかの代替アプローチが許可されていますが、どれもDNSニーズに正確かつ明らかな一致するものではありません。これにより、これらのデリケートな選択肢は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の実装モデルと解像度モデルの不安定性を引き起こす問題を引き起こす可能性があるかどうかという2つの問題が発生します。。
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.
ユニコード定義も進化します。バージョン3.2は、このドキュメントの作業が開始された直後に登場しました。いくつかの文字と機能を追加し、いくつかのマイナーな互換性のないコードポイントの変更を含めました。IETFは、将来の変更に関する制約に関する合意を確保していますが、その合意が実際にどのように機能するかはまだわかりません。UTCは契約によって禁止されるべきである最近の可能な変更を投票することを選択したため、この段階では予後は実際には不十分に見えます（投票の結果は関連性がありません。結論）。ただし、コミュニティの一部のメンバーは、Unicode 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.
o 「彼らは私たちの慣習に慣れ、適応する」という原則は、プログラミング言語またはAPIのルールを書いている場合は問題ありません。しかし、議論中の慣習は半数学システムの一部ではなく、文化に深く染み込んでいます。英語を話すアメリカ人が、インターネットが「色」の正しい綴りを使用することを要求すると言われていても、彼または彼女は確信することはありません。リヨンでフランス語を話す人に、IETFまたはレジストラまたはレジストリの決定に対応するために、ケベックのフランス語スピーカーとまったく同じ語彙的慣習を使用することはおそらくありません。「モントリオール」とは、「E」上の急性アクセントマークを持つ同様の単語のスペルミスまたは英語化のいずれかです（つまり、Unicode文字u 00e9またはその同等物の1つを使用）。しかし、2つのフォームが一致すべきかどうかを決定するルールに関するグローバルな合意 - それは、いずれかの言語のエンドユーザーとスピーカーを驚かせることはありませんが、「スペルミス」または「角度化」があるかどうかについての合意と同じくらいありそうもないより大きな悲劇。
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 00f8に登場するノルウェー/デンマークのキャラクター（視覚的には、順方向のスラッシュで「o '' 'ownstruck）とu 00f6に登場する「o-umlaut」ドイツのキャラクター（視覚的には、diaeresisを伴う小文字」（またはumlaut））は明らかに異なり、一致するプログラムは「等しい」比較をもたらす必要はありません。しかし、それらは、たとえば「e」のいずれかよりも、お互いに似ています。人間は文脈で精神的に修正を行うことができ、簡単にそうすることができ、コンピューターがそうすることができない場合は驚くことがあります。さらに悪いことに、スウェーデンのキャラクターがドイツ語のO-Umlautと同一であり、コードポイント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つは、上記の問題と同様の問題がほぼすべての言語とスクリプトに存在することです。それぞれにその特異性があり、それぞれの特異性は、関連するグループで非常に馴染みのある一般的な使用法と文化的問題に結び付けられており、しばしば文化的価値として深く保持されています。米国の学童が完全に有効な英国のスペルを使用するためのスペルテストで悪い成績を取得できる限り、またはフランスやドイツのスペルを使用することができます。。同様に、エジプトまたはイスラエルの子どもたちが、母音やストレスマークの有無にかかわらず単語を書くことは許容されないことを教えられている場合、それらのマークが含まれている場合、正しいものである必要があります。または、JAMOのオーダーアウトシーケンス、時刻の処理と単純なマッチングに基づくシステム、コンテキスト情報のないシステムに驚かされ、ユーザーのニーズを満たすことはできません。
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.
過去数世紀にわたって、多言語の状況に対処するために、世界のさまざまな地域で地元の慣習が確立されてきました。これらのいくつかを調べると役立つかもしれません。たとえば、言語が自分の言語とは異なる国を訪れた場合、名刺はしばしば両側に片側に印刷されます。慣習は完全に一貫しているわけではなく、テクニックは受信者が寛容であると想定しています。名前や場所の翻訳は、他の状況や音訳で試みられます。正確な翻訳や音訳はしばしば不可能であることが広く理解されているため、人々は通常、エラーに微笑み、努力を高く評価し、先に進みます。
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ベースの名前に遭遇すると、（確かにugい）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に関する「今すぐフリーズし、これらの領域の変更は必要ありません」という決定を下すことができます。そのエースは、ローマベースのグリフをキーまたはレンダリングする能力を持たない環境であっても、アプリケーションの問題を滑らかにします（または、ユーザーエクスペリエンスは、そのようなグリフを互いに簡単に区別できないようなものです）。Unicodeコンソーシアムは、DNSの非互換性のリスクを生み出す方法でエラーを修復することを決して決定しないこと。EDNS [RFC2671]を展開できるか、その長い名前が実際に重要ではないこと。日本と中国のコンピューターユーザー（およびその他）がローカルを放棄するか、2022ベースの文字コーディングソリューション（ユニコードへの100万の新しいコードポイントの追加がほぼ確実に必要ですが、おそらく十分ではないということです。、条件）または漏れ防止および完全に正確な境界変換メカニズムを構築します。バンドの外またはコンテキスト情報は、「スクリプトにグリフをマップする」問題に常に十分です。等々。いずれの場合も、症例の約80％または90％が十分に機能する可能性がありますが、そのような部分的な解決策が十分である可能性は低いです。たとえば、誰かが彼女の名前を90％正しく綴ることができるか、会社名が正しく一致していると仮定しますが、他の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]がより小さなアドレスブロックを意味のある名前にマッピングするのに問題があることが証明されているためです。
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.
地元系の検索とマッピングは、他の文字列と一致する文字列の解釈に関する国家のバリエーションを可能にします。これは、異なる局所が異なるルールを適用する場合に特に重要な配置を可能にします。しかし、もちろん、これは、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自体と同じように不正な変更に対して慎重に保護される必要があります。また、特にそのようなシステムが中央の権限や名前の一意性なしで設計されている場合、2つ以上の（サブ）レイヤーを含む配置に問題の新しい機会があるかもしれません。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. Liu、DNS and 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] American National Standards Institute（旧アメリカ合衆国標準研究所）、X3.4、1968、「情報交換のための米国コード」。ANSI X3.4-1968は、わずかな変更で新しいバージョンに置き換えられましたが、1968年のバージョンはインターネットにとって決定的なままです。ASCIIが最初に標準として策定された後、ISOはASCIIをベースとして使用する国際標準646を採用しました。IS 646には実際には2つのコードテーブルが含まれていました。「国際参照バージョン」（多くの場合、ISO 646-IRVと呼ばれることが多い）と、当時のASCIIと本質的に同一でした。全国使用のための文字位置の数。
[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] Fuller、V.、Li、T.、Yu、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.
Eidnes、H.、de Groot、G。およびP. Vixie、「クラスレスIn-Addr.Arpa Delegation」、RFC 2317、1998年3月。
[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] Verisignグローバルレジストリサービス（ゾーン管理者、または「レジストリオペレーター」、com、[レジストラ]、以下の[レジストラ]、以下を参照）によって提供されるサイズ情報。2002年第3四半期。
[DNS-Search] Klensin, J., "A Search-based access model for the DNS", Work in Progress.
[DNS-Search] Klensin、J。、「DNSの検索ベースのアクセスモデル」、進行中の作業。
[FINGER] Zimmerman, D., "The Finger User Information Protocol", RFC 1288, December 1991.
[指] Zimmerman、D。、「The Fingerユーザー情報プロトコル」、RFC 1288、1991年12月。
Harrenstien, K., "NAME/FINGER Protocol", RFC 742, December 1977.
Harrenstien、K。、「名前/指プロトコル」、RFC 742、1977年12月。
[IAB-OPES] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[IAB-Opes] Floyd、S。およびL. Daigle、「Open Pluggable Edge ServicesのIAB建築および政策上の考慮事項」、RFC 3238、2002年1月。
[IQUERY] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 2002.
[iquery]ローレンス、D。、「廃止Iquery」、RFC 3425、2002年11月。
[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
[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。and R. Daniel、「The Naming Authority Pointer（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 Delogation Discovery System（DDDS）パート1：包括的なDDDS」、RFC 3401、2002年10月。
Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
Mealling、M。、「Dynamic Delogation Discovery System（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。、「Dynamic Delogation Discovery System（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.
[レジストラ]割り当てられた名前と数字（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] Crispin、M。、「Supdup Protocol」、RFC 734、1977年10月。
[RFC811] Harrenstien, K., White, V. and E. Feinler, "Hostnames Server", RFC 811, March 1982.
[RFC811] Harrenstien、K.、White、V。およびE. Feinler、「Hostnames Server」、RFC 811、1982年3月。
[RFC819] Su, Z. and J. Postel, "Domain naming convention for Internet user applications", RFC 819, August 1982.
[RFC819] Su、Z。およびJ. Postel、「インターネットユーザーアプリケーションのドメイン命名規則」、RFC 819、1982年8月。
[RFC830] Su, Z., "Distributed system for Internet name service", RFC 830, October 1982.
[RFC830] Su、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、Stahl、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.、Stahl、M。およびE. Feinler、「Hostname Server」、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] Postel、J。、「ドメイン名システム構造と委任」、RFC 1591、1994年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、RFC 2181、1997年7月。
[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] Berners-Lee、T.、Fielding、R。and L. Masinter、「Uniform Resource Identiers（URI）：Generic Syntax」、RFC 2396、1998年8月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608] Guttman、E.、Perkins、C.、Veizades、J。and M. Day、「サービスロケーションプロトコル、バージョン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.、ed。、「Tangled Web：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。and 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。and R. Denenberg、eds。、「共同W3C/IETF URI計画関心グループからのレポート：ユニフォームリソース識別子（URI）、URL、およびユニフォームリソース名（URNS）：明確化と推奨事項」、RFC 3305、2002年8月。
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, December 2002.
[RFC3439] Bush、R。およびD. Meyer、「いくつかのインターネットアーキテクチャガイドラインと哲学」、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.
[Seng] Seng、J.、et al。、eds。、「国際化されたドメイン名：中国語、日本、韓国語の登録および管理ガイドライン」、進行中の作業。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings (stringprep)", RFC 3454, December 2002.
[StringPrep] Hoffman、P。およびM. Blanchet、「国際化された文字列の準備（StringPrep）」、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.
DNSに国際化された文字列を配置するために使用される特定のプロファイルは、「NamePrep」と呼ばれ、Hoffman、P。およびM. Blanchet、「NamePrep：国際化ドメイン名のStringPrepプロファイル」で説明されています。
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[Telnet] Postel、J。およびJ. Reynolds、「Telnetプロトコル仕様」、STD 8、RFC 854、1983年5月。
Postel, J. and J. Reynolds, "Telnet Option Specifications", STD 8, RFC 855, May 1983.
Postel、J。およびJ. Reynolds、「Telnetオプション仕様」、STD 8、RFC 855、1983年5月。
[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 Consortium、Unicode Standard、バージョン3.0、Addison-Wesley：Reading、MA、2000。バージョン3.1、2001の更新。バージョン3.2、2002の更新。
[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] Davis、M。and M. Duerst、「Unicode Standard Annex＃15：Unicode Normization Forms」、Unicode Consortium、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、Stahl、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] Gargano、J。およびK. Weiss、「Whois and Network Information Lookup Service、Whois」、RFC 1834、1995年8月。
Weider, C., Fullton, J. and S. Spero, "Architecture of the Whois++ Index Service", RFC 1913, February 1996.
Weider、C.、Fullton、J。およびS. Spero、「Whois Index Serviceのアーキテクチャ」、RFC 1913、1996年2月。
Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, June 1997;
Williamson、S.、Kosters、M.、Blacka、D.、Singh、J。and K. Zeilstra、「紹介Whois（rwhois）Protocol 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、「The Application/Whoispp-Queryコンテンツタイプ」、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]国際電気通信ユニオン、「推奨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.
多くの人々が、このドキュメントのバージョンやそれに入った考えに貢献しています。著者は、特に、ハラルド・アルベスランド、ロブ・オーストイン、ボブ・ブレイデン、ヴィントン・ケルフ、マット・クロフォード、レスリー・デイグル、パトリック・ファルトストローム、エリック・A・ホール、テッド・ハーディ、ポール・ホフマン、エリック・ノードマーク、Zitaウェンゼルに、特定の提案とZita Wenzelに感謝したいと思います。/または、以前のバージョンの仮定とプレゼンテーションに挑戦し、それらを改善する方法を提案します。
John C. Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140
ジョンC.クレンシン1770マサチューセッツアベニュー、＃322ケンブリッジ、マサチューセッツ州02140
EMail: 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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。