RFC3467 日本語訳
3467 Role of the Domain Name System (DNS). J. Klensin. February 2003. (Format: TXT=84570 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Klensin Request for Comments: 3467 February 2003 Category: Informational
Klensinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 3467 2003年2月のカテゴリ: 情報
Role of the Domain Name System (DNS)
ドメインネームシステムの役割(DNS)
Status of this Memo
この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)インターネット協会(2003)。 All rights reserved。
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
1. 序論と歴史… 2 DNS開発のための1.1文脈… 3 1.2 DNSのレビューと設計されるとしてのその役割… 4 1.3 ウェブと目に見えるユーザドメイン名… 6 1.4 インターネットアプリケーションプロトコルとそれらの発展… 7 2. DNS積みすぎのサイン… 8 3. 探すこと、ディレクトリ、およびDNS… 12 3.1概要… 12 3.2 いくつかの詳細とコメント… 14 4. 国際化… 15 4.1 ASCIIは英語のジャスト・ビコーズではありません… 16 4.2 「ASCIIコード化」にアプローチします… 17 4.3 "Stringprep"とその複雑さ… 17 4.4 ユニコード安定問題… 19 4.5人の聴衆、エンドユーザ、およびユーザーインタフェース問題… 20 自然言語の4.6個の名刺と他の自然な用途。 22 4.7 ASCII Encodingsとローマキーボード仮定… 22
Klensin Informational [Page 1] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[1ページ]のRFC3467の役割
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
4.8 イントラ-DNSは「多言語名前」のためにアプローチします… 23 5. 検索ベースのシステム: 主要な論争… 23 6. セキュリティ問題… 24 7. 参照… 25 7.1 標準の参照… 25 7.2 説明していて有益な参照… 25 8. 承認… 30 9. 作者のアドレス… 30 10. 完全な著作権宣言文… 31
1. Introduction and History
1. 序論と歴史
The DNS was designed as a replacement for the older "host table" system. Both were intended to provide names for network resources at a more abstract level than network (IP) addresses (see, e.g., [RFC625], [RFC811], [RFC819], [RFC830], [RFC882]). In recent years, the DNS has become a database of convenience for the Internet, with many proposals to add new features. Only some of these proposals have been successful. Often the main (or only) motivation for using the DNS is because it exists and is widely deployed, not because its existing structure, facilities, and content are appropriate for the particular application of data involved. This document reviews the history of the DNS, including examination of some of those newer applications. It then argues that the overloading process is often inappropriate. Instead, it suggests that the DNS should be supplemented by systems better matched to the intended applications and outlines a framework and rationale for one such system.
DNSは、より古い「ホストテーブル」システムとの交換として設計されました。 両方が(IP)アドレスをネットワークでつなぐより抽象的なレベルで名前をネットワーク資源に供給することを意図しました(見てください、例えば、[RFC625]、[RFC811]、[RFC819]、[RFC830]、[RFC882])。 近年、DNSはインターネットのための便利に関するデータベースになりました、新機能を加えるという多くの提案で。 これらの提案のいくつかだけがうまくいっています。 DNSを使用することに関する主な(単に)動機は、しばしば、存在しているのによるである広く配布されます、データのかかわった特定用途に、現体制、施設、および内容が適切であるからであるというわけではありません。 このドキュメントはそれらのいくつかの、より新しいアプリケーションの試験を含むDNSの歴史を再検討します。 そして、それは、積みすぎプロセスがしばしば不適当であると主張します。 代わりに、それは、DNSが意図しているアプリケーションに合わせられるほうがよかったシステムによって補われるべきであると示唆して、そのようなシステムの1つのためにフレームワークと原理について概説します。
Several of the comments that follow are somewhat revisionist. Good design and engineering often requires a level of intuition by the designers about things that will be necessary in the future; the reasons for some of these design decisions are not made explicit at the time because no one is able to articulate them. The discussion below reconstructs some of the decisions about the Internet's primary namespace (the "Class=IN" DNS) in the light of subsequent development and experience. In addition, the historical reasons for particular decisions about the Internet were often severely underdocumented contemporaneously and, not surprisingly, different participants have different recollections about what happened and what was considered important. Consequently, the quasi-historical story below is just one story. There may be (indeed, almost certainly are) other stories about how the DNS evolved to its present state, but those variants do not invalidate the inferences and conclusions.
続くいくつかのコメントがいくらか修正主義者です。 良いデザインと工学はしばしば将来必要になるものに関してデザイナーによる直観のレベルを必要とします。 だれもそれらについて明確に話すことができないので、これらのデザイン決定のいくつかの理由を当時、明白にしません。 以下での議論はその後の開発と経験の見地からインターネットのプライマリ名前空間(「クラス=IN」DNS)に関する決定のいくつかを再建します。 さらに、インターネットに関する特定の決定の歴史的な理由は同時にしばしば厳しくunderdocumentedされました、そして、当然ながら異なった関係者には、何が起こったか、そして、何が重要であると考えられたかに関して異なった回想があります。 その結果、以下の準歴史的な話はちょうど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]).
このドキュメントはRFC1034[RFC1034]の用語かどんな良いDNSチュートリアルの一般的な意味解釈も推定します(見てください、例えば、[Albitz])。
Klensin Informational [Page 2] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[2ページ]のRFC3467の役割
1.1 Context for DNS Development
1.1 DNS開発のための文脈
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:
アルパネットの全体のポスト始動の期間の寿命とほとんどインターネットの操作の最初のおよそ10年間、ホスト名のリストとアドレスとアドレスからのそれらのマッピングは頻繁にアップデートされた「ホストテーブル」[RFC625]で維持されました、[RFC811]、[RFC952。] 印刷された用紙であいまいさを避けて、システムで他のキャラクタコーディング(著しくEBCDIC)を使用することでinteroperationを可能にして、コードが置くISO646[IS646]の「国家の使用」を避けるために選ばれて、名前自体はASCII[ASCII]の部分集合に制限されました。 後で"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 人々がホスト番号(アドレス)を覚えているという要件を排除してください。 それと反対な従来の電話、数値ホスト番号戦略を含む数値付番システムの見かけの経験にもかかわらず、(and do not)はホストの(大きい)の一握り以上でうまくいきませんでしたか?
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 アドレスが変化したときには安定性を提供してください。 アドレス--アルパネットに現代のインターネット--接続性であるときに、ネットワーク形態とルーティングの機能であり、しばしばそれらを変えなければならなかったということであるかトポロジーで、より重要にある程度変えて以来。 アドレスが変化するとすぐに、名前を安定しているように保つことができました。
o Provide the capability to have multiple addresses associated with
a given host to reflect different types of connectivity and
topology. Use of names, rather than explicit addresses, avoided
the requirement that would otherwise exist for users and other
hosts to track these multiple host numbers and addresses and the
topological considerations for selecting one over others.
o 与えられたホストに関連している複数のアドレスを持つ能力を提供して、異なったタイプの接続性とトポロジーを反映してください。 名前の使用は、他のものの上の1つを選択するために明白なアドレスよりむしろそうでなければユーザと他のホストがこれらの複数のホスト番号とアドレスを追跡するように存在する要件と位相的な問題を避けました。
After several years of using the host table approach, the community concluded that model did not scale adequately and that it would not adequately support new service variations. A number of discussions and meetings were held which drew several ideas and incomplete proposals together. The DNS was the result of that effort. It continued to evolve during the design and initial implementation period, with a number of documents recording the changes (see [RFC819], [RFC830], and [RFC1034]).
ホストテーブルアプローチを使用した数年の後に、共同体はモデルが適切に比例しないで、また新しいサービスが変化であると適切にサポートしないと結論を下しました。 いくつかの考えと不完全な提案を接近させた多くの議論と会合が行われました。 DNSはその取り組みの結果でした。 それは、デザインと初期の実装の期間、発展し続けていました、多くのドキュメントが変化を記録していて([RFC819]、[RFC830]、および[RFC1034]を見てください)。
Klensin Informational [Page 3] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[3ページ]のRFC3467の役割
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デザインはむしろ名前管理の分配を可能にしました。
1.2 Review of the DNS and Its Role as Designed
1.2 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は、ネットワーク資源を特定するように設計されました。 含んでいて、例えば、個人的な名前とEメールアドレスに関する思惑がありましたが、それは、主として人々、ブランドなどを特定するように設計されませんでした。 同時に、システムは、初期の「インターネット」のクラスへの新しいレコード種類の追加を通して潜在的に新しいクラスの導入を通して新しいデータ型と構造に対応するように柔軟性で設計されました。 それらの今後の拡大の適切な識別子と内容を予期できなかったので、デザインはこれらの分野であればホストテーブルの制限されたテキストフォームだけではなく、どんな(2進)の情報も含むかもしれません。
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、しかし、特に、どんな2進法表示にも対応するためには、それ(オリジナルホストテーブルから命名規則を引き出す部分集合)の非常に制限された部分集合でした。 その部分集合の選択は人間の要素問題によって一部動かされました、国際的な関係に可能なあいまいさを排除する願望を含んでいて。 したがって、解釈の国際的な変化を持っていたキャラクタコードが除かれて、強調キャラクタとケース区別は、書かれると混乱させているとして(ハイフンキャラクタを伴う強調の場合で)根絶されたか、または人々などで読みます。 これらの問題は同様に制限された文字集合をもたらしたものとプロトコル要素として多くのITUとISOプロトコルに使用されることで非常に同様であるように見えます。(Cf。 [X29]).
Klensin Informational [Page 4] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[4ページ]のRFC3467の役割
Another assumption was that there would be a high ratio of physical
hosts to second level domains and, more generally, that the system
would be deeply hierarchical, with most systems (and names) at the
third level or below and a very large percentage of the total names
representing physical hosts. There are domains that follow this
model: many university and corporate domains use fairly deep
hierarchies, as do a few country-oriented top level domains
("ccTLDs"). Historically, the "US." domain has been an excellent
example of the deeply hierarchical approach. However, by 1998,
comparison of several efforts to survey the DNS showed a count of SOA
records that approached (and may have passed) the number of distinct
hosts. Looked at differently, we appear to be moving toward a
situation in which the number of delegated domains on the Internet is
approaching or exceeding the number of hosts, or at least the number
of hosts able to provide services to others on the network. This
presumably results from synonyms or aliases that map a great many
names onto a smaller number of hosts. While experience up to this
time has shown that the DNS is robust enough -- given contemporary
machines as servers and current bandwidth norms -- to be able to
continue to operate reasonably well when those historical assumptions
are not met (e.g., with a flat, structure under ".COM" containing
well over ten million delegated subdomains [COMSIZE]), it is still
useful to remember that the system could have been designed to work
optimally with a flat structure (and very large zones) rather than a
deeply hierarchical one, and was not.
別の仮定はシステムがほとんどのシステムで深く第3よりレベルと総名前の非常に大きい百分率で階層的な(そして、名前)表すのが物理ホストであるならセカンドレベルドメインと物理ホスト対より一般にそれの高い確率にあるだろうということでした。 このモデルに従うドメインがあります: 多くの大学の、そして、法人のドメインがいくつかの国指向のトップ・レベル・ドメイン(「ccTLDs」)のように深い階層構造を公正に使用します。 歴史的である、「米国」 ドメインは深く階層的なアプローチに関する好例です。 しかしながら、1998年までには、記録するDNSがSOAのカウントにそれを示した調査するいくつかの取り組みの比較が異なったホストの数にアプローチしました(そして、通ったかもしれません)。 別の角度から見られて、私たちは、インターネットの代表として派遣されたドメインの数がホストの数、またはネットワークで他のものに対するサービスを提供するのにおいて有能なホストの数をアプローチするか、または超えている状況に近づいているように見えます。 おそらく、これは、より少ない数のホストに多くの名前を写像する同義語か別名から生じます。 サーバとしての現代のマシンと現在の帯域幅標準を考えて、経験は、これまで、DNSが十分強健であることを示しましたが; システムがそうしたかもしれないのを覚えているのを、深く階層的なものよりむしろ平板的構造(そして、非常に大きいゾーン)で最適に働くように設計されて、それらの歴史的な仮定が迎えられないとき(1000万の代表として派遣されたサブドメインの上に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.
同様に、直接(例えば、[RFC1034]を見る)人々の名前とEメールアドレスをDNSに入力することに関する何らかの早めの思惑にもかかわらず、インターネットの電子メールアドレスはオリジナルを保存しました、プレDNS、均し槌か厳密にドットで切り離されたものよりむしろ「位置のユーザ(または、メールボックス)」概念的な形式。 そのインスタンスでは、位置はホストが言及です。 少なくとも「IN」のクラスでは、唯一の例外はSOA記録のある分野です。
Both the DNS architecture itself and the two-level (host name and mailbox name) provisions for email and similar functions (e.g., see the finger protocol [FINGER]), also anticipated a relatively high ratio of users to actual hosts. Despite the observation in RFC 1034 that the DNS was expected to grow to be proportional to the number of users (section 2.3), it has never been clear that the DNS was seriously designed for, or could, scale to the order of magnitude of number of users (or, more recently, products or document objects), rather than that of physical hosts.
メールのためのDNSアーキテクチャ自体と2レベル(ホスト名とメールボックス名)の条項とまた、ユーザ対実際のホストの比較的高い比率に予期された同様の機能(例えば、指のプロトコル[FINGER]を見る)の両方。 または、DNSがユーザ(セクション2.3)の数に比例しています、それが一度も明確であったことがないということになるように成長すると予想されたRFC1034での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。
Klensin Informational [Page 5] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[5ページ]のRFC3467の役割
[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デザインが可能であると結論づけたデザイン。(より包括的なディレクトリアプローチはそのデザインがそうではありませんでした)。 同時に、何人かの関係者が、制限が将来の問題を引き起こすかもしれないと恐れました。 このドキュメントは本質的には、それらがたぶん正しかったという立場を取ります。 他方では、ディレクトリ技術と実装はその翌年の間、かなり発展しています: または、仮定をもう再訪させるべき時間であるかもしれません、どちらかこのドキュメントの残りで熟考された2(さらに)の平らなメカニズムの文脈でさらに根本的である、DNS交換に向かった経路として。
1.3 The Web and User-visible Domain Names
1.3 ウェブと目に見えるユーザドメイン名
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の「記録」ドメイン名を使用するというウェブデザイン決定はいくつかの点における重大な誤りであると間接指定の何らかのシステムよりむしろ判明しました。 タイプの便利、および容易に覚えていられた製品名からドメイン名を作る願望はDNSの平らになるのに通じました、多くの人々が、現在COM(または関連ccTLDの下のいくつかの国、2番目または第3レベル名で)の下の第2レベル名が重要なすべてであると知覚していて。 この知覚は何人かの追加名前を「販売すること」を切望しているドメイン名記録係[REGISTRAR]によって補強されました。 もちろん、そして、登録されていて、ものが1製品あたり1つの第2レベル(または、トップレベルさえ)ドメインに必要とした知覚はネットワーク資源の(通常組織的)の収集に関連している名前を持っているよりむしろ名前の数における急速な加速につながりました。 その加速は「販売」名のビジネスで順番に明確に1名前あたり1個のベースで充電している記録係、「サイバースクワッター」、および他のもののためになりましたが、それは明らかに全体でインターネットのためになりませんでした。
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
また、セカンドレベルドメイン名へのこの強調は商標共同体に問題を生じさせました。 インターネットが国際的であり、名前が平坦で資格のないスペースで居住されているので、市場でそれらを混乱させるという見込みが全く通常なくても、同様に命名された実体は闘争中です。 問題は厳格な措置の選択を除いて、「非-解決でき」であるように見えます。 これらの力は「名前」と「マーク」に関する論争を治める法律とコンベンションへの著しい変化を含んでいます。 または
Klensin Informational [Page 6] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[6ページ]のRFC3467の役割
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-作品]でIABによって議論された問題の多くを上げるように思えます。 書き直し機械が特定用途のために追加回避策によって伴われても、これらの問題は起こります。 例えば、関連サービスを呼び出そうとしているアプリケーションの参加なしでネットワークでDNS名か他の参照を変えるなら、「同じホスト」を特定する必要があるセキュリティ協会とアプリケーションがしばしば問題を出くわします。
1.4 Internet Applications Protocols and Their Evolution
1.4 インターネットアプリケーションプロトコルとそれらの発展
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
アプリケーションレベルでは、インターネットにおけるアクティブで、広範囲の使用でのプロトコルのわずかしか展開と使用で蓄積されたコンピュータサイエンスの現代の知識か人間の要素か経験のどちらかを反映しません。 代わりに、プロトコルは、プロトタイプのすぐ先におけるプロトタイプで典型的な好都合な感染のタイプを通常含むレベルで配布される傾向があります。 彼らが有用であることが分かるなら、ネットワークの本質は非常に急速な普及を可能にします(すなわち、彼らが真空をいっぱいにします、だれも以前に知らなかった真空が存在したとしても)。 しかし、インストールされたベース真空がいったんいっぱいにされると
Klensin Informational [Page 7] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[7ページ]のRFC3467の役割
provides its own inertia: unless the design is so seriously faulty as to prevent effective use (or there is a widely-perceived sense of impending disaster unless the protocol is replaced), future developments must maintain backward compatibility and workarounds for problematic characteristics rather than benefiting from redesign in the light of experience. Applications that are "almost good enough" prevent development and deployment of high-quality replacements.
それ自身の慣性を提供します: デザインが有効な使用を防ぐくらいには真剣に不完全でない場合(プロトコルが取り替えられない場合災害を迫らせるという広く知覚された感覚があります)、未来の発展は問題の多い特性のために経験の見地から再設計の利益を得るよりむしろ後方の互換性と回避策を維持しなければなりません。 「ほとんど十分良い」アプリケーションは高品質な交換の開発と展開を防ぎます。
The DNS is both an illustration of, and an exception to, parts of this pessimistic interpretation. It was a second-generation development, with the host table system being seen as at the end of its useful life. There was a serious attempt made to reflect the computing state of the art at the time. However, deployment was much slower than expected (and very painful for many sites) and some fixed (although relaxed several times) deadlines from a central network administration were necessary for deployment to occur at all. Replacing it now, in order to add functionality, while it continues to perform its core functions at least reasonably well, would presumably be extremely difficult.
DNS、両方がイラストである、例外、この悲観的な解釈の部分。 それは役に立つ寿命の終わりのように見られるホストテーブルシステムへの二世開発でした。 当時コンピューティング到達技術水準を反映するのがされた重大な試みがありました。 しかしながら、展開は、予想よりはるかに遅い、そして、(多くのサイトに非常に苦痛)でした、そして、中央のネットワーク管理からのいくつかの固定された(何度か弛緩しますが)締め切りが、展開が全く起こるのに必要でした。 おそらく、少なくとも合理的に上手にコア機能を実行し続けている間、現在機能性を加えるためにそれを取り替えるのは非常に難しいでしょう。
There are many, perhaps obvious, examples of this. Despite many known deficiencies and weaknesses of definition, the "finger" and "whois" [WHOIS] protocols have not been replaced (despite many efforts to update or replace the latter [WHOIS-UPDATE]). The Telnet protocol and its many options drove out the SUPDUP [RFC734] one, which was arguably much better designed for a diverse collection of network hosts. A number of efforts to replace the email or file transfer protocols with models which their advocates considered much better have failed. And, more recently and below the applications level, there is some reason to believe that this resistance to change has been one of the factors impeding IPv6 deployment.
この多くて、恐らく明白な例があります。 定義の多くの知られている欠乏と弱点にもかかわらず、「指」と"whois"[WHOIS]プロトコルは取り替えられていません(後者[WHOIS-UPDATE]をアップデートするか、または取り替える多くの取り組みにもかかわらず)。 Telnetプロトコルとその多くのオプションがSUPDUP[RFC734]1を排出しました。(論証上、ネットワークホストのさまざまの収集のためにそれを設計するほうがよかったです非常に)。 メールかファイル転送プロトコルを彼らの支持者がはるかによく考えたモデルに取り替える多くの取り組みが失敗しました。 そして、この改革への抵抗がIPv6展開を妨害する要素の1つであると信じる何らかの理由が、より最近とアプリケーションレベルの下にあります。
2. Signs of DNS Overloading
2. DNS積みすぎのサイン
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デザインか用途のどちらかのそれらの劇的な意識改革でというよりむしろ働いているのにすべて集中しました。 似たり寄ったりの時に起こったこれらの問題の数はまさしくまさしく複雑さを言い足して、デザインを増加して変更するのを試みるのではなく、意識改革のそのタイプについて賛成の議論をするかもしれません(例えば、見てください、[RFC3439]のセクション2の簡単さの議論)。
Klensin Informational [Page 8] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[8ページ]のRFC3467の役割
For example:
例えば:
o While technical approaches such as larger and higher-powered
servers and more bandwidth, and legal/political mechanisms such as
dispute resolution policies, have arguably kept the problems from
becoming critical, the DNS has not proven adequately responsive to
business and individual needs to describe or identify things (such
as product names and names of individuals) other than strict
network resources.
o より大きくて、より高く動力付きのサーバや、より多くの帯域幅などの技術的なアプローチ、および論争の解決方針などの法的であるか政治上のメカニズムが、問題が重要になるのを論証上妨げましたが、DNSが、適切にビジネスに敏感であると判明しないで、個人は、厳しいネットワーク資源以外のもの(個人の製品名や名前などの)を説明するか、または特定する必要があります。
o While stacks have been modified to better handle multiple
addresses on a physical interface and some protocols have been
extended to include DNS names for determining context, the DNS
does not deal especially well with many names associated with a
given host (e.g., web hosting facilities with multiple domains on
a server).
o スタックが物理インターフェースに関する複数のアドレスをよりよく扱うように変更されて、文脈を決定するためのDNS名を含むようにいくつかのプロトコルを広げている間、DNSは与えられたホスト(例えば、複数のドメインがサーバにあるウェブホスティング施設)に関連している多くの名前に特によく対処しません。
o Efforts to add names deriving from languages or character sets
based on other than simple ASCII and English-like names (see
below), or even to utilize complex company or product names
without the use of hierarchy, have created apparent requirements
for names (labels) that are over 63 octets long. This requirement
will undoubtedly increase over time; while there are workarounds
to accommodate longer names, they impose their own restrictions
and cause their own problems.
o 言語か文字集合を得ながら名前を加える取り組みが簡単なASCIIとイギリスのような名前(以下を見る)を除いて、オンであるか、または階層構造の使用なしで複雑な会社か製品名を利用するために同等の状態で基づいて、63以上の八重奏である名前(ラベル)のための作成された見かけの要件を長くしてください。 この要件は時間がたつにつれて、確かに増加するでしょう。 より長い名前に対応するために回避策がある間、それらは、それら自身の制限を課して、それら自身の問題を引き起こします。
o Increasing commercialization of the Internet, and visibility of
domain names that are assumed to match names of companies or
products, has turned the DNS and DNS names into a trademark
battleground. The traditional trademark system in (at least) most
countries makes careful distinctions about fields of
applicability. When the space is flattened, without
differentiation by either geography or industry sector, not only
are there likely conflicts between "Joe's Pizza" (of Boston) and
"Joe's Pizza" (of San Francisco) but between both and "Joe's Auto
Repair" (of Los Angeles). All three would like to control
"Joes.com" (and would prefer, if it were permitted by DNS naming
rules, to also spell it as "Joe's.com" and have both resolve the
same way) and may claim trademark rights to do so, even though
conflict or confusion would not occur with traditional trademark
principles.
o 会社か製品の名前を合わせると思われる増加するインターネットの商用化、およびドメイン名の目に見えることはDNSとDNS名を商標戦場に変えました。 (少なくとも)ほとんどの国の伝統的な商標システムは適用性の分野の周りで慎重な区別をします。 しかし、両方の間には、「ジョーのピザ」(ボストンの)と「ジョーのピザ」(サンフランシスコの)とのありそうな闘争があるだけではなく、スペースはいつ地理学か業種のどちらかによって分化なしで平らにされていますか、そして、「ジョーの自動修理。」(ロサンゼルスの) すべての3が、"Joes.com"(そして、それが規則を命名するDNSによって可能にされるなら、また、「ジョーの.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
o 多くの組織には、同じURLとドメイン名の下の異なったウェブサイトがありたいです。 それは、時々、これが地理的変異を引き起こす(Widget社は米国1つに比例して異なった材料をイギリスのユーザに寄贈したがっているかもしれない)ためのものであり、時々、情報をサーバからユーザの最も近くに位相的に提供するのによる、より高い性能を提供することになっています。 名前解決です。
Klensin Informational [Page 9] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[9ページ]のRFC3467の役割
mechanism is expected to provide this functionality, there are
three possible models (which might be combined):
メカニズムがこの機能性を提供すると予想されて、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内容交渉とこれらの問題を結合する一般的に引用された代替のアプローチ(Cf。 [RFC2295]), HTTP接続は最初に次に、好みが交渉されていて向け直されたクライアントになるように「一般的である」か「プライマリ」のホストに開かれるか、または代替のデータを送られるのが必要です。 少なくとも「より近い」位置にアクセスするのによる向上性能の見地から、初めはとその後、クライアントがどんな動作も開始する前にこのアプローチは必要な結果を犠牲にします。 一般的な満足している交渉アプローチの特性のいくつかがウェブURLにおけるDNSの非最適の使用のための回避策であると主張さえできました。
o Many existing and proposed systems for "finding things on the
Internet" require a true search capability in which near matches
can be reported to the user (or to some user agent with an
appropriate rule-set) and to which queries may be ambiguous or
fuzzy. The DNS, by contrast, can accommodate only one set of
(quite rigid) matching rules. Proposals to permit different rules
in different localities (e.g., matching rules that are TLD- or
zone-specific) help to identify the problem. But they cannot be
applied directly to the DNS without either abandoning the desired
level of flexibility or isolating different parts of the Internet
from each other (or both). Fuzzy or ambiguous searches are
desirable for resolution of names that might have spelling
variations and for names that can be resolved into different sets
of glyphs depending on context. Especially when
internationalization is considered, variant name problems go
beyond simple differences in representation of a character or
o 「インターネットでものを見つけます」の多くの既存の、そして、提案されたシステムがマッチの近くでユーザ(または適切な規則セットのユーザエージェントに)であると、そして、どの質問があいまいであるか、またはあいまいであるかもしれないかにどれを報告できるかで本当の検索能力を必要とします。 対照的に、DNSは1セットの(全く堅い)の合っている規則しか対応できません。 異なった場所(例えば、TLDの、または、ゾーン特有の合っている規則)で異なった規則を可能にするという提案は、問題を特定するのを助けます。 しかし、必要なレベルの柔軟性を捨てるか、またはインターネットの互い(ともに)と異なった地域を隔離しながら、どちらも直接DNSにそれらを適用できません。 スペル変化を持っているかもしれない名前の解決とglyphsが文脈による異なったセットに変えることができる名前に、あいまいであるかあいまいな検索は望ましいです。 または特に国際化が考えられるとき、異形名前問題がキャラクタの表現の簡単な違いを越える。
Klensin Informational [Page 10] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[10ページ]のRFC3467の役割
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).
ストリングを注文します。 代わりに、ユーザ驚きと混乱を避けるのは異なったアルファベットで書くことができる言語などの関係とKanjiひらがな関係とSimplifiedとTraditional中国人などの考慮を必要とします。 中国のものに基づくキャラクタの文脈のこれらの問題の部分集合を扱うための議論と提案に関して[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]の、より多くの議論を提供します)。 インターネット断片化と分離に関して同様の効果を持っている重解(例えば、いろいろな時にミンツ[ミンツ]と他のものによって提案された多言語名前のための別々の根)もメカニズムのどちらかなしで対応できない名前か文字集合の局所療法に関する多くの願望があります。
o For some purposes, it is desirable to be able to search not only
an index entry (labels or fully-qualified names in the DNS case),
but their values or targets (DNS data). One might, for example,
want to locate all of the host (and virtual host) names which
cause mail to be directed to a given server via MX records. The
DNS does not support this capability (see the discussion in
[IQUERY]) and it can be simulated only by extracting all of the
relevant records (perhaps by zone transfer if the source permits
doing so, but that permission is becoming less frequently
available) and then searching a file built from those records.
o いくつかの目的のために、インデックスエントリ(DNS場合におけるラベルか完全に修飾された名前)だけではなく、彼らの値か目標(DNSデータ)も捜すことができるのは望ましいです。 例えば、人はMX記録で与えられたサーバにメールを向けるホスト(そして、事実上のホスト)名のすべての場所を見つけたがっているかもしれません。 DNSはこの能力をサポートしないで([IQUERY]で議論を見てください)、単に、関連記録(ソースが、そうすることを許可しますが、その許可が頻繁により利用可能でなくなっているなら、恐らくゾーンのそばでは、移す)のすべてを抽出して、次に、それらの記録から造られたファイルを捜すことによって、それはシミュレートできます。
o Finally, as additional types of personal or identifying
information are added to the DNS, issues arise with protection of
that information. There are increasing calls to make different
information available based on the credentials and authorization
of the source of the inquiry. As with information keyed to site
locations or proximity (as discussed above), the DNS protocols
make providing these differentiated services quite difficult if
not impossible.
o 最終的に、個人的であるか特定情報の追加タイプがDNSに加えられるとき、問題はその情報の保護で起こります。 異なった情報を問い合せの源の資格証明書と承認に基づいて利用可能にするという増加する要求があります。 情報が立地か近接(上で議論するように)に合わせられている状態でこれらの差別化されたサービスを提供するのがDNSプロトコルでかなり難しいか不可能になるとき。
Klensin Informational [Page 11] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[11ページ]のRFC3467の役割
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プロトコルか何らかのプロトコルで、サポートされる)によってよく扱われるか、いずれのDNSでも捜しませんが、または環境(一般的なインターネット検索エンジンなどの)を捜すことです。 上で議論した新しいアプリケーションを配布するという困難を考えて、トリックとクラッジが十分悪いか、または悪くなることにかかわらず新しいソリューションは用法としての十分が成長して、必要であり、配布することができるという重要な質問は、考えます。
3. Searching, Directories, and the DNS
3. 探すこと、ディレクトリ、およびDNS
3.1 Overview
3.1 概要
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の規制と上の議論は「検索層」か「探せるシステム」として以下と呼ばれた中間的プロトコルメカニズムの導入を示します。 用語「ディレクトリ」と「ディレクトリシステム」は「探せるシステム」と共に互換性を持って本書では使用されます、後者ははるかに正確ですが。 検索層の提案は2(さらに)ステージルックアップを使用するでしょう、DNSの国際化している名前のためのいくつかの提案と似て(セクション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パッチ、クラッジ、または回避策ではなく、探せるシステムであると示唆します。
Klensin Informational [Page 12] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[12ページ]のRFC3467の役割
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ラベルに取り入れるのにトリックencodingsを利用する必要はなくて(そうするための人工の階層構造を作成して)。
o There is considerable experience (albeit not much of it very
successful) in doing fuzzy and "sonex" (similar-sounding) matching
in directory systems. Moreover, it is plausible to think about
different matching rules for different areas and sets of names so
that these can be adapted to local cultural requirements.
Specifically, it might be possible to have a single form of a name
in a directory, but to have great flexibility about what queries
matched that name (and even have different variations in different
areas). Of course, the more flexibility that a system provides,
the greater the possibility of real or imagined trademark
conflicts. But the opportunity would exist to design a directory
structure that dealt with those issues in an intelligent way,
while DNS constraints almost certainly make a general and
equitable DNS-only solution impossible.
o 豊富な経験がある、(それの多くでない、非常にうまくいく、)、中でしている中であいまいで「sonexに」合っている(同様に聞こえる)ディレクトリシステムそのうえ、異なった領域とセットの名前のために異なった合っている規則について考えるのは、地方の文化的な要件にこれらを適合させることができるくらいもっともらしいです。 明確に、ディレクトリの名前のただ一つのフォームを持っているのが可能であるかもしれませんが、どんな質問に関してかなりの柔軟性を持っているかはその名前に合っていました(異なった領域の異なった変化を持ちさえしてください)。 もちろん、システムが提供するより多くの柔軟性であり、本当の、または、想像される商標闘争の可能性は、より大きいです。 しかし、機会は知的な方法でそれらの問題に対処したディレクトリ構造を設計するために存在しているでしょう、一般的で公正なDNSだけソリューションはDNS規制でほぼ確実に不可能になりますが。
o If a directory system is used to translate to DNS names, and then
DNS names are looked up in the normal fashion, it may be possible
to relax several of the constraints that have been traditional
(and perhaps necessary) with the DNS. For example, reverse-
mapping of addresses to directory names may not be a requirement
even if mapping of addresses to DNS names continues to be, since
the DNS name(s) would (continue to) uniquely identify the host.
o ディレクトリシステムがDNS名に翻訳するのに使用されて、次に、DNS名が正常なファッションで調べられるなら、DNSと共にいくつかの伝統的で(恐らく必要)であった規制を弛緩するのは可能であるかもしれません。 例えば、DNS名へのアドレスに関するマッピングが、続けても、ディレクトリ名へのアドレスに関する逆マッピングは要件でないかもしれません、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"
o 戻るディレクトリシステムは設計できて、ただ一つの名前ではなく、1セットの名前がネットワーク-locational情報か他の文脈を確立する属性と対にされました。 この情報の種類は「特定の命名されたリソースのための最も近くて(最も良い)のサーバ」を決議する際にかなり役に立つかもしれません。
Klensin Informational [Page 13] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[13ページ]のRFC3467の役割
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 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 名前は国にバウンドしています、そして、言語は商標現実を管理するのを助けるかもしれません、商標重要な文脈におけるDNSの使用が、上のセクション1.3で議論するように商標システムについて世界的な「平らになること」を必要とする傾向がありますが。
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の代わりにユーザにとって、目に見える検索かディレクトリシステムで排除されることであるなら、工学と方針自然の両方の多くの難問が消え失せそうです。
3.2 Some Details and Comments
3.2 いくつかの詳細とコメント
Almost any internationalization proposal for names that are in, or
map into, the DNS will require changing DNS resolver API calls
("gethostbyname" or equivalent), or adding some pre-resolution
preparation mechanism, in almost all Internet applications -- whether
to cause the API to take a different character set (no matter how it
is then mapped into the bits used in the DNS or another system), to
accept or return more arguments with qualifying or identifying
information, or otherwise. Once applications must be opened to make
such changes, it is a relatively small matter to switch from calling
into the DNS to calling a directory service and then the DNS (in many
situations, both actions could be accomplished in a single API call).
ほとんど何かほとんどすべてのインターネットアプリケーションをあるか、またはDNSがDNSレゾルバAPI要求("gethostbyname"か同等物)を変えるのが必要である、または何らかのプレ解決準備メカニズムを言い足すコネに写像する名前のための国際化提案--APIが情報の、または、そうでない資格を得るか同一視との、より多くの議論を異なった文字集合(次に、それがどのようにDNSか別のシステムで使用されるビットに写像されても)を取って、受け入れるか、または返すことを引き起こすのであるかどうか それは、かつて、そのような変更を行うためにアプリケーションを開かなければならなくて、DNSにちょっと立ち寄るのからディレクトリサービスを呼ぶと切り換える比較的小さい物質とそして、DNS(多くの状況で、ただ一つのAPI呼び出しで両方の動作を実行できた)です。
A directory approach can be consistent both with "flat" models and multi-attribute ones. The DNS requires strict hierarchies, limiting its ability to differentiate among names by their properties. By contrast, modern directories can utilize independently-searched attributes and other structured schema to provide flexibilities not present in a strictly hierarchical system.
ディレクトリアプローチは「平坦な」モデルとマルチ属性ものと一致している場合があります。 名前の中で彼らの特性で差別化する性能を制限して、DNSは厳しい階層構造を必要とします。 対照的に、近代的なディレクトリは、厳密に階層的なシステムの現在でない余裕を提供するのに独自に捜された属性と他の構造化された図式を利用できます。
There is a strong historical argument for a single directory structure (implying a need for mechanisms for registration, delegation, etc.). But a single structure is not a strict requirement, especially if in-depth case analysis and design work leads to the conclusion that reverse-mapping to directory names is not a requirement (see section 5). If a single structure is not needed, then, unlike the DNS, there would be no requirement for a global organization to authorize or delegate operation of portions of the structure.
単一ディレクトリ構造のための強い歴史的な議論があります(登録、委譲などのためにメカニズムの必要性を含意して)。 しかし、ただ一つの構造は厳しい要件ではありません、特に徹底的な症例分析とデザインワークがディレクトリ名への逆マッピングが要件(セクション5を見る)でないという結論につながるなら。 ただ一つの構造は必要でないなら、グローバル組織が構造の一部の操作を認可するか、または代表として派遣するという要件が全くDNSと異なっていないでしょう。
Klensin Informational [Page 14] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[14ページ]のRFC3467の役割
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.)
を支持して、 より遠くに簡単な「名前」から遠くに移行することによって「ただ一つの構造がありません」概念を取ることができた、例えば、多属性multihierarchical(一面の大部分が限られた語彙を使用するfacetedシステム) (例えば[IS5127]これらの用語は情報検索と分類システム文学でかなり標準であり、見てください。) 手順がデータベースの向こう側に、または、実行される検索がことであるfaceted実体に関するプロバイダーとデータベースの中でさえユニークさを確実にする必要性を避けるようにそのようなシステムを設計できました。 (さらなる議論の[DNS-検索]を見てください。)
While the discussion above includes very general comments about attributes, it appears that only a very small number of attributes would be needed. The list would almost certainly include country and language for internationalization purposes. It might require "charset" if we cannot agree on a character set and encoding, although there are strong arguments for simply using ISO 10646 (also known as Unicode or "UCS" (for Universal Character Set) [UNICODE], [IS10646] coding in interchange. Trademark issues might motivate "commercial" and "non-commercial" (or other) attributes if they would be helpful in bypassing trademark problems. And applications to resource location, such as those contemplated for Uniform Resource Identifiers (URIs) [RFC2396, RFC3305] or the Service Location Protocol [RFC2608], might argue for a few other attributes (as outlined above).
上の議論は属性に関して非常に一般的なコメントを含んでいますが、非常に少ない数の属性だけが必要であるように見えます。 リストは国際化目的のためにほぼ確実に国と言語を含んでいるでしょう。 私たちが文字集合とコード化に同意できないなら、それは"charset"を必要とするかもしれません; 単にISO10646を使用するための強い議論があります。(また、ユニコードか「UCS」(ユニバーサル文字セットのための)ユニコードとして知られていて、それらが商標問題を迂回させる際に役立っているなら、置き換え商標問題におけるIS10646コード化は「商業」の、そして、「非営利的である」(他)の属性を動機づけるかもしれません; そして、Uniform Resource Identifier(URI)RFC2396のために熟考されたものなどのリソース位置へのアプリケーション(RFC3305かService LocationプロトコルRFC2608)は、他のいくつかの属性について賛成の議論をするかもしれません(上に概説されているように)。
4. Internationalization
4. 国際化
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.
ASCIIの伝統的なDNS部分集合で正確にDNSを国際的にする問題によって動かされたか、または言語からDNSの機能へのアクセスをより明確に提供しながらこのドキュメントの基礎となって、システムをそれと命名する考えの多くを表すことができません。 IETFの「国際化ドメイン名」作業部会(IDN-WG)で関連仕事の多くのことをしました、また、このドキュメントは他のフォーラムで大規模な並行協議を利用しますが。このセクションは「国際化しているDNS」か「多言語DNS」が探検されて、その評価に基づく将来の階段を示すとき何が知られたかに関する評価を含みます。
When the IDN-WG was initiated, it was obvious to several of the participants that its first important task was an undocumented one: to increase the understanding of the complexities of the problem sufficiently that naive solutions could be rejected and people could go to work on the harder problems. The IDN-WG clearly accomplished that task. The beliefs that the problems were simple, and in the corresponding simplistic approaches and their promises of quick and painless deployment, effectively disappeared as the WG's efforts matured.
IDN-WGが開始されたとき、数人の関係者にとって、最初の重要な仕事が正式書類のないものであったのは明白でした: 問題の複雑さの理解を増強するために、十分そんなにナイーブなソリューションを拒絶できました、そして、人々は、より困難な問題に働きかけることができました。IDN-WGは明確にそのタスクを達成しました。 WGの取り組みが熟したとき、事実上、簡単であり、対応する安易なアプローチと彼らの迅速で無痛の展開の約束に基づき問題信念は見えなくなりました。
Klensin Informational [Page 15] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[15ページ]のRFC3467の役割
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.
増強された理解から学習されたレッスンとナイーブな信念の何らかの消散が警告として、より広い共同体によってみなされるべきです: 問題は簡単ではありません。 ソリューションのために全体のシステムを見るより明確にむしろわずかな要素を抜粋するのは問題をあいまいにしますが、どんな問題の価値がある問題も解決しないのに結果として生じるかもしれません。
4.1 ASCII Isn't Just Because of English
4.1 ASCIIは英語のジャスト・ビコーズではありません。
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を使用します。」であったと裁決します。 私たちは、他のほとんどあらゆるスクリプト(私たちがキャラクタの残りを可能にするなら、ASCIIさえISOで646の国際Referenceバージョンを指定した)がホスト名の制限されたASCIIより複雑であると発見しました("LDH"は形成します、とセクション1.1は見ます)。 そして、ASCIIが完全に英語を表すことができるというわけではないくらいの--ASCIIに現れないキャラクタか読み分け記号だけで正しくつづられる言語のいくつかの単語があります。 いくつかの例における、スクリプトの、より広い品揃えで、ケースマッピングは、1つのケースからもう片方まで働いていますが、リバーシブルではありません。 他のものには、働いているキャラクタ(ぴったりしただけコード化ではなく、言語の)の代理をする代替の方法に関してコンベンションがあります。たいてい、しかし、いつもそうであるというわけではありません。 そして、ユニコード/10646が提供されている状態で同じキャラクタの代理をする異なった方法をコード化するのにおいて問題があります(「キャラクタ」は故意にここで"glyph"よりむしろ使用されます)。 そして、それでも、他のものに、2glyphs(1ではなく、距離機能質問であるかもしれない)が「合うかどうか」に関して質問が2進の答えと共にあります。 これらの問題へのIETFアプローチはcanonicalizationをあらかじめ合わせるのが必要である(以下での"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は明確なブロックを使用することによってというよりむしろ1キャラクタあたり1個のベースのユニコード/10646のキャラクタを完全に新しいコード化文字集合を指定しようとするか、選んで、または選ぼうとする誘惑に抵抗しました。 インターネット特有の需要を満たすように設計された文字集合が非常に魅力的であるように見えるかもしれませんが、IETFには、実際にその仕事を引き受けるために、専門的技術、リソース、および表現が批判的に重要な共同体から一度もありませんでした。 恐らく、より重要です、新しい取り組みはして、いくらか異なった特性でコードを作成するユニコード委員会と異なって多くの複雑な見返りのいくつかを作るのを選んだかもしれません。 しかし、そうするのが、より少ない問題と副作用に伴うコードを作成するだろうという証拠が全くありません。 見返りを異なって作ると、異なったセットの問題、どれが等しくそうであるだろうか、そして、より難しいのが単にはるかにもたらされそうでしょう。
Klensin Informational [Page 16] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[16ページ]のRFC3467の役割
4.2 The "ASCII Encoding" Approaches
4.2 「ASCIIコード化」アプローチ
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が知られている内部の問題なしで任意の2進のストリングを扱うことができる間([RFC2181]を見てください)、テキストがケースから独立している方法[RFC1034][RFC1035)で解釈されるという要件によっていくつかの制限が課されます。 より重要です、ほとんどのインターネットアプリケーションがホストテーブルRFCsでRFC1035で「慎重」として指定されるホスト名で制限された"LDH"構文を仮定します。 それらの仮定が迎えられないなら、それらのアプリケーションの多くの従う実装が作成者とユーザを驚かせる振舞いを示すかもしれません。 これらの潜在的な問題を避けるために、IETF国際化仕事は「ASCIIコンパチブルEncodings」(ACE)に焦点を合わせました。 これらのencodingsはDNS自身のLDHコンベンションを保存します。 アップグレードしていないアプリケーションの実装はコード化されたフォームを利用します、特別なコーディングを認識して、非ASCII文字にそれらを写像するために、より新しいものを書くことができますが。 しかしながら、ヒューマンインターフェース問題が無視されても、これらのアプローチは問題なしではありません。 他の問題の中では、彼らは結局DNSラベルが国際化している名前(すなわち、ユニコードをコード化する)であるとみなされることになっているか、または実際のLDH名として解釈されることになっているかをそれ自体で決定するヒューリスティックであることを当てにします。 そして、国際的なスクリプトと名前の複雑さに結合されると、DNSの合っているメカニズムが呼び出される[STRINGPREP]前にACEシステムは、DNSサーバで特定の質問が保存されたオブジェクトに合うかどうかに関するすべての決断を伝統的にしている間、合っている仕事の多くが別々のクライアント側、canonicalizationまたは「準備」プロセスに切り離されるのを必要とします。
4.3 "Stringprep" and Its Complexities
4.3 "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.
上に概説されているように、非ASCII名をDNSとほかの場所に置くと関連している問題を避けるためのモデルはストリングが偽りのキャラクタコードを排除するか、または拒絶して、何人かのキャラクタを他のものに写像して、何らかの系列canonicalizationを実行して、一般に、正確に比較できるフォームを作成するストリング準備機能を通り抜けた後にだけ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
一般的な概念の基本的なstringprepは簡単ですが、多くの詳細がかなり微妙です、そして、関連見返りは複雑です。 かなりの努力がプロトコルとテーブルをはっきりさせて、微調整するのに置かれている状態で何カ月も企てられたデザインチーム。 IETFが文字の組、キャラクタコーディング、および関連コンベンションを定義するビジネスに得るのを避ける一般協定にもかかわらず、グループは、何度か特別番組を考えて、拒絶しました。
Klensin Informational [Page 17] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[17ページ]のRFC3467の役割
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.
以上へのコード位置の処理はキャラクタの類似性と違いに関してユニコードによってされた区別にユーザ知覚にほとんど合っています。 しかし、言語特有の、または、国の特有の規則を取り入れる激しい誘惑(そして、圧力)がありました。 抵抗されると、それらの誘惑は、目に見える完全に国際化している名前において暗示して進行中の論争か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 同じ言葉を表すTraditionalとSimplified漢字のマッチング
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).
これらの操作のどれかを支持するという決定は、他のスクリプトか言語のための意味を持って、過程の総合的な複雑さを増加させるでしょう。 例えば、言語特殊情報がどうにか利用可能でない場合、TraditionalとSimplified中国人の間で合っている実行は同じ「伝統的な」キャラクタの日本の、そして、韓国の用途に影響力を持っています(例えば、Simplified中国人にKanjiを写像するのは適切でないでしょう)。
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にもかかわらず、結果がマッチングと比較の過程の他のすべての部分のようにむしろ「マッチにもかかわらず、マッチがありません」2進の答えをもたらすというDNSによって課された要件でそうしていない、例えば、ユーザかユーザ駆動の学習的機能で評価できる類似性スケールの値。
Klensin Informational [Page 18] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[18ページ]のRFC3467の役割
4.4 The Unicode Stability Problem
4.4 ユニコード安定問題
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.
ISO10646は、キャラクタを使用するか、または比較するために基本的に規則ではなく、コード・ポイントだけを定義します。 これによる現在何に関する仕事がある長年の伝統の一部がISO/IEC JTC1/SC2であるかということです: 彼らは、自分達の範囲のようにコードポイント課題を実行して、キャラクタが使用されている方法を通常扱いました。 その結果、事実上、彼らは、より広い範囲の国際化問題に対処していません。 対照的に、ユニコードTechnical Committee(UTC)はcanonicalizationと比較のために別館と技術報告書(見てください、例えば、[UTR15])でいくつかの付則を定義しました。 DNSによって当てにされるのは、十分正確なファッションでそれらを作るか、または定義するために簡単であって、"stringprep"と"nameprep"仕事がそれらの規則とコンベンションの多くの要因として考慮されたのではなく、永久的です。
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定義がマッチングを正確で明白にするように少なくとも追加情報なしで不十分であるいくつかの領域を特定しました。 これらの場合のいくつかでは、ユニコードStandardはいくつかの交互のアプローチを可能にします。そのいずれはDNSの必要性への正確で明白なマッチではありません。 それはIETFまでの徹底的な専門的技術(まして、別のものを犠牲にして1つの言語を最適化すると決めるためのどんなメカニズムも)をこれらの敏感な選択に残しました。(IETFは十分な状態で欠けています)。
For example, it is tempting to define some rules on the basis of membership in particular scripts, or for punctuation characters, but there is no precise definition of what characters belong to which script or which ones are, or are not, punctuation. The existence of these areas of vagueness raises two issues: whether trying to do precise matching at the character set level is actually possible (addressed below) and whether driving toward more precision could create issues that cause instability in the implementation and resolution models for the DNS.
例えば、特定のスクリプト、または句読文字のための会員資格に基づいていくつかの規則を定義するのに誘惑していますが、どのスクリプトかどれがあるか、またはないかにどんなキャラクタが属するかに関する厳密な定義が全くありません、句読。 あいまいさのこれらの領域の存在は2冊を提起します: 文字の組レベルで正確なマッチングをしようとするのが実際に可能であり(以下では、記述されます)、以上に向かって運転するか否かに関係なく、精度がDNSのために実現における不安定性を引き起こす問題と解決モデルを創造するかもしれません。
The Unicode definition also evolves. Version 3.2 appeared shortly after work on this document was initiated. It added some characters and functionality and included a few minor incompatible code point changes. IETF has secured an agreement about constraints on future changes, but it remains to be seen how that agreement will work out in practice. The prognosis actually appears poor at this stage, since UTC chose to ballot a recent possible change which should have been prohibited by the agreement (the outcome of the ballot is not relevant, only that the ballot was issued rather than having the result be a foregone conclusion). However, some members of the community consider some of the changes between Unicode 3.0 and 3.1 and between 3.1 and 3.2, as well as this recent ballot, to be
また、ユニコード定義は発展します。 このドキュメントへの作業が開始されたすぐ後にバージョン3.2は現れました。 それは、何らかのキャラクタと機能性を加えて、いくつかの小さい方の非互換なコードポイント変化を含んでいました。 IETFは将来の変化の上で規制に関する協定を保証しましたが、その協定が実際にはどのように考え出されるかはまだ不明です。 予後は現在のところ実際に貧しく見えます、UTCが、協定で禁止されるべきであった最近の可能な変化に投票するのを選んだので。(投票の結果が関連していない、結果が当然の結果であることを持っているより投票はむしろ発行されるだけでした) しかしながら、共同体の何人かのメンバーが、考えるこの最近の投票と同じくらい良いユニコード3.0と3.1と3.1〜3.2の間のいくつかの変化は
Klensin Informational [Page 19] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[19ページ]のRFC3467の役割
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.
これらの不安定性が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(プログラミング言語、システム、および環境に対処する小委員会の中のInternationalizationワーキンググループ)にそれらの問題のいくつかを割り当てました。 WG20は歴史的に国際化問題に考え深さに、そして徹底的に対処しましたが、近年、状態が何度か疑問でいました。 しかしながら、WG20へのこれらの件の課題はUTC仕様より異なった振舞いを指定する最後のISO国際化規格の危険を増加させます。
4.5 Audiences, End Users, and the User Interface Problem
4.5 聴衆、エンドユーザ、およびユーザーインタフェース問題
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-
o 私たちがプログラミング言語かAPIのために規則を書いているなら、「彼らは、私たちのコンベンションに使用されて、適合する」という原則はすばらしいです。 しかし、議論しているコンベンションが準数学のシステムの一部でない、それらは文化で根深いです。 英語を話すアメリカ人がインターネットが、「色」の正しいスペルが使用されるのを必要とするとどれくらいの頻度で言われても、その人は確信しないでしょう。 リヨンのフランス人のスピーカーにまさにフランス人と同じ語彙コンベンションを使用させます。
Klensin Informational [Page 20] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[20ページ]のRFC3467の役割
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.
ケベックのスピーカー、収容、IETFか記録係か登録の決定はただありそうではありません。 「モントリオール」は、「e」(すなわち、同等物の9か1つをユニコード文字U+00E使用する)の上に鋭アクセントマークがある同様の単語のスペルミスかanglicizationのどちらかです。 しかし、2つのフォームが合っているはずであるかどうかと決心して、1つの言語かもう片方のエンドユーザとスピーカーを驚かせない規則のグローバルな協定は「スペルミス」か"anglicization"が、よりすばらしいパロディであるかどうかに関する協定と同じくらいありそうもないです。
More generally, it is not clear that the outcome of any conceivable nameprep-like process is going to be good enough for practical, user-level, use. In the use of human languages by humans, there are many cases in which things that do not match are nonetheless interpreted as matching. The Norwegian/Danish character that appears in U+00F8 (visually, a lower case 'o' overstruck with a forward slash) and the "o-umlaut" German character that appears in U+00F6 (visually, a lower case 'o' with diaeresis (or umlaut)) are clearly different and no matching program should yield an "equal" comparison. But they are more similar to each other than either of them is to, e.g., "e". Humans are able to mentally make the correction in context, and do so easily, and they can be surprised if computers cannot do so. Worse, there is a Swedish character whose appearance is identical to the German o-umlaut, and which shares code point U+00F6, but that, if the languages are known and the sounds of the letters or meanings of words including the character are considered, actually should match the Norwegian/Danish use of U+00F8.
より一般に、実用的で、ユーザ平らな使用には十分良いのは想像できるどんなnameprepのような過程の結果も行くのが明確ではありません。 人間による人間の言語の使用で、合っていないものがそれにもかかわらず、合っていると解釈される多くの場合があります。 U+00F8(目視により、小文字'o'は前進のスラッシュで「過剰-打撃」である)に現れるノルウェーの、または、デンマーク人のキャラクタとU+00F6(目視により、aは分切(または、ウムラウト符号)でケース'o'を下ろす)に現れる「o-ウムラウト符号」ドイツ人のキャラクタは明確に異なっています、そして、どんな合っているプログラムも「等しい」比較をもたらすはずがありません。 しかし、それらは例えばいずれか一方があるより互いと同様です。「e。」 人間は、精神的に状況内において修正をして、それほど容易にできます、そして、コンピュータがそうできないなら、彼らは驚くことができます。 よりひどく、外観がドイツのo-ウムラウト符号と同じであり、コード・ポイントU+00F6を共有しますが、言語が知られていて、手紙の音かキャラクタを含む単語の意味が考えられるなら実際にU+00F8のノルウェーの、または、デンマークの使用に合うべきであるスウェーデン人のキャラクタがあります。
This text uses examples in Roman scripts because it is being written in English and those examples are relatively easy to render. But one of the important lessons of the discussions about domain name internationalization in recent years is that problems similar to those described above exist in almost every language and script. Each one has its idiosyncrasies, and each set of idiosyncracies is tied to common usage and cultural issues that are very familiar in the relevant group, and often deeply held as cultural values. As long as a schoolchild in the US can get a bad grade on a spelling test for using a perfectly valid British spelling, or one in France or Germany can get a poor grade for leaving off a diacritical mark, there are issues with the relevant language. Similarly, if children in Egypt or Israel are taught that it is acceptable to write a word with or without vowels or stress marks, but that, if those marks are included, they must be the correct ones, or a user in Korea is potentially offended or astonished by out-of-order sequences of Jamo, systems based on character-at-a-time processing and simplistic matching, with no contextual information, are not going to satisfy user needs.
本稿は、それが英語で書かれていて、それらの例は比較的レンダリングしやすいので、ローマスクリプトによる例を使用します。 しかし、近年ドメイン名国際化についての議論の重要な教訓の1つは上で説明されたものと同様の問題がほとんどあらゆる言語とスクリプトで存在しているということです。 それぞれには特異性があって、それぞれのセットの特異性は、関連グループで非常に身近な一般的な用法と文化的なテーマに結ばれて、文化的価値観としてしばしば深く保たれます。 米国の学童が完全に有効なイギリスのスペルを使用するための漢字テストに悪い成績を取ることができるか、またはフランスかドイツの1つが読み分け記号をやめるために悪い成績を取ることができる限り、関連言語には問題があります。 同様に、エジプトかイスラエルの子供が母音か強勢記号のあるなしにかかわらず単語を書くのが許容できますが、それらのマークが含まれているならそれらが正しい方でなければならないことを教えられるか、または韓国のユーザはJamoの不適切な系列によって潜在的に怒っているか、驚かされているなら、文脈上の情報なしで一度にキャラクタ処理と安易なマッチングに基づくシステムはユーザ需要を満たさないでしょう。
Klensin Informational [Page 21] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[21ページ]のRFC3467の役割
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.
ユーザは言語と文化と取り引きする解決策を要求しています。 専門家かコンピュータに役立つ識別子記号列のシステムはせいぜいaにかなり異なった解決策(このドキュメントは、当時、書かれて、いくらかほとんど定義されていなかった)です、問題。 最近の努力で、ユーザ要件と辛うじて定義された識別子の区別を無視するなら私たちが不十分な問題を解決しているのがかつてより明確になりました。 そして、逆に、ユーザ要件の解決策に近似するために提案されたアプローチは簡単な識別子が必要とするよりはるかに複雑であるかもしれません。
4.6 Business Cards and Other Natural Uses of Natural Languages
自然言語の4.6個の名刺と他の自然な用途
Over the last few centuries, local conventions have been established in various parts of the world for dealing with multilingual situations. It may be helpful to examine some of these. For example, if one visits a country where the language is different from ones own, business cards are often printed on two sides, one side in each language. The conventions are not completely consistent and the technique assumes that recipients will be tolerant. Translations of names or places are attempted in some situations and transliterations in others. Since it is widely understood that exact translations or transliterations are often not possible, people typically smile at errors, appreciate the effort, and move on.
ここ数世紀にわたって、地方のコンベンションは、世界各地で多言語状況に対処するために設立されています。 これらのいくつかを調べるのは役立っているかもしれません。 例えば、1つが言語がものと異なっている国を訪問するなら、自己であり、名刺は2つの側(各言語の半面)でしばしば印刷されます。 コンベンションは完全に一貫しているというわけではありません、そして、テクニックは受取人が許容性があると仮定します。 名前か場所に関する翻訳は他のものにおけるいくつかの状況と音訳で試みられます。 努力に感謝します、そして、正確な翻訳か音訳がしばしば可能であるというわけではないことが広く理解されているので、人々は誤りに通常微笑んで、移動します。
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が完全な一致を必要とするか、またはルックアップは失敗します。
4.7 ASCII Encodings and the Roman Keyboard Assumption
4.7 ASCII Encodingsとローマキーボード仮定
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,
ACEベースの解決策のための議論の一部はアプリケーションがアップグレードしていないとき、多言語環境のためのエスケープを提供するということです。 より古いアプリケーションがACEベースの名前に遭遇すると、仮定は(明白に醜い)のASCIIによってコード化されたストリングを表示して、タイプできるということです。 この議論は、ローマベースのアルファベットの混合物の見地から妥当ですが、ローマベースのキャラクタのエントリーを支持しないことができませんし、便利にそのようなキャラクタをレンダリングできないユーザレベルシステムと装置がかかわるなら、関連していないかもしれません。 そのようなシステムは今日の世界のわずか、インターネットがますます第一の関心が地元の問題、ローカルの情報、および現地語と共にある人口によって使用されるとき数だけが上昇すると合理的に予想できるということです。 それはそうです。
Klensin Informational [Page 22] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[22ページ]のRFC3467の役割
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.
例えば、人口を想像するために、だれがアラビアの、または、タイの文字を使用するか、そして、だれがスクリプトか入力装置に通常のアクセスを持っていないかがかなりたやすく、ローマに派生しているアルファベットを基礎づけました。
4.8 Intra-DNS Approaches for "Multilingual Names"
4.8 「多言語名前」のためのイントラ-DNSアプローチ
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ベースの解決策のいずれも実行可能でないように見えます。 彼らは人々がコンピュータの人生を簡単にするように定められたコンベンションへの深く強固な言語習慣を適合させるという可能であるように見えないあまりに多くの前提で休息します。 私たちは「今それを凍らせてください、そして、いいえはこれらの領域の変化のためにそうしなければなりません」をユニコードとnameprepに関する決定にすることができます。 そのACEは、キーへの能力なしで環境さえにおけるアプリケーション問題を取り繕うか、またはローマベースのglyphs(ユーザー・エクスペリエンスが互いとそのようなglyphsを容易に区別できないようにものであるところ)をレンダリングするでしょう。 ユニコードConsortiumは、DNSの不一致の危険を作成する方法で誤りを修理すると決して決めないでしょう。 私たちがEDNS[RFC2671]を配備できますか、または長い名前は本当に重要ではありません。 日本の、そして、中国人のコンピュータユーザ(そして、他のもの)が望んでいるのは、彼らのローカルをあきらめるか、2022年のベースのキャラクタコード化解決策(新法が100万の大きい部分のどの添加のためにユニコードを示すかは、ほぼ確実に必要な、しかし、たぶん十分でない状態である)であるか体格は漏れなくて完全に正確な境界変換メカニズムです。 バンドか文脈上の情報からのそれは「スクリプトへの地図glyph」問題にいつも十分です。 など。 その都度、およそ80%か90%のケースが満足に働きますが、十分良いのがそのような部分的解決がなるありそうもないのは、ありそうです。 例えばだれかが正しく彼女の名前を90%つづることができるか、会社名が80%の割合で正しく合わせられていますが、または他の20%の試みが競争相手を特定するなら: どちらかが適切であると考えられそうですか?
5. Search-based Systems: The Key Controversies
5. 検索ベースのシステム: 主要な論争
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)
上にテキストのいくつかに示されるように、それはシングルで共同体の必要性に役立つだろうかどうかが最も良いのに関する未決問題です。(機能上、そして、恐らく行政上であっても分配、)
Klensin Informational [Page 23] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[23ページ]のRFC3467の役割
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.
そして、普遍的な適用性があるディレクトリ、局所的にオーダーメイドの検索を支持する単一ディレクトリ、(最も重要である、マッチング) 機能、または多彩で、局所的に決定しているディレクトリ。 それぞれには、アトラクションがあります。 いずれにもかかわらず、1番目は本質的には逆マッピングを防ぐでしょう(アドレスか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.
局所的にオーダーメイドの検索とマッピングはストリングが他のどれに合っていた解釈の国家の変化を可能にするでしょう、異なった場所が異なった規則を適用するとそれが特に重要であるアレンジメント、例えば、diacriticalsのあるなしにかかわらずキャラクタのマッチング。 もちろん、しかし、これはURLをクライアントマシンでの設定かユーザのネットワークの接続性のどちらかに適切に評価しないか、依存しないかもしれないのを含意します。 一般に、それは望ましい状況ではありません、ユーザが一般的な場合でURL(または、他のホスト参照)を共有できないで、特定のユーザが1つのホストか位置からもう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によって課された要件の取り外しに結びつけられるなら、別々のディレクトリとデータベースのシステムは命名階層構造の最上部を管理するただ一つの世界的な権威の必要性を主に排除するでしょう。
6. Security Considerations
6. セキュリティ問題
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,
このドキュメントによって含意された提案のセットはおもしろい安全保障問題を示します(すなわち、重要でないものは何でも簡単です)。 おそらく、ネットワーク資源の場所を見つけるのに使用されるディレクトリシステムは、DNS自身として同じくらい慎重に未承認の変更に対して保護される必要があるでしょう。 また、2つ以上の(潜水艦)層にかかわるアレンジメントには問題の新しい機会があるかもしれません、特にそのようなシステムが名前の主要な権威もユニークさなしで設計されたなら。 1つの名前を調べることを伴ったDNSルックアップ系列と比べて、それらのリスクがどれほどすばらしいかは、不確実です。
Klensin Informational [Page 24] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[24ページ]のRFC3467の役割
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.
異なった下位木で潜在的に情報を取り戻して、次に、追加ルックアップをします。 その多段式のルックアップがしばしばケースであるために望んでいる、追加制限が課されない場合、例えば、NAPTRは[RFC2915]を記録します。 しかし、追加ステップ、システム、およびデータベースはほぼ確実に妥協のいくつかの追加危険を伴います。
7. References
7. 参照
7.1 Normative References
7.1 標準の参照
None
なし
7.2 Explanatory and Informative References
7.2 説明していて有益な参照
[Albitz] Any of the editions of Albitz, P. and C. Liu, DNS and
BIND, O'Reilly and Associates, 1992, 1997, 1998, 2001.
[Albitz] Albitz P.とC.リュウとDNSとBINDとオライリーと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 Institut(以前アメリカ合衆国規格研究所)、X3.4、1968、「米国情報交換用符号。」 わずかな変更でANSI X3.4-1968をより新しいバージョンに取り替えましたが、1968年のバージョンはインターネットに決定的に残っています。 いつか、ASCIIが最初に規格として定式化された後にISOは世界規格646を採用しました。(それは、ベースとしてASCIIを使用します)。 実際に含まれた2コードが見送る646です: 現代の本質的にはASCIIと同じであった「国際参照バージョン」(ISO 646-IRVとしてしばしば参照をつけられる)、および国家の使用のための多くの欄を指定する「基本的なバージョン。」(ISO 646-BV)
[CIDR] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993.
[CIDR] フラーとV.と李とT.とユーとJ.とK.Varadhan、「以下を掘る(CIDR)階級のない相互ドメイン」 「アドレス課題と集合戦略」、RFC1519、9月1993日
Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
ADDR.ARPA delegation", RFC 2317, March 1998.
EidnesとH.とdeグルートとG.とP.Vixie、「階級のないIN ADDR.ARPA代表団」、RFC2317、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.
Verisign Global Registry Services(ゾーンの管理者、または「登録オペレータ」、COMに関して、以下の[REGISTRAR]を見る)によってICANN(2002第3四半期)に提供された[COM-SIZE]サイズ情報。
[DNS-Search] Klensin, J., "A Search-based access model for the
DNS", Work in Progress.
[DNS-検索] Klensin、J.、「DNSの検索ベースのアクセスモデル」、ProgressのWork。
Klensin Informational [Page 25] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[25ページ]のRFC3467の役割
[FINGER] Zimmerman, D., "The Finger User Information Protocol",
RFC 1288, December 1991.
[弄ります] ジンマーマン、D.、「指のユーザー情報プロトコル」、RFC1288、1991年12月。
Harrenstien, K., "NAME/FINGER Protocol", RFC 742,
December 1977.
Harrenstien、K.、「名前/指のプロトコル」、RFC742、1977年12月。
[IAB-OPES] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC
3238, January 2002.
[IAB-作品] フロイドとS.とL.Daigle、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、2002年1月。
[IQUERY] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
2002.
D. [IQUERY]ローレンス、2002年11月、「IQUERYを時代遅れにする」RFC3425。
[IS646] ISO/IEC 646:1991 Information technology -- ISO 7-bit
coded character set for information interchange
[IS646]ISO/IEC、646:1991 情報技術--、情報交換のためのISOの7ビットのコード化文字集合
[IS10646] ISO/IEC 10646-1:2000 Information technology --
Universal Multiple-Octet Coded Character Set (UCS) --
Part 1: Architecture and Basic Multilingual Plane and
ISO/IEC 10646-2:2001 Information technology --
Universal Multiple-Octet Coded Character Set (UCS) --
Part 2: Supplementary Planes
[IS10646]ISO/IEC10646-1: 2000年の情報技術--普遍的なMultiple-八重奏Coded文字コード(UCS)--第1部: アーキテクチャ、基本多言語水準、およびISO/IEC10646-2: 2001年の情報技術--普遍的なMultiple-八重奏Coded文字コード(UCS)--第2部: 補っている飛行機
[MINC] The Multilingual Internet Names Consortium,
http://www.minc.org/ has been an early advocate for
the importance of expansion of DNS names to
accommodate non-ASCII characters. Some of their
specific proposals, while helping people to understand
the problems better, were not compatible with the
design of the DNS.
[ミンツ] MultilingualインターネットNames Consortium、 http://www.minc.org/ はDNS名の拡張の重要性が非ASCII文字を収容する初期の支持者です。 人々が問題をより理解しているのを助けている間、彼らの明確な提案のいくつかがDNSのデザインと互換性がありませんでした。
[NAPTR] Mealling, M. and R. Daniel, "The Naming Authority
Pointer (NAPTR) DNS Resource Record", RFC 2915,
September 2000.
[NAPTR] 食事とM.とR.ダニエル、「命名権威指針(NAPTR)DNSリソース記録」、RFC2915、2000年9月。
Mealling, M., "Dynamic Delegation Discovery System
(DDDS) Part One: The Comprehensive DDDS", RFC 3401,
October 2002.
食事、M.、「ダイナミックな委譲発見システム(DDDS)は1つを分けます」。 「包括的なDDDS」、2002年10月のRFC3401。
Mealling, M., "Dynamic Delegation Discovery System
(DDDS) Part Two: The Algorithm", RFC 3402, October
2002.
食事、M.、「ダイナミックな委譲発見システム(DDDS)は2を分けます」。 「アルゴリズム」、RFC3402、2002年10月。
Mealling, M., "Dynamic Delegation Discovery System
(DDDS) Part Three: The Domain Name System (DNS)
Database", RFC 3403, October 2002.
食事、M.、「ダイナミックな委譲発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、2002年10月。
Klensin Informational [Page 26] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[26ページ]のRFC3467の役割
[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)を創設したプロセスの初期段階の[REGISTRAR]、「お札」は米国政府によってリリースされました。 その紙は伝統的なDNS操作で必要でない新しい用語といくつかの概念を紹介しました。 「登録」という用語はドメインの実際のオペレータとデータベース保持者に適用されました(通常トップレベルでは、グリーン以来、Paperは少ししか他の何にも関係がありませんでした)、名前を売り出して、それらを「記入者」に利用可能にした組織が「記録係」として知られていましたが。 古典的なDNSモデルでは、「ゾーンの管理者」の機能は登録と記録係の役割の両方を取り囲みました、そのモデルは名前における商業市場を予期しませんでしたが。
[RFC625] Kudlick, M. and E. Feinler, "On-line hostnames
service", RFC 625, March 1974.
[RFC625] KudlickとM.とE.Feinler、「オンラインホスト名サービス」、RFC625、1974年3月。
[RFC734] Crispin, M., "SUPDUP Protocol", RFC 734, October 1977.
[RFC734] クリスピン、M.、「SUPDUPプロトコル」、RFC734、1977年10月。
[RFC811] Harrenstien, K., White, V. and E. Feinler, "Hostnames
Server", RFC 811, March 1982.
[RFC811] HarrenstienとK.とホワイトとV.とE.Feinler、「ホスト名サーバ」、RFC811、1982年3月。
[RFC819] Su, Z. and J. Postel, "Domain naming convention for
Internet user applications", RFC 819, August 1982.
[RFC819] SuとZ.とJ.ポステル、「インターネットユーザアプリケーションのためのドメイン命名規則」、RFC819、1982年8月。
[RFC830] Su, Z., "Distributed system for Internet name
service", RFC 830, October 1982.
[RFC830] Su、Z.、「インターネット名前サービスのための分散システム」、RFC830、1982年10月。
[RFC882] Mockapetris, P., "Domain names: Concepts and
facilities", RFC 882, November 1983.
[RFC882]Mockapetris、P.、「ドメイン名:」 「概念と施設」、RFC882、11月1983日
[RFC883] Mockapetris, P., "Domain names: Implementation
specification", RFC 883, November 1983.
[RFC883]Mockapetris、P.、「ドメイン名:」 「実装仕様」、RFC883、1983年11月。
[RFC952] Harrenstien, K, Stahl, M. and E. Feinler, "DoD
Internet host table specification", RFC 952, October
1985.
[RFC952] HarrenstienとKとスタールとM.とE.Feinler、「DoDインターネット・ホストテーブル仕様」、RFC952、1985年10月。
[RFC953] Harrenstien, K., Stahl, M. and E. Feinler, "HOSTNAME
SERVER", RFC 953, October 1985.
[RFC953] HarrenstienとK.とスタールとM.とE.Feinler、「ホスト名サーバ」、RFC953、1985年10月。
[RFC1034] Mockapetris, P., "Domain names, Concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetrisと、P.と、「ドメイン名、Concepts、および施設」、STD13、RFC1034、11月1987日
Klensin Informational [Page 27] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[27ページ]のRFC3467の役割
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC1591] Postel, J., "Domain Name System Structure and
Delegation", RFC 1591, March 1994.
[RFC1591] ポステルと、J.と、「ドメインネームシステム構造と委譲」(RFC1591)は1994を行進させます。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2181] ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、1997年7月。
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content
Negotiation in HTTP", RFC 2295, March 1998
[RFC2295] HoltmanとK.とA.Mutz、「HTTPにおけるわかりやすい満足している交渉」、RFC2295、1998年3月
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax",
RFC 2396, August 1998.
[RFC2396] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day,
"Service Location Protocol, Version 2", RFC 2608, June
1999.
[RFC2608]Guttman(E.、パーキンス、C.、Veizades、J.、およびM.日)は「1999年6月にRFC2608を位置のプロトコル、バージョン2インチ調整します」。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC2671] Vixie、P.、「DNS(EDNS0)のための拡張機能」、RFC2671、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.、エド、「Aはウェブをもつれました」。 「I18N、Domain Names、およびOtherインターネットプロトコルの問題」、RFC2825、2000年5月。
[RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root",
RFC 2826, May 2000.
[RFC2826]IAB(「ユニークなDNS根のIABの技術的なコメント」、RFC2826)は2000がそうするかもしれません。
[RFC2972] Popp, N., Mealling, M., Masinter, L. and K. Sollins,
"Context and Goals for Common Name Resolution", RFC
2972, October 2000.
[RFC2972] ポップ、N.、食事、M.、Masinter、L.、およびK.Sollins、「コモンの文脈と目標は解決を命名します」、RFC2972、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] 食事とM.とR.Denenberg、Eds、「共同W3C/IETF URI計画営利団体から、報告してください」 Uniform Resource Identifier(URI)、URL、および一定のリソース名(つぼ): 「明確化と推薦」、RFC3305、8月2002日
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3439, December 2002.
[RFC3439]ブッシュと、R. and D.マイヤーと、「何らかのインターネットの建築ガイドラインと哲学」、RFC3439、12月2002日
[Seng] Seng, J., et al., Eds., "Internationalized Domain
Names: Registration and Administration Guideline for
Chinese, Japanese, and Korean", Work in Progress.
[Seng] Seng、J.、他、Eds、「国際化ドメイン名:」 「中国語、日本語、および韓国語のための登録と政権ガイドライン」は進行中で働いています。
Klensin Informational [Page 28] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[28ページ]のRFC3467の役割
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings (stringprep)", RFC 3454,
December 2002.
[STRINGPREP] ホフマンとP.とM.Blanchet、「国際化しているストリング(stringprep)の準備」、RFC3454、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に置くのに使用される特定のプロフィールがホフマン、P.、およびM.Blanchetで説明された"nameprep"と呼ばれる、「Nameprep:」 「国際化ドメイン名のためのStringprepプロフィール」、処理中の作業。
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[telnet] ポステル、J.、およびJ.レイノルズ(「telnetプロトコル仕様」、STD8、RFC854)は1983がそうするかもしれません。
Postel, J. and J. Reynolds, "Telnet Option
Specifications", STD 8, RFC 855, May 1983.
ポステル、J.、およびJ.レイノルズ(「telnetオプション仕様」、STD8、RFC855)は1983がそうするかもしれません。
[UNICODE] The Unicode Consortium, The Unicode Standard, Version
3.0, Addison-Wesley: Reading, MA, 2000. Update to
version 3.1, 2001. Update to version 3.2, 2002.
[ユニコード] ユニコード共同体、ユニコード規格、バージョン3.0、アディソン-ウエスリー: 読書、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] デイヴィス、M.、およびM.Duerst、「ユニコード規格は#15、を付加します」。 「ユニコード正常化が形成される、」、ユニコード共同体、行進2002 ユニコードStandard、バージョン3.1.1の不可欠の部分。 ( http://www.unicode.org/reports/tr15/tr15-21.html )では、利用可能です。
[WHOIS] Harrenstien, K, Stahl, M. and E. Feinler,
"NICNAME/WHOIS", RFC 954, October 1985.
[WHOIS] HarrenstienとKとスタールとM.とE.Feinler、「NICNAME/WHOIS」、RFC954、1985年10月。
[WHOIS-UPDATE] Gargano, J. and K. Weiss, "Whois and Network
Information Lookup Service, Whois++", RFC 1834, August
1995.
[WHOIS-アップデート] ガルガノ、J.、K.ウィス、および「Whoisとネットワーク情報ルックアップサービス、Whois++」、RFC1834、8月1995日
Weider, C., Fullton, J. and S. Spero, "Architecture of
the Whois++ Index Service", RFC 1913, February 1996.
ワイダーとC.とFulltonとJ.とS.スペロウ、「Whois++インデックスサービスのアーキテクチャ」、RFC1913、1996年2月。
Williamson, S., Kosters, M., Blacka, D., Singh, J. and
K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5",
RFC 2167, June 1997;
ウィリアムソン、S.とKostersとM.とBlackaとD.とシン、J.とK.Zeilstra、「紹介Whois(RWhois)はV1.5"、RFC2167と、1997年6月に議定書を作ります」。
Daigle, L. and P. Faltstrom, "The
application/whoispp-query Content-Type", RFC 2957,
October 2000.
DaigleとL.とP.Faltstrom、「whoisppアプリケーション/質問コンテントタイプ」、RFC2957、2000年10月。
Daigle, L. and P. Falstrom, "The application/whoispp-
response Content-type", RFC 2958, October 2000.
DaigleとL.とP.Falstrom、「アプリケーション/whoispp応答文書内容」、RFC2958、2000年10月。
Klensin Informational [Page 29] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[29ページ]のRFC3467の役割
[X29] International Telecommuncations Union, "Recommendation
X.29: Procedures for the exchange of control
information and user data between a Packet
Assembly/Disassembly (PAD) facility and a packet mode
DTE or another PAD", December 1997.
[X29]国際Telecommuncations組合、「推薦X.29:」 1997年12月の「Packet議会/分解(PAD)施設とパケット形態DTEか別のPADの間の制御情報と利用者データの交換のための手順。」
8. Acknowledgements
8. 承認
Many people have contributed to versions of this document or the thinking that went into it. The author would particularly like to thank Harald Alvestrand, Rob Austein, Bob Braden, Vinton Cerf, Matt Crawford, Leslie Daigle, Patrik Faltstrom, Eric A. Hall, Ted Hardie, Paul Hoffman, Erik Nordmark, and Zita Wenzel for making specific suggestions and/or challenging the assumptions and presentation of earlier versions and suggesting ways to improve them.
多くの人々がそれに入ったこのドキュメントか考えのバージョンに貢献しました。 特定の提案をする、そして/または、それらを改良するように以前のバージョンと示唆方法の仮定とプレゼンテーションに挑んで頂いて、作者は特にハラルドAlvestrand、ロブAustein、ボブ・ブレーデン、ビントン・サーフ、マット・クロフォード、レスリーDaigle、パトリクFaltstrom、エリックA.Hall、テッド・ハーディー、ポール・ホフマン、エリックNordmark、およびZitaウェンツェルに感謝したがっています。
9. Author's Address
9. 作者のアドレス
John C. Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140
マサチューセッツAve、ジョンC.Klensin1770#322ケンブリッジ、MA 02140
EMail: klensin+srch@jck.com
メール: klensin+ srch@jck.com
A mailing list has been initiated for discussion of the topics discussed in this document, and closely-related issues, at ietf-irnss@lists.elistx.com. See http://lists.elistx.com/archives/ for subscription and archival information.
メーリングリストは本書では議論した話題の議論、および ietf-irnss@lists.elistx.com の密接に関連の問題のために開始されました。 購読と記録保管所の情報に関して http://lists.elistx.com/archives/ を見てください。
Klensin Informational [Page 30] RFC 3467 Role of the Domain Name System (DNS) February 2003
ドメインネームシステム(DNS)2003年2月のKlensinの情報[30ページ]のRFC3467の役割
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Klensin Informational [Page 31]
Klensin情報です。[31ページ]
一覧
スポンサーリンク
