この文書はRFC3467の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                         J. Klensin
Request for Comments: 3467                                 February 2003
Category: Informational


                  Role of the Domain Name System (DNS)
                 ドメインネームシステム(DNS)の役割

Status of this Memo
この文書の状態


   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.
   このメモはインターネット共同体のための情報を供給します。これはインター
   ネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice
著作権表示

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

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
   1.  導入と歴史
      1.1  Context for DNS Development
      1.1  DNS開発の状況
      1.2 Review of the DNS and Its Role as Designed
      1.2 DNSとその設計された役割の再検討
      1.3 The Web and User-visible Domain Names
      1.3 ウェブとユーザが目に見えるドメイン名
      1.4 Internet Applications Protocols and Their Evolution
      1.4 インターネットアプリケーションプロトコルとその進展
   2.  Signs of DNS Overloading
   2.  DNSに負担をかけ過ぎる徴候
   3.  Searching, Directories, and the DNS
   3.  検索、ディレクトリ、DNS
      3.1 Overview
      3.1 概観
      3.2 Some Details and Comments
      3.2 いくつかの細部とコメント
   4.   Internationalization
   4.   国際化
      4.1 ASCII Isn't Just Because of English
      4.1 ASCIIは英語のためにものではありません
      4.2 The "ASCII Encoding" Approaches
      4.2 「ASCIIコード化」方法
      4.3 "Stringprep" and Its Complexities
      4.3 「文字列前処理」とその複雑さ
      4.4 The Unicode Stability Problem
      4.4 ユニコード安定性問題
      4.5 Audiences, End Users, and the User Interface Problem
      4.5 観衆、最終消費者とユーザ・インタフェース問題
      4.6 Business Cards and Other Natural Uses of Natural Languages
      4.6 自然言語の名刺と他の自然な使用
      4.7 ASCII Encodings and the Roman Keyboard Assumption
      4.7 ASCIIコードとローマ字キーボードの仮定
      4.8 Intra-DNS Approaches for "Multilingual Names"
      4.8 「多言語名」のDNS内の方法
   5.  Search-based Systems: The Key Controversies
   5.  検索ベースシステム:キー論争
   6.  Security Considerations
   6.  セキュリティの考察
   7.  References
   7.  参考文献
      7.1 Normative References
      7.1 参照する参考文献

      7.2 Explanatory and Informative References
      7.2 説明と有益な参考文献
   8.  Acknowledgements
   8.  謝辞
   9.  Author's Address
   9.  著者のアドレス
   10. Full Copyright Statement
   10. 著作権表示全文


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の既存の構造体や機能
   や内容が適切であるからではありません。この文書は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)に
   ついて決定のいくらかを再構築します。加えて、インターネットについての
   特定の決定の歴史的理由はしばしばその時代の文書の下にあり、そして、驚
   くべきことにではなく、異なった関係者が、何が起きたか、そして何が重要
   であると思われたかについて、異なった記憶を持っています。従って、下の
   準歴史物語は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]参照)の理解を仮定します。

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:
   ARPANETの始動時期後の寿命の間と、インターネット運用の最初の
   10年ぐらいは、ホスト名とアドレスの相互変換のリストはしばしば更新さ
   れた「ホストテーブル」で維持されました[RFC625][RFC811][RFC952]。名前
   自身は、印刷された形であいまい性を避け、システムが他の文字コード(特
   にEBCDIC)を使うという状態での相互運用を認めて、そしてISO6
   46[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  人々がホスト番号(アドレス)を覚えているという必要条件を排除。従来
      の電話システムでのこれと反対の明白な経験にもかかわらず、数値番号シ
      ステムが、数値ホスト番号計画を含めて、多数のホストに対してよく働き
      ませんでした。

   o  Provide stability when addresses changed.  Since addresses -- to
      some degree in the ARPANET and more importantly in the
      contemporary Internet -- are a function of network topology and
      routing, they often had to be changed when connectivity or
      topology changed.  The names could be kept stable even as
      addresses changed.
   o  アドレスが変化した時の、安定性の供給。アドレスが−ARPANET程
      度で、現代のインターネットでは特に−ネットワークトポロジーとルーティ
      ングの機能であり、しばしば接続性やトポロジーが変化した時、変えられ
      なければなりませんでした。名前は、アドレスが変化した時さえ、安定す
      るようにおかれることができました。

   o  Provide the capability to have multiple addresses associated with
      a given host to reflect different types of connectivity and
      topology.  Use of names, rather than explicit addresses, avoided
      the requirement that would otherwise exist for users and other
      hosts to track these multiple host numbers and addresses and the
      topological considerations for selecting one over others.
   o  異なったタイプの接続性とトポロジーを反映するために多数のアドレスが
      所定のホストと結び付けられるようにする能力の供給。明示的なアドレス
      ではなく名前の使用が、ユーザーと他のホストが多数のホスト番号とアド
      レスを追跡し、トポロジーを考慮していつを選択する以外の要求条件を避
      けました。

   After several years of using the host table approach, the community
   concluded that model did not scale adequately and that it would not
   adequately support new service variations.  A number of discussions
   and meetings were held which drew several ideas and incomplete
   proposals together.  The DNS was the result of that effort.  It
   continued to evolve during the design and initial implementation
   period, with a number of documents recording the changes (see
   [RFC819], [RFC830], and [RFC1034]).
   数年のホストテーブルの方式の使用後に、共同体はそのモデルが十分にスケー
   ルせず、そして十分に新しいサービスをサポートしないであろうと結論しま
   した。いくつかの考えと不完全な提案に対する多くの論議と打合せが開催さ
   れました。DNSはその努力の結果でした。これは、多くの文書が変更を記
   録するように、デザインと初期の実装時期の間に進展しつづけました
   ([RFC819][RFC830] [RFC1034]参照)。

   The goals for the DNS included:
   DNSの目的は以下を含みます:

   o  Preservation of the capabilities of the host table arrangements
      (especially unique, unambiguous, host names),
   o  ホストテーブル配置能力保存(特にユニークな、明確な、ホスト名)、

   o  Provision for addition of additional services (e.g., the special
      record types for electronic mail routing which quickly followed
      introduction of the DNS), and
   o  追加サービスの付加の準備(例えば、DNS導入直後に続いた電子メール
      ルーチングのための特別なレコード)、そして

   o  Creation of a robust, hierarchical, distributed, name lookup
      system to accomplish the other goals.
   o  他の目的を達成する強靭、階層的、分散、名前検索システムの作成。


   The DNS design also permitted distribution of name administration,
   rather than requiring that each host be entered into a single,
   central, table by a central administration.
   DNS構想は、それぞれのホストが中央管理機構によってひとつの中央表に
   入力されるのを要求するより、名前管理の分散を認めました。

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はネットワーク資源を識別するよう意図されました。例えば、個人名
   と電子メールアドレスを含むと推測があったけれども、人々や商標などを識
   別するよう意図されませんでした。同時にシステムは、共に新しいレコード
   タイプの付加を通して最初の「インターネット」クラスに、そして、潜在的
   に新しいクラスの導入を通して、柔軟に新しいデータタイプと構造体を受け
   入れるよう意図されました。適切な識別子とそれらの未来の拡張内容が予期
   できなかったので、デザインはこれらのフィールドが、ホストテーブルの限
   定されたテキスト形式だけではなく、どんな(バイナリ)情報も含めること
   ができることを規定しました。

   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ですらなく、そ
   の非常に限定された部分集合、元のホストテーブル命名規則に由来する部分
   集合でした。その部分集合の選択が、国際的な状況での可能なあいまい性を
   排除する願望を含めて、人間の要因の考慮によって運用されました。それ故
   に表現に国際的な相違を持つ文字コードが除去され、下線文字と大文字小文
   字の区別が人が読み書きするときに紛らわしいから削除(下線はハイフンと)
   された、などです。これらの考慮は同様に限定された文字集合が多くのIT
   UとISOプロトコルでプロトコル要素として用いられるという結果になっ
   たのと非常に類似しているように思われます([X29]参照)。

   Another assumption was that there would be a high ratio of physical
   hosts to second level domains and, more generally, that the system
   would be deeply hierarchical, with most systems (and names) at the
   third level or below and a very large percentage of the total names
   representing physical hosts.  There are domains that follow this
   model: many university and corporate domains use fairly deep
   hierarchies, as do a few country-oriented top level domains
   ("ccTLDs").  Historically, the "US." domain has been an excellent
   example of the deeply hierarchical approach.  However, by 1998,
   comparison of several efforts to survey the DNS showed a count of SOA
   records that approached (and may have passed) the number of distinct
   hosts.  Looked at differently, we appear to be moving toward a
   situation in which the number of delegated domains on the Internet is
   approaching or exceeding the number of hosts, or at least the number
   of hosts able to provide services to others on the network.  This
   presumably results from synonyms or aliases that map a great many
   names onto a smaller number of hosts.  While experience up to this
   time has shown that the DNS is robust enough -- given contemporary
   machines as servers and current bandwidth norms -- to be able to
   continue to operate reasonably well when those historical assumptions
   are not met (e.g., with a flat, structure under ".COM" containing
   well over ten million delegated subdomains [COMSIZE]), it is still
   useful to remember that the system could have been designed to work
   optimally with a flat structure (and very large zones) rather than a
   deeply hierarchical one, and was not.
   もう1つの仮定が2番目のレベルのドメインに物理的なホストの高い比率が
   あるであろうということで、そして、より一般に、システムが深く階層的で、
   たいていのシステム(そして名前)の第3レベルかそれ以下にあり、物理的
   なホストを表している名前の比率が非常に高いという事です。このモデルに
   従うドメインがあります:多くの大学と企業のドメインがかなり深い階層を
   使い、そして少数の国別最上位ドメイン(「ccTLDs」)もそうです。歴史的
   に、「US.」ドメインは深い階層的なアプローチの優秀な例でした。しかしな
   がら、1998、DNSを観察する努力がSOAの数が異なるホストの数に
   近づく(そして超えたかもしれない)ことを明らかにました。他から見ても、
   我々はインターネット上の委任されたドメインの数が、ホストの数、あるい
   は少なくともネットワークの上で他にサービスを供給することが可能なホス
   トの数に接近しているか超える状態にあるように思われます。これは多分、
   小数のホストのが非常に多くの名前の同意語あるいは別名をマップする結果
   として生じます。今までの経験から、DNSが−与えられた時代のサーバ用
   の機械と現在の帯域幅標準で−歴史的仮定が満たされなくても(例えば
   「.COM」下の平らな構造は1000万以上のサブドメインを含みます
   [COMSIZE])、上手に動作しつづけるける事ができ可能であるのに十分強靭
   であることを示ました、システムが深く階層的なものよりどちらかと言うと、
   平らな構造(そして非常に大きいゾーン)で働くように最適化されたことを
   覚えていることはまだ有用です。

   Similarly, despite some early speculation about entering people's
   names and email addresses into the DNS directly (e.g., see
   [RFC1034]), electronic mail addresses in the Internet have preserved
   the original, pre-DNS, "user (or mailbox) at location" conceptual
   format rather than a flatter or strictly dot-separated one.
   Location, in that instance, is a reference to a host. The sole
   exception, at least in the "IN" class, has been one field of the SOA
   record.
   同様に、人々の名前と電子メールアドレスを直接DNSに入力するというあ
   る初期の推測にもかかわらず(例えば、[RFC1034]参照) 、インターネット
   の電子メールアドレスが、フラットか厳密にドット区切りではなく、DNS
   の前からある元の「ユーザ(メールボックス)アット場所」の概念形式を維
   持しました。場所は、この場合、ホストの参照です。唯一の例外は、少なく
   とも「IN」クラスでの、SOAレコードの1つのフィールドでした。

   Both the DNS architecture itself and the two-level (host name and
   mailbox name) provisions for email and similar functions (e.g., see
   the finger protocol [FINGER]), also anticipated a relatively high
   ratio of users to actual hosts.  Despite the observation in RFC 1034
   that the DNS was expected to grow to be proportional to the number of
   users (section 2.3), it has never been clear that the DNS was
   seriously designed for, or could, scale to the order of magnitude of
   number of users (or, more recently, products or document objects),
   rather than that of physical hosts.
   DNS構造自体と、Eメールや類似機能(例えばフィンガープロトコル
   [FINGER])の2層供給の両方は、同じく実際のホストへのユーザーの比較的
   高い比率を予期します。DNSがユーザ数程度に成長することを期待される
   というRFC1034での報告にもかかわらず(2.3章)、DNSが物理ホ
   スト規模ではなくユーザ数規模で(又は、最近では、製品や文書オブジェク
   ト規模)真剣に設計されたか、可能なのか、スケールするのか、が一度も明
   確でありませんでした。

   Just as was the case for the host table before it, the DNS provided
   critical uniqueness for names, and universal accessibility to them,
   as part of overall "single internet" and "end to end" models (cf.
   [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.
   ちょうど前にホストテーブルで本当であったように、DNSは全体的な「ひ
   とつのインターネット」の部分と「エンドエンド」モデルでの、名前の重大
   な一意性と普遍的な利用性を供給します([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で「Aレコー
   ド」ドメイン名を使うウェブのデザインの決定は、無目的のシステムより、
   いくつかの点で重大なミスであることが分かりました。タイピングの便利さ
   と簡単に覚えられる商品名ドメイン名を作る願望は、DNSを平坦にし、多
   くの人々がCOMの第2レベル名(又は、いくつかの国で、そのccTLD
   の第2か第3レベル名)が有意義な全てと認識します。この認識は追加の名
   前を「売る」ことを切望していたあるドメイン名登録係[REGISTRAR]によって
   強化されました。そして、もちろん、1つの商品毎に第2レベル(あるいは
   最上位レベル)が必要と言う認識は、名前がネットワーク資源の集合(通常
   組織)と結び付けられるようにするより、登録されている名前の数の速い加
   速を導きました。その加速は、順に、明らかに名前毎の請求をしている登録
   係と、「サイバースクワッタ」と、名前「販売」ビジネスの人たちに利益を
   もたらしましたが、しかしこれはインターネット全体の利益かどうか明らか
   ではありません。

   This emphasis on second-level domain names has also created a problem
   for the trademark community.  Since the Internet is international,
   and names are being populated in a flat and unqualified space,
   similarly-named entities are in conflict even if there would
   ordinarily be no chance of confusing them in the marketplace.  The
   problem appears to be unsolvable except by a choice between draconian
   measures.  These might include significant changes to the legislation
   and conventions that govern disputes over "names" and "marks".  Or
   they might result in a situation in which the "rights" to a name are
   typically not settled using the subtle and traditional product (or
   industry) type and geopolitical scope rules of the trademark system.
   Instead they have depended largely on political or economic power,
   e.g., the organization with the greatest resources to invest in
   defending (or attacking) names will ultimately win out.  The latter
   raises not only important issues of equity, but also the risk of
   backlash as the numerous small players are forced to relinquish names
   they find attractive and to adopt less-desirable naming conventions.
   この第2レベルドメイン名に対する重要視は商標社会での問題を生じました。
   インターネットが国際的で、そして名前が平坦で無条件の空間にあるので、
   たとえ市場でほとんど混乱所生じさせていなくても、類似した名前の衝突を
   生じました。問題は厳しい基準を選択する以外解決不可能であるように思わ
   れます。これらは「名前」と「記号」の論争を管理する法律と習慣に対する
   重要な変更を含むかもしれません。あるいは微妙で伝統的な製品(あるいは
   産業)タイプと、商標の地理的範囲の規則を使う、名前の「権利」が一般に
   安定していない状態という結果になるかもしれません。その代わりに彼らは
   主に政治力、あるいは経済力に依存しました、例えば、名前を防御(あるい
   は攻撃)することに投資する最大の資源を持つ組織は究極的に成功するでしょ
   う。後者は公平の重要な問題だけではなく、多数の小さいプレーヤーが魅力
   的な名前を放棄して、より望ましくない名前を採用することを強いられるよ
   うに、反動の危険も引き起こします。

   Independent of these sociopolitical problems, content distribution
   issues have made it clear that it should be possible for an
   organization to have copies of data it wishes to make available
   distributed around the network, with a user who asks for the
   information by name getting the topologically-closest copy.  This is
   not possible with simple, as-designed, use of the DNS: DNS names
   identify target resources or, in the case of email "MX" records, a
   preferentially-ordered list of resources "closest" to a target (not
   to the source/user).  Several technologies (and, in some cases,
   corresponding business models) have arisen to work around these
   problems, including intercepting and altering DNS requests so as to
   point to other locations.
   これらの社会政治問題から独立に、コンテンツ流通問題が、名指しで情報を
   求めるユーザーがトポロジー的に最も近いコピーを得るように、組織が、ネッ
   トワークの周辺に配った利用可能なデータコピーを持つことが可能な事を明
   確にしました。これは単純であるように設計されたDNSで利用可能であり
   ません:DNS名が目標資源を識別するか、あるいは、電子メールの「MX」
   レコードで、目標に近い(発信源/ユーザではない)優先順位つき資源リス
   トです。いくつかの技術(そして、ある場合には、対応するビジネスモデル)
   が、DNS要求を横取りし他の場所を指し示すように変更する事を含め、問
   題の周りで働くために生じました。

   Additional implications are still being discovered and evaluated.
   追加の意味がまだ発見されて、そして評価されています。

   Approaches that involve interception of DNS queries and rewriting of
   DNS names (or otherwise altering the resolution process based on the
   topological location of the user) seem, however, to risk disrupting
   end-to-end applications in the general case and raise many of the
   issues discussed by the IAB in [IAB-OPES].  These problems occur even
   if the rewriting machinery is accompanied by additional workarounds
   for particular applications.  For example, security associations and
   applications that need to identify "the same host" often run into
   problems if DNS names or other references are changed in the network
   without participation of the applications that are trying to invoke
   the associated services.
   DNS問合せを妨害しDNSの名前に書き直す(あるいはユーザーのトポロ
   ジー的な場所に基づいて解決処理を変更する)方法が、しかしながら、一般
   的な場合でエンドエンドアプリケーションを混乱させる危険があり、そして
   [IAB-OPES]でIABによって論じられた問題の多くを発生するように思われ
   ます。これらの問題は、たとえ書き直し機械が特定のアプリケーションのた
   めに追加の回避策を行っていても、起こります。例えば、セキュリティアソ
   シエーションと「同じホスト」を識別する必要があるアプリケーションが、
   もしDNS名や他の参照値が、提携サービスに呼びかけるアプリケーション
   の参加なしでネットワークを変更するなら、しばしば問題に出くわします。

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
   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はこの悲観的な解釈の具体例でもあるし、例外でもあります。DNS
   は、ホストテーブルシステムが有効寿命を終えたと考えられた後の、第2世
   代の展開です。その時代の計算発達水準を反映させられた重大な試みがあり
   ました。しかしながら、展開は期待されるよりずっと遅く(そして多くのサ
   イトにとって苦痛であった)、そして中央のネットワーク管理者からのある
   固定した締切期限が展開に必要でした(数回緩和されたが)。核心機能は少
   なくとも相応によく能力を発揮し続けるのに、機能性を加えるために、今そ
   れを置き換えるのは、多分非常に難しいでしょう。

   There are many, perhaps obvious, examples of this.  Despite many
   known deficiencies and weaknesses of definition, the "finger" and
   "whois" [WHOIS] protocols have not been replaced (despite many
   efforts to update or replace the latter [WHOIS-UPDATE]).  The Telnet
   protocol and its many options drove out the SUPDUP [RFC734] one,
   which was arguably much better designed for a diverse collection of
   network hosts.  A number of efforts to replace the email or file
   transfer protocols with models which their advocates considered much
   better have failed.  And, more recently and below the applications
   level, there is some reason to believe that this resistance to change
   has been one of the factors impeding IPv6 deployment.
   これの多くの、多分明白な、例があります。多くの既知の欠陥と鮮明度の弱
   点にもかかわらず、「finger」と「whois」[WHOIS]プロトコルは置き換えら
   れませんでした(後者を更新するか置き換える努力[WHOIS-UPDATE]にもかか
   わらず)置き換えられませんでした。Telnetプロトコルとその多くのオプショ
   ンはSUPDUP[RFC734]を追い払いました、そしてこれは多分ずっと良くネット
   ワークホストの多様な収集のために設計されていました。電子メールあるい
   はファイル転送プロトコルを、提唱者がずっと良く考慮したモデルで置き換
   える多くの努力が失敗しました。そして、より最近、そしてアプリケーショ
   ンレベル下で、変化に対するこの抵抗が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章で簡単に論議します)。

   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」を管理したいと考え(そして好み、DN
      S命名規則で許され、同じ「Joe's.com」のつづりで、同じ方法で変換しす
      る)、伝統的な商標の原則で対立や混乱がで存在しなくても、商標権によ
      り要求するでしょう。

   o  Many organizations wish to have different web sites under the same
      URL and domain name.  Sometimes this is to create local variations
      -- the Widget Company might want to present different material to
      a UK user relative to a US one -- and sometimes it is to provide
      higher performance by supplying information from the server
      topologically closest to the user.  If the name resolution
      mechanism is expected to provide this functionality, there are
      three possible models (which might be combined):
   o  多くの組織が同じURLとドメイン名下で異なったウェブサイトを持つこ
      とを望みます。時々これはローカルな変化を作るはずです−ウィジェット
      会社は合衆国と英国ユーザーに異なった資料を提出することを望むかもし
      れません−そして時々これはトポロジー的に最も近いサーバーからユーザ
      へ情報を供給することによってより高い性能を供給するはずです。もし名
      前解決メカニズムがこの機能を供給することを期待されるなら、3つの可
      能なモデルがあります(組み合わせるかもしれない):

      -  supply information about multiple sites (or locations or
         references).  Those sites would, in turn, provide information
         associated with the name and sufficient site-specific
         attributes to permit the application to make a sensible choice
         of destination, or
      -  多数のサイト情報(あるいは場所や参照)を供給。それらのサイトは、
         名前とアプリケーションに賢明な宛先選択を許すのに十分なサイト特
         有の属性と結び付いた、情報を供給するであろう、あるいは。

      -  accept client-site attributes and utilize them in the search
         process, or
      -  クライアントサイト属性を受け入れて、捜索プロセスで、それらを利
         用する、あるいは。

      -  return different answers based on the location or identity of
         the requestor.
      -  要求者の場所や識別子に基づいて異なった答えを返す。

   While there are some tricks that can provide partial simulations of
   these types of function, DNS responses cannot be reliably conditioned
   in this way.
   この種の機能の部分的なシミュレーションを供給することができるあるトリッ
   クがあるが、DNS回答はこのようなことに対して信頼できません。

   These, and similar, issues of performance or content choices can, of
   course, be thought of as not involving the DNS at all.  For example,
   the commonly-cited alternate approach of coupling these issues to
   HTTP content negotiation (cf. [RFC2295]), requires that an HTTP
   connection first be opened to some "common" or "primary" host so that
   preferences can be negotiated and then the client redirected or sent
   alternate data.  At least from the standpoint of improving
   performance by accessing a "closer" location, both initially and
   thereafter, this approach sacrifices the desired result before the
   client initiates any action.  It could even be argued that some of
   the characteristics of common content negotiation approaches are
   workarounds for the non-optimal use of the DNS in web URLs.
   これらや類似の性能や内容選択の問題は、もちろん、まったくDNSなしで
   考えることができます。例えば、HTTPコンテンツ交渉の問題のよく言わ
   れる代わりの方法は([RFC2295]参照)、HTTP接続を最初「共通」あつい
   は「主」ホストに接続し、優先交渉を行い、そしてクライアントをリダイレ
   クトするか、代用データを送信する事です。少なくとも「より近い」場所に
   アクセスすることによって性能を改善するとの見地からは、最初とその後の
   両方で、この方法はクライアントが行動を始める前の望ましい結果を犠牲に
   します。共通コンテンツ交渉方法の特性のいくつかは、ウェブURLでのD
   NSの望ましくない使い方の回避策であると論じることができます。

   o  Many existing and proposed systems for "finding things on the
      Internet" require a true search capability in which near matches
      can be reported to the user (or to some user agent with an
      appropriate rule-set) and to which queries may be ambiguous or
      fuzzy.  The DNS, by contrast, can accommodate only one set of
      (quite rigid) matching rules.  Proposals to permit different rules
      in different localities (e.g., matching rules that are TLD- or
      zone-specific) help to identify the problem.  But they cannot be
      applied directly to the DNS without either abandoning the desired
      level of flexibility or isolating different parts of the Internet
      from each other (or both).  Fuzzy or ambiguous searches are
      desirable for resolution of names that might have spelling
      variations and for names that can be resolved into different sets
      of glyphs depending on context.  Especially when
      internationalization is considered, variant name problems go
      beyond simple differences in representation of a character or
      ordering of a string.  Instead, avoiding user astonishment and
      confusion requires consideration of relationships such as
      languages that can be written with different alphabets, Kanji-
      Hiragana relationships, Simplified and Traditional Chinese, etc.
      See [Seng] for a discussion and suggestions for addressing a
      subset of these issues in the context of characters based on
      Chinese ones.  But that document essentially illustrates the
      difficulty of providing the type of flexible matching that would
      be anticipated by users; instead, it tries to protect against the
      worst types of confusion (and opportunities for fraud).
   o  「インターネットで何かを見つける」ための多くの既存と提案されたシス
      テムが、ユーザ(ありは適切な規則のユーザエージェント)への報告に近
      似一致の検索能力を必要とし、これは問合せがあいまいです。DNSは、
      それと対照的に、(非常に厳密な)一致規則を1つだけ収容できます。異
      なる場所での異なる規則(例えば、TLDやゾーン特有の一致規則)の提
      案が問題を見分けます。けれどもそれらは、柔軟性の望ましいレベルを断
      念するか、あるいはインターネットの異なる部分をそれぞれ切り離すか、
      でないと、直接DNSに適用できません。あいまいな探索は複数のつづり
      の名前の解決や、文脈によって異なる字形に変換される名前で望ましいで
      す。特に国際化が考慮される時、方言名問題は、文字の表現あるいは文字
      列の順序における単純な相違を越えています。それよりも、ユーザー驚き
      と混乱を避けるには、異なったアルファベットで書かれる言語、漢字と平
      仮名の関係、簡易と伝統的な中国語などの考慮を必要とします。中国語に
      基づいた文字で、これらの問題の一部を扱う論議と提案のために[Seng]を
      見てください。しかし、上記の文書は本質的にユーザーによって予期され
      る柔軟な一致を供給することの困難を説明し、その代わりに、最悪の混乱
      (そして詐欺可能性)から保護しようとします。

   o  The historical DNS, and applications that make assumptions about
      how it works, impose significant risk (or forces technical kludges
      and consequent odd restrictions), when one considers adding
      mechanisms for use with various multi-character-set and
      multilingual "internationalization" systems.  See the IAB's
      discussion of some of these issues [RFC2825] for more information.
   o  様々な文字集合と多言語「国際化」システムを考えるとき、歴史的DNS
      と、DNSがどのように働くかを仮定をするアプリケーションが、重要な
      危険(あるいは技術的馬鹿と当然の変な制限の影響力)を課します。もっ
      と多くの情報のために、IABのこれらの問題の論議を見てください
      [RFC2825]。

   o  In order to provide proper functionality to the Internet, the DNS
      must have a single unique root (the IAB provides more discussion
      of this issue [RFC2826]).  There are many desires for local
      treatment of names or character sets that cannot be accommodated
      without either multiple roots (e.g., a separate root for
      multilingual names, proposed at various times by MINC [MINC] and
      others), or mechanisms that would have similar effects in terms of
      Internet fragmentation and isolation.
   o  インターネットに適切な機能性を供給するために、DNSは一つのユニー
      クなルートを持たなくてはなりません(IABはこの問題さらに多くにの
      議論を用意する[RFC2826])。名前や文字集合のローカルな扱いのための
      多くの願望があります、これは多数のルート(例えば、MINC[MINC]や
      他の人たちによって何度も提案された、多言語名のための別ルート)、あ
      るいはインターネットの分裂や隔離と類似効果を持つメカニズムなしで受
      け入れることはできません。

   o  For some purposes, it is desirable to be able to search not only
      an index entry (labels or fully-qualified names in the DNS case),
      but their values or targets (DNS data).  One might, for example,
      want to locate all of the host (and virtual host) names which
      cause mail to be directed to a given server via MX records.  The
      DNS does not support this capability (see the discussion in
      [IQUERY]) and it can be simulated only by extracting all of the
      relevant records (perhaps by zone transfer if the source permits
      doing so, but that permission is becoming less frequently
      available) and then searching a file built from those records.
   o  ある目的で、インデックス項目(DNSの場合ラベルあるいは完全指定名)
      だけではなく、その値あるいは標的(DNSデータ)を検索することが可
      能なことは望ましいです。例えば、MXレコードで特定のメールサーバに
      メールを送る結果となるホスト(と仮想ホスト)名のすべての場所を突き
      止めることを望むかもしれません。DNSはこの能力をサポートしません
      ([IQUERY]の議論を見てください)、そしてこれはただ適切なレコード
      (多分もしソースが許すならゾーン転送によって、しかしその許可はあま
      り利用可能でありません)のすべてを抜き出し、次にそれらのレコードか
      ら構築されたファイルを検索することによって真似ることができます。

   o  Finally, as additional types of personal or identifying
      information are added to the DNS, issues arise with protection of
      that information.  There are increasing calls to make different
      information available based on the credentials and authorization
      of the source of the inquiry.  As with information keyed to site
      locations or proximity (as discussed above), the DNS protocols
      make providing these differentiated services quite difficult if
      not impossible.
   o  最終的に、追加タイプの個人や識別情報がDNSに加えられる時、その情
      報の保護の問題が起こります。問合せ元の資格証明と認可に基づき、異な
      る情報を利用可能にする追加呼出があります。(上で論じられるように)
      サイトの場所あるいは近くに基づく情報は、DNSプロトコルは、もし不
      可能でないとしても、これらの区分サービスを用意するが非常に難しいで
      す。

   In each of these cases, it is, or might be, possible to devise ways
   to trick the DNS system into supporting mechanisms that were not
   designed into it.  Several ingenious solutions have been proposed in
   many of these areas already, and some have been deployed into the
   marketplace with some success.  But the price of each of these
   changes is added complexity and, with it, added risk of unexpected
   and destabilizing problems.
   これらのケースのそれぞれで、DNSが意図しなかったメカニズムをサポー
   トするようにDNSシステムをだます方法を考案することが可能、あるいは
   可能かもしれません。いくつかの巧妙な解決がすでにこれらのエリアの多く
   で提案されました、そしていくつかがいずれかの市場の中に配置され、成功
   しました。けれどもこれらの変更のそれぞれの付加的な複雑さと、意外な不
   安定さの問題の危険を加えました。

   Several of the above problems are addressed well by a good directory
   system (supported by the LDAP protocol or some protocol more
   precisely suited to these specific applications) or searching
   environment (such as common web search engines) although not by the
   DNS.  Given the difficulty of deploying new applications discussed
   above, an important question is whether the tricks and kludges are
   bad enough, or will become bad enough as usage grows, that new
   solutions are needed and can be deployed.
   上記の問題のいくつかは、良いディレクトリシステム(LDAPプロトコル
   やより正確にこれらの特定のアプリケーションに適したプロトコルによって)
   あるいは探索環境(普通のWebサーチ・エンジンなど)によって上手に扱
   われますが、DNSは上手に扱いません。上記の様に新しいアプリケーショ
   ンを実装することが困難であるという条件のもとでの重要な質問が、問題の
   あるトリックとクラッジ、あるいは、あまりにも広く使われる過ぎてる時、
   新しい解決法が必要か、配置できるか、という事です。

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のパッチや
   クラッジや回避策ではなく、探索可能システムであることを示唆します。

   The following points illustrate particular aspects of this
   conclusion.
   次のポイントはこの結論の特定の局面を説明します。

   o  A directory system would not require imposition of particular
      length limits on names.
   o  ディレクトリシステムが名前の特定の長さの限界の強制を必要としない
      でしょう。

   o  A directory system could permit explicit association of
      attributes, e.g., language and country, with a name, without
      having to utilize trick encodings to incorporate that information
      in DNS labels (or creating artificial hierarchy for doing so).
   o  ディレクトリシステムが明白に名前に、例えば言語や国などの、属性を認
      め、DNSラベルにその情報を取り入れるためにトリッキーなコーディン
      グ(あるいは人工的階層)を利用する必要はないでしょう。

   o  There is considerable experience (albeit not much of it very
      successful) in doing fuzzy and "sonex" (similar-sounding) matching
      in directory systems.  Moreover, it is plausible to think about
      different matching rules for different areas and sets of names so
      that these can be adapted to local cultural requirements.
      Specifically, it might be possible to have a single form of a name
      in a directory, but to have great flexibility about what queries
      matched that name (and even have different variations in different
      areas).  Of course, the more flexibility that a system provides,
      the greater the possibility of real or imagined trademark
      conflicts.  But the opportunity would exist to design a directory
      structure that dealt with those issues in an intelligent way,
      while DNS constraints almost certainly make a general and
      equitable DNS-only solution impossible.
   o  (それほど成功してないにもかかわらず)ディレクトリシステムでファジー
      一致あるいは「sonex」(類似に聞こえる)一致の相当の経験があります。
      さらに、ローカルな文化的必要条件に適合するため、異なるエリアと名前
      に対し、異なる一致規則を考えこともっともらしいです。特に、ディレク
      トリで名前のひとつの形式を持つが、どの質問がその名前に一致するかに
      ついて、大きい柔軟性を持つ(そして異なるエリアで異なる相違を持つ)
      ことは可能であるかもしれません。もちろん、システムがより多くの柔軟
      性を供給すると、それだけ商標の対立の可能性がより大きい、もしくは大
      きいと想像されます。けれども知的な方法でそれらの問題を扱うディレク
      トリ構造体を設計する機会は存在するであろう、他方DNS制約がほとん
      ど確かに一般的な、そして均等なDNSだけの解決を不可能にします。

   o  If a directory system is used to translate to DNS names, and then
      DNS names are looked up in the normal fashion, it may be possible
      to relax several of the constraints that have been traditional
      (and perhaps necessary) with the DNS.  For example, reverse-
      mapping of addresses to directory names may not be a requirement
      even if mapping of addresses to DNS names continues to be, since
      the DNS name(s) would (continue to) uniquely identify the host.
   o  もしディレクトリシステムが名前をDNSに翻訳するために使われ、そし
      て次にDNS名が標準的な方法で検索されるなら、DNSで伝統的(そし
      て多分必要であった)制約のいくつかを和らげることは可能であるかもし
      れません。例えば、たとえアドレスからDNS名への翻訳を継続していて
      も、DNS名がユニークにホストを識別する(し続ける)であろうから、
      アドレスからディレクトリ名への反対翻訳が必要条件ではないかもしれま
      せん。

   o  Solutions to multilingual transcription problems that are common
      in "normal life" (e.g., two-sided business cards to be sure that
      recipients trying to contact a person can access romanized
      spellings and numbers if the original language is not
      comprehensible to them) can be easily handled in a directory
      system by inserting both sets of entries.
   o  「標準的な生活」でありふれた多言語の転写問題に対する解決(例えば、
      両面名刺で、これは受取人が連絡を取ろうとする時、元の言語が理解でき
      なくても、理解できるつづりと数字にアクセスできることを確かにします)
      が両方の項目設定を差し込むことによってディレクトリシステムで容易に
      処理されることができます。

   o  A directory system could be designed that would return, not a
      single name, but a set of names paired with network-locational
      information or other context-establishing attributes.  This type
      of information might be of considerable use in resolving the
      "nearest (or best) server for a particular named resource"
      problems that are a significant concern for organizations hosting
      web and other sites that are accessed from a wide range of
      locations and subnets.
   o  戻るであろうディレクトリシステムが、ひとつの名前ではなく、ネットワー
      ク位置情報や他のコンテキスト確立情報を伴う名前の集合を返すように、
      設計できたます。このタイプの情報が、「特定の命名された資源に最も近
      い(もしくは最も良い)サーバ」の解決での使用、これはウェブをホスティ
      ングする組織や広範囲の場所とサブネットからアクセスされる他のサイト
      で、重要な懸念を考慮すべきかもしれません。

   o  Names bound to countries and languages might help to manage
      trademark realities, while, as discussed in section 1.3 above, use
      of the DNS in trademark-significant contexts tends to require
      worldwide "flattening" of the trademark system.
   o  国と言葉に制約された名前が商標の現実の処理を手伝うかもしれないませ
      ん、他方、上記1.3章で論じられるように、商標の意味の文脈でのDN
      Sの使用は商標システムを世界的に「平らにする」ことを必要とする傾向
      があります。

   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が異なる文字集合を扱い(DN
   Sや他のシステムで使われたビットの中にどのように翻訳されるかに関わら
   ず)、情報か他のものの修正か識別の引数を受入れるか返します。アプリケー
   ションがこのような変更をする必要があると、それはDNS呼出を変えるの
   と、ディレクトリサービスを呼出しそれからDNSを呼び出すのでは、変更
   があまりありません(多くの状態で、両方の行動がひとつのAPI呼出で達
   成できます)。

   A directory approach can be consistent both with "flat" models and
   multi-attribute ones.  The DNS requires strict hierarchies, limiting
   its ability to differentiate among names by their properties.  By
   contrast, modern directories can utilize independently-searched
   attributes and other structured schema to provide flexibilities not
   present in a strictly hierarchical system.
   ディレクトリ方法が共に「平ら」モデルと多特質で一貫し得ます。DNSは、
   それらの特性付きの名前を区別するその能力を制限して、厳密な階層を必要
   とします。それと対照して、近代的なディレクトリが厳密に階層的なシステ
   ムで存在していない柔軟性を供給するために独立して捜索された属性と他の
   構造化された図解を利用することができます。

   There is a strong historical argument for a single directory
   structure (implying a need for mechanisms for registration,
   delegation, etc.).  But a single structure is not a strict
   requirement, especially if in-depth case analysis and design work
   leads to the conclusion that reverse-mapping to directory names is
   not a requirement (see section 5).  If a single structure is not
   needed, then, unlike the DNS, there would be no requirement for a
   global organization to authorize or delegate operation of portions of
   the structure.
   (登録、委任などのためにメカニズムの必要を暗示している)ひとつのディ
   レクトリ構造体に強い歴史的の論拠があります。けれどもひとつの構造体が、
   特にもし深く事例分析と構想の仕事がディレクトリ名への逆翻訳が必要条件
   ではないという結論に導くなら、厳密な必要条件ではありません(5章参照)。
   もしひとつの構造体が必要とされないなら、DNSと異なり、構造体の部分
   の運用を公認するか、あるいは委任するグローバルな組織の必要がないでしょ
   う。

   The "no single structure" concept could be taken further by moving
   away from simple "names" in favor of, e.g., multiattribute,
   multihierarchical, faceted systems in which most of the facets use
   restricted vocabularies.  (These terms are fairly standard in the
   information retrieval and classification system literature, see,
   e.g., [IS5127].)  Such systems could be designed to avoid the need
   for procedures to ensure uniqueness across, or even within, providers
   and databases of the faceted entities for which the search is to be
   performed.  (See [DNS-Search] for further discussion.)
   「ひとつでない構造体」の概念は、単純な「名前」を親切なものにするのを
   促進します、例えば、多属性、多層、側面の大部分が限定された語彙を使う
   側面システムです。(これらの用語は情報検索と分類システム学でかなり標
   準です、例えば、[IS5127]参照。)このようなシステムが検索が実行される
   側面項目のプロバイダ間やデータ、あるいは内での一様性の保障の必要性を
   避けます。(これ以上の議論は[DNS-Search]参照。)

   While the discussion above includes very general comments about
   attributes, it appears that only a very small number of attributes
   would be needed.  The list would almost certainly include country and
   language for internationalization purposes.  It might require
   "charset" if we cannot agree on a character set and encoding,
   although there are strong arguments for simply using ISO 10646 (also
   known as Unicode or "UCS" (for Universal Character Set) [UNICODE],
   [IS10646] coding in interchange.  Trademark issues might motivate
   "commercial" and "non-commercial" (or other) attributes if they would
   be helpful in bypassing trademark problems.  And applications to
   resource location, such as those contemplated for Uniform Resource
   Identifiers (URIs) [RFC2396, RFC3305] or the Service Location
   Protocol [RFC2608], might argue for a few other attributes (as
   outlined above).
   上記の議論は属性についての非常に一般的なコメントを含むが、ただ属性の
   非常に小さい数だけが必要とされるであろうと思われます。リストは国際化
   の目的のためにほとんど確かに国と言語を含むでしょう。交換でISO10
   646(ユニコードあるいは「UCS」(普遍的文字集合)と知られる)
   [UNICODE][IS10646]コードを使うことに対して強い論拠があるけれども、文
   字集合とコーディングについて合意することができないなら、「charset」を
   必要とするかもしれません。商標問題で、もしそれらが商標問題の回避の助
   けになるなら、「営利」と「非営利」(あるいは他の)属性に興味が起こる
   かもしれません。そして、一様リソース識別子(URI)[RFC2396, RFC3305]
   やサービス場所プロトコル[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.
   この文書の基礎となっている考えの多くが、DNSの国際化の考察か、ある
   いは特に、ASCIIの伝統的なDNS部分集合で表現できない言語や命名
   システムからDNS機能へのアクセスを供給することの考察によって動かさ
   れました。この文書が他のフォーラムで大規模な平行した議論にの絵を描く
   けれども、適切な仕事の多くがIETFの「国際化ドメイン名」ワーキング
   グループ(IDN−WG)でされました。この章は、「国際化DNS」ある
   いは「多言語DNS」が探究された時に学ばれたことの評価を含み、そして
   その評価に基づいて将来のステップを示唆します。

   When the IDN-WG was initiated, it was obvious to several of the
   participants that its first important task was an undocumented one:
   to increase the understanding of the complexities of the problem
   sufficiently that naive solutions could be rejected and people could
   go to work on the harder problems.  The IDN-WG clearly accomplished
   that task. The beliefs that the problems were simple, and in the
   corresponding simplistic approaches and their promises of quick and
   painless deployment, effectively disappeared as the WG's efforts
   matured.
   IDN−WGが始まった時、その最初の重要な仕事が文書化されていないも
   のであったことは関係者の数人に明白でした:十分に問題の複雑さの理解を
   増やし、それほど原始的な解決が拒絶され、そして人々がもっと難しい問題
   の仕事に出かけることができました。IDN−WGは明らかにその仕事を達
   成しました。問題が単純だという信念と、対応する単純化した方法と、それ
   らの速く痛みがない展開の約束は、WGの努力の成熟に従って効率的に消滅
   しました。

   Some of the lessons learned from increased understanding and the
   dissipation of naive beliefs should be taken as cautions by the wider
   community: the problems are not simple. Specifically, extracting
   small elements for solution rather than looking at whole systems, may
   result in obscuring the problems but not solving any problem that is
   worth the trouble.
   深い理解から得られた教訓と、原始的信念の消散はより広い共同体にとって
   警告と思われるべきです:問題は単純ではありません。特に、システム全体
   を見ないで、解決のために小さい要素を引き抜くことは、問題を不明瞭にし、
   しかしも障害を起こす問題を何も解決しないという結果をもたらすかもしれ
   ません。

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).
   mid-70sで選択されたホスト名規則は、出発点であったけれども、「英語がA
   SCIIを使うからASCII」ではありませんでした。我々が見つけたほ
   とんどすべての他のスクリプト(そしてもし我々がISO646国際参照版
   の残りの文字を許すならASCIIでさえ)はASCIIに限定されたホス
   ト名(1.1章「LDH」参照)よりいっそう複雑です。そしてASCIIは
   英語を完全に表すには十分ではありません−ASCIIに現われない文字あ
   るいは区別的発音符でだけ正確につづられその言語におけるいくつかの単語
   があります。より広範囲のスクリプト選択で、ある例で、大文字小文字の変
   換が、一方から他方へは働くが、逆は可能ではありません。他のもので、文
   字の代わりの方法について慣習があり(その言語で、文字符号化[だけ]で
   はなく)これはほとんど働きますが常にではありません。そして、ユニコー
   ド/10646が同じ文字(「字形」ではなく「文字」です、ここで故意に
   使われています)を表す異なった方法を供給するという、符号化問題があり
   ます。そして、まだ他のもので、2つの字形が「一致」するかどうかの質問
   があり、そしてそれは二値の答えではなく、距離関数問題かもしれません。
   これらの問題へのIETFのアプローチは事前一致正規化を必要とします
   (下記の「文字列前処理」の論議を見ます)。

   The IETF has resisted the temptations to either try to specify an
   entirely new coded character set, or to pick and choose Unicode/10646
   characters on a per-character basis rather than by using well-defined
   blocks.  While it may appear that a character set designed to meet
   Internet-specific needs would be very attractive, the IETF has never
   had the expertise, resources, and representation from critically-
   important communities to actually take on that job.  Perhaps more
   important, a new effort might have chosen to make some of the many
   complex tradeoffs differently than the Unicode committee did,
   producing a code with somewhat different characteristics.  But there
   is no evidence that doing so would produce a code with fewer problems
   and side-effects.  It is much more likely that making tradeoffs
   differently would simply result in a different set of problems, which
   would be equally or more difficult.
   IETFは、完全に新しい文字セットコードを指定したり、明確に定義され
   たブロックではなく、ユニコード/10646から文字毎の選択をする誘惑
   に抵抗しました。インターネット特有の必要を満たすよう意図された文字セッ
   トが非常に魅力的であるであろうように思われるかもしれないが、IETF
   は一度も仕事を行っている批判的重要な共同体の専門的知識と資源と代表を
   持っていたことがありません。多分もっと重要なのは、いくらか異なった文
   字のコードを作り出す新しい取り組みは、ユニコード委員会がしたのより、
   いくつかの複雑なトレードオフの難しい選択があるかもしれない事です。け
   れどもそうすることが、より少ない問題と副作用でコードを作り出すであろ
   う、という証拠がありません。違ったトレードオフを作ることはただ異なる
   問題をもたらすことがありそうで、そしてそれは同じかより難しいでしょう。

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])。より重要なのは、たいていのイ
   ンターネットアプリケーションがホスト名RFCで指定されたりやRFC
   1035で「慎重」と言われた限定ホスト名「LDH」構文を想定します。
   もしそれらの仮定が満たされないなら、それらのアプリケーションの実装の
   多くが実装者とユーザを驚かせる行動を示すかもしれません。これらの可能
   性がある問題を避けるために、IETFの国際化の仕事は「ASCII互換
   コーディング」(ACE)に焦点を合わせました。これらのコーディングは
   DNS自身でLDHの慣習を維持します。更新されないアプリケーション実
   装がコード化された書式を利用し、他方、より新しいものが特別なコードを
   認識し、それらを非ASCII文字に翻訳するよう書かれることができます。
   これらの方法はは、人間インタフェース問題が無視されていても、しかしな
   がら、問題なしではありません。他の問題の間で、DNSラベルが国際化名
   (すなわち、コード化されたユニコード)と考えられるか、あるいは実際の
   LDH名と解釈されるかどうか決定するのは究極的にはヒューリスティック
   に頼ります。そして特定の問合せが保管された対象と一致するかどうかの確
   定が伝統的にDNSサーバによって作られるのに対し、ACEシステムは国
   際的な文字と名前の複雑さによって、一致の仕事の多くが、DNSの一致メ
   カニズムが呼び出される前に、別のクライアント側の正規化あるいは「準備」
   手順に分けられる事を要求します[STRINGPREP]。

4.3 "Stringprep" and Its Complexities
4.3 「文字列前処理」とその複雑さ

   As outlined above, the model for avoiding problems associated with
   putting non-ASCII names in the DNS and elsewhere evolved into the
   principle that strings are to be placed into the DNS only after being
   passed through a string preparation function that eliminates or
   rejects spurious character codes, maps some characters onto others,
   performs some sequence canonicalization, and generally creates forms
   that can be accurately compared.  The impact of this process on
   hostname-restricted ASCII (i.e., "LDH") strings is trivial and
   essentially adds only overhead.  For other scripts, the impact is, of
   necessity, quite significant.
   上に概説されるように、DNSは他の場所で非ASCII名を設定するのに
   関する問題を避けるモデルは、偽文字コードの削除や拒絶をし、ある文字を
   他のに変え、ある文字列正規化を実施し、実際に比較をする形式を生成する、
   文字列前処理関数の通った後にだけ文字列はDNSに設定されるという原理
   に、発展させられました。このホスト名限定ASCII(すなわち「LDH」)
   文字列上のプロセスの影響は些細であって、そして本質的にただオーバーヘッ
   ドだけを加えます。他の文字のために、影響は、必然的に、非常に重要です。

   Although the general notion underlying stringprep is simple, the many
   details are quite subtle and the associated tradeoffs are complex. A
   design team worked on it for months, with considerable effort placed
   into clarifying and fine-tuning the protocol and tables.  Despite
   general agreement that the IETF would avoid getting into the business
   of defining character sets, character codings, and the associated
   conventions, the group several times considered and rejected special
   treatment of code positions to more nearly match the distinctions
   made by Unicode with user perceptions about similarities and
   differences between characters.  But there were intense temptations
   (and pressures) to incorporate language-specific or country-specific
   rules.  Those temptations, even when resisted, were indicative of
   parts of the ongoing controversy or of the basic unsuitability of the
   DNS for fully internationalized names that are visible,
   comprehensible, and predictable for end users.
   文字列前処理の基礎となっている一般的な考えが単純であるけれども、多く
   の細部は非常に微妙です、そして関連づけられたトレードオフは複雑です。
   構想チームがプロトコルと表を明確にし調整することに何カ月間も相当な努
   力で取り組みました。IETFが文字セットを定義する事業や文字コード化
   や関連する慣習に入り込むのを避けるであろうという一般協定にもかかわら
   ず、グループは何回か熟慮を行い、ユニコードコードポジションについて、
   文字の類似と相違に関するユーザの理解により近い区別の特別扱いの拒否を
   しました。けれども言語特有か、あるいは国特有の規則を含む激しい誘惑
   (そして圧力)がありました。それらの誘惑は、拒否される時さえ、エンド
   ユーザの目に見えて理解可能で予測可能な完全に国際化名の進行中の論争あ
   るいはDNSの基本的な非適合性の一部を示していました。

   There have also been controversies about how far one should go in
   these processes of preparation and transformation and, ultimately,
   about the validity of various analogies.  For example, each of the
   following operations has been claimed to be similar to case-mapping
   in ASCII:
   同様にこれらの準備と転換の処理で究極的にどれだけ種々な類似の正当性に
   ついて行くべきであるかについて論争がありました。例えば、次の演算のそ
   れぞれがASCIIの大文字小文字の変換に類似していると主張されました:

   o  stripping of vowels in Arabic or Hebrew
   o  アラブ語あるいはヘブライ語での母音の露出化。

   o  matching of "look-alike" characters such as upper-case Alpha in
      Greek and upper-case A in Roman-based alphabets
   o  ギリシャ語の大文字アルファと、ローマベースのアルファベットの大文字
      Aの「そっくり」文字の一致。

   o  matching of Traditional and Simplified Chinese characters that
      represent the same words,
   o  同じ言葉を表す伝統的漢字と、単純化漢字の一致。

   o  matching of Serbo-Croatian words whether written in Roman-derived
      or Cyrillic characters
   o  ローマ派生かキュリロス文字で書かれるか否かにかかわらずセルボクロア
      チア語の言葉の一致。

   A decision to support any of these operations would have implications
   for other scripts or languages and would increase the overall
   complexity of the process.  For example, unless language-specific
   information is somehow available, performing matching between
   Traditional and Simplified Chinese has impacts on Japanese and Korean
   uses of the same "traditional" characters (e.g., it would not be
   appropriate to map Kanji into Simplified Chinese).
   これらの演算のいずれでも支援する決定が他の文字あるいは言葉のために意
   味を持つでしょう、そして処理の全体的な複雑さを増やすでしょう。例えば、
   言語特定の情報が利用可能でないなら、伝統的中国文字と単純化中国文字の
   間の一致の実行は、同じ「伝統的」文字の日本と韓国での使用に影響を与え
   ます(例えば、単純化中国文字に漢字を翻訳することは適当ではないでしょ
   う)。

   Even were the IDN-WG's other work to have been abandoned completely
   or if it were to fail in the marketplace, the stringprep and nameprep
   work will continue to be extremely useful, both in identifying issues
   and problem code points and in providing a reasonable set of basic
   rules.  Where problems remain, they are arguably not with nameprep,
   but with the DNS-imposed requirement that its results, as with all
   other parts of the matching and comparison process, yield a binary
   "match or no match" answer, rather than, e.g., a value on a
   similarity scale that can be evaluated by the user or by user-driven
   heuristic functions.
   たとえIDN−WGの仕事が完全に捨てられても、もしそれが市場で失敗し
   ても、文字列前処理と名前前処理の仕事は、問題の識別とコードポイントと
   基本的規則の合理的セットの供給の問題で非常に有用であるために続けるで
   しょう。問題が残っている所は多分名前前処理ではなく、DNSに課された
   要求条件で、その結果が一致と比較の処理の全てのほかの部分で、例えば、
   ユーザやユーザ駆動のヒューリスティックに評価される類似性の尺度ではな
   く、「一致か不一致」の2者択一の答えをもたらします。

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は基本的にコードポイントを定義するだけで、文字を使っ
   たり比較する規則は定義しません。これは現在のISP/IEC JTC1/
   SC2の仕事の長年の伝統の一部です:彼らはコードポイント割当てを行い、
   そしてiパン的に文字が使われる方法は彼らの範囲外と扱いました。従って、
   彼らは国際化問題のより広い範囲を効率的に扱いませんでした。それと対照
   して、ユニコード技術委員会(UTC)は、付録と技術報告で(例えば[UTR15]
   参照)、ある正規化と比較のための追加の規則を定義しました。それらの規
   則と取り決めの多くが「文字列前処理」と「名前前処理」の仕事について考
   慮に入れられましたが、DNSにとって十分に正確で永久に当てに出来る方
   法でそれらを作るか定義することは簡単ではありません。

   Perhaps more important, the discussions leading to nameprep also
   identified several areas in which the UTC definitions are inadequate,
   at least without additional information, to make matching precise and
   unambiguous.  In some of these cases, the Unicode Standard permits
   several alternate approaches, none of which are an exact and obvious
   match to DNS needs.  That has left these sensitive choices up to
   IETF, which lacks sufficient in-depth expertise, much less any
   mechanism for deciding to optimize one language at the expense of
   another.
   多分より重要なのは、名前前処理を導く論議が、 少なくとも追加の情報無し
   では、UTC定義が正確かつ明確に一致をするには不適切であるいくつかの
   エリアを識別しました。これらの場合のいくつかで、ユニコード標準はいく
   つかの代わりの方法を認め、そのどれもDNSで必要な正確で明白な一致で
   はありません。それはIETFのきめ細かい選択に残され、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
   evidence of instability and that these instabilities are better
   handled in a system that can be more flexible about handling of
   characters, scripts, and ancillary information than the DNS.
   ユニコード定義は同じく発展します。バージョン3.2は、この文書の仕事が
   始められたすぐ後に、現われました。それはある文字と機能性を加えて、そ
   して少数のマイナーな互換性がないコードポイント変更を含みました。IE
   TFは未来の変更の制約についての合意を保証しました、しかし合意が実際
   はうまくいくかどうかが、残っています。UTCが合意によって禁止される
   べきであった投票を最近の選択したので、現段階での予想は実際は難しいよ
   うにみえます(投票の結果は適切ではなく、ただ密室決定でないようにみせ
   るだけですから)。しかしながら、ある共同体のメンバーがユニコード3.0
   と3.1、3.1と3.2の間に変更を、最近の投票と同じぐらい、不安定性の
   証拠と考えます、これらの不安定性はDNSより文字や言語や補助的な情報
   の取り扱いに柔軟なシステムで扱えます。

   In addition, because the systems implications of internationalization
   are considered out of scope in SC2, ISO/IEC JTC1 has assigned some of
   those issues to its SC22/WG20 (the Internationalization working group
   within the subcommittee that deals with programming languages,
   systems, and environments).  WG20 has historically dealt with
   internationalization issues thoughtfully and in depth, but its status
   has several times been in doubt in recent years.  However, assignment
   of these matters to WG20 increases the risk of eventual ISO
   internationalization standards that specify different behavior than
   the UTC specifications.
   加えて、国際化システムの意味がSC2の範囲外と考えられるから、ISO/
   IEC JTC1がこれらの問題のいくつかをSC22/WG20(プログラ
   ム言語とシステムと環境を扱う小委員会内の国際化ワーキンググループ)に
   割り当てました。WG20が歴史的に深く国際化問題を扱いますが、その状
   態は近年何度も疑問です。しかしながら、これらのWG20への問題の割当
   は、UTC仕様と異なる行動を指定する、最終的なISO国際化標準の危険
   を増やします。

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.
   DND国際化問題が起こしたものの一部、商標問題とその他は、我々が−一
   般的人々が期待していない−「オブジェクトの識別」の問題を止め、−読め
   るだけでなく、言語的に意味があり、文化に依存し、非専門家に意味がある
   −「名前」の問題を開始しました。

   Within the IETF, the IDN-WG, and sometimes other groups, avoided
   addressing the implications of that transition by taking "outside our
   scope -- someone else's problem" approaches or by suggesting that
   people will just become accustomed to whatever conventions are
   adopted.  The realities of user and vendor behavior suggest that
   these approaches will not serve the Internet community well in the
   long term:
   IETFやIDN−WGやその他のグループで、この移行の問題は「我々の
   問題ではない−−他人の問題」と言ったり、人々は採用されるどんな取り決
   めにもなれると提案する事で、扱うのを避けられました。ユーザとベンダ行
   動の現実はこれらの方法が長期間上手にインターネット共同体に仕えないこ
   とを示唆します:

   o  If we want to make it a problem in a different part of the user
      interface structure, we need to figure out where it goes in order
      to have proof of concept of our solution.  Unlike vendors whose
      sole [business] model is the selling or registering of names, the
      IETF must produce solutions that actually work, in the
      applications context as seen by the end user.
   o  もし我々がユーザ・インタフェース構造体の異なった部分でそれを問題に
      することを望むなら、我々は解決の概念の証明を持って行く所を理解する
      必要があります。その単独の[ビジネス]モデルが名前を売るか登録する
      ベンダーと異なり、IETFはエンドユーザに見られるアプリケーション
      状況で実際に働く解決を作り出さなくてはなりません。

   o  The principle that "they will get used to our conventions and
      adapt" is fine if we are writing rules for programming languages
      or an API.  But the conventions under discussion are not part of a
      semi-mathematical system, they are deeply ingrained in culture.
      No matter how often an English-speaking American is told that the
      Internet requires that the correct spelling of "colour" be used,
      he or she isn't going to be convinced. Getting a French-speaker in
      Lyon to use exactly the same lexical conventions as a French-
      speaker in Quebec in order to accommodate the decisions of the
      IETF or of a registrar or registry is just not likely.  "Montreal"
      is either a misspelling or an anglicization of a similar word with
      an acute accent mark over the "e" (i.e., using the Unicode
      character U+00E9 or one of its equivalents). But global agreement
      on a rule that will determine whether the two forms should match
      -- and that won't astonish end users and speakers of one language
      or the other -- is as unlikely as agreement on whether
      "misspelling" or "anglicization" is the greater travesty.
   o  「彼らが我々の取り決めに慣れ、順応するであろう」という原則は、もし
      我々がプログラミング言語やAPIの規則を書いているなら、素晴らしい
      です。けれども議論中の取り決めは半数学的なシステムの一部ではなく、
      深く文化に根ざしています。どれぐらい英語を話しているアメリカ人がイ
      ンターネットは「colour」の正しいつづりが使われることを要求している
      と言うにもかかわらず、彼あるいは彼女が確信しようとしていません。I
      ETFの決定あるいは登録係か登記所の決定を受け入れるため、ケベック
      のフランス語の話し手がリヨンのフランス語の話してと正確に同じ語彙を
      使うように取り決めるのは有望ではありません。「Montreal」は誤ったつ
      づりか「e」の上に鋭いアクセント記号がある同様の言葉の英国風です
      (すなわち、ユニコード文字U+00E9あるいはその同等物を使います)。け
      れども2つの形式が一致するかどうか決定する規則の世界的な合意が−そ
      してそれが末端ユーザとある言語の話し手あるいは他の言語の話してを驚
      かさない−というのが「誤ったつづり」あるいは「英国風」の合意という
      のはありそうになく、こっけいです。

   More generally, it is not clear that the outcome of any conceivable
   nameprep-like process is going to be good enough for practical,
   user-level, use.  In the use of human languages by humans, there are
   many cases in which things that do not match are nonetheless
   interpreted as matching.  The Norwegian/Danish character that appears
   in U+00F8 (visually, a lower case 'o' overstruck with a forward
   slash) and the "o-umlaut" German character that appears in U+00F6
   (visually, a lower case 'o' with diaeresis (or umlaut)) are clearly
   different and no matching program should yield an "equal" comparison.
   But they are more similar to each other than either of them is to,
   e.g., "e".  Humans are able to mentally make the correction in
   context, and do so easily, and they can be surprised if computers
   cannot do so.  Worse, there is a Swedish character whose appearance
   is identical to the German o-umlaut, and which shares code point
   U+00F6, but that, if the languages are known and the sounds of the
   letters or meanings of words including the character are considered,
   actually should match the Norwegian/Danish use of U+00F8.
   より一般に、想像可能な名前前処理のような手順の結果が、十分に実際的な
   ユーザレベルの使用iに良い、という事は明確ではありません。人間が人間
   の言葉を使用するときでも、一致すると解釈される一致しないものが多くの
   場合にあります。ノルウェー/デンマーク文字のU+00F8(視覚的には小文字
   「o」とフォワードスラッシュの重ね打ち)と、ドイツ文字のU+00F6(視覚
   的には分音記号、(あるいはウムラウト記号)付きの小文字「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つが上記に類似している問題がほとん
   どすべての言語と文字で存在するということです。それぞれが特有性を持ち、
   そしてそれぞれの特有性が通常の使用法と文化的な問題に結び付き、そして
   関係者に非常に深く知られていて、そしてしばしば文化的価値感に深く結び
   ついています。合衆国の学童が完全に正当な英国のつづりを使うとつづりテ
   ストの生成機が悪くなりえて、フランス人やドイツ人が区別的発音符を忘れ
   ると成績が悪くなりえて、これが言語に関連する問題です。同様に、もしエ
   ジプトあるいはイスラエルの子供たちが母音あるいは強勢符号の有無にかか
   わらず言葉を書くことが受容できるということを教えられるなら、もしそれ
   らのマークが含まれるていても正しいに違いなく、あるいは韓国のJamo
   システムのユーザーが文字毎の処理や極端に単純な処理で、文脈上の情報な
   しで、ユーザーの必要を満たそうとしていない者に対し、潜在的に不快か、
   あるいは驚きます。

   Users are demanding solutions that deal with language and culture.
   Systems of identifier symbol-strings that serve specialists or
   computers are, at best, a solution to a rather different (and, at the
   time this document was written, somewhat ill-defined), problem.  The
   recent efforts have made it ever more clear that, if we ignore the
   distinction between the user requirements and narrowly-defined
   identifiers, we are solving an insufficient problem.  And,
   conversely, the approaches that have been proposed to approximate
   solutions to the user requirement may be far more complex than simple
   identifiers require.
   ユーザが言語と文化を論ずる解決を要求しています。専門家あるいはコン
   ピュータをサポートする記号文字列の識別システムが、良くても、その解決
   と言うより異なった(そして、この文書が書かれた時において、幾分、正し
   く定義されていない)問題です。最近の取り組みが、もし我々がユーザの必
   要条件と狭い定義の識別子の区別を無視するなら、我々は不十分な問題を解
   いている、というのを明確にしました。そして、逆にユーザ必要条件に対す
   る解決に近付くために提言された方法は、単純な識別要求するよりはるかに
   より複雑であるかもしれません。

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.
   これまでの数世紀に、多言語の状態を扱うことに対しするローカルな協定が、
   世界の種々の部分で確立されました。これらのいくつかを調べることは助け
   になるかもしれません。例えば、もし母国語と異なる言語の国を訪問するな
   ら、名刺がしばしば両面刷りで、各面がそれぞれの言語で印刷されます。慣
   習は完全には一貫せず、そしてこのテクニックは受取人が寛大であることを
   想定します。ある場合は名前や場所の翻訳が試みられ、他の場合は音訳され
   ます。正確な翻訳あるいは音訳がしばしば可能ではないことは広く理解され
   ているので、人々が一般的に誤りに対しほほ笑んで、努力を正当に評価し、
   そして前進します。

   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コードとローマ字キーボードの仮定

   Part of the argument for ACE-based solutions is that they provide an
   escape for multilingual environments when applications have not been
   upgraded.  When an older application encounters an ACE-based name,
   the assumption is that the (admittedly ugly) ASCII-coded string will
   be displayed and can be typed in.  This argument is reasonable from
   the standpoint of mixtures of Roman-based alphabets, but may not be
   relevant if user-level systems and devices are involved that do not
   support the entry of Roman-based characters or which cannot
   conveniently render such characters.  Such systems are few in the
   world today, but the number can reasonably be expected to rise as the
   Internet is increasingly used by populations whose primary concern is
   with local issues, local information, and local languages.  It is,
   for example, fairly easy to imagine populations who use Arabic or
   Thai scripts and who do not have routine access to scripts or input
   devices based on Roman-derived alphabets.
   ACEベースの解決の議論の一部が、アプリケーションが更新されなかった
   時、多言語環境に逃げ道を提供することです。より古いアプリケーションが
   ACEベースの名前に遭遇する時、(明らかに醜い)ASCIIコード文字
   列が示され、タイプできるという仮定しています。この論拠はローマ字ベー
   スのアルファベットの見地から合理的ですが、もしローマ字ベースの文字を
   サポートしない、表示に適していないユーザーレベルシステムと装置を伴う
   なら、適切ではないかもしれません。このようなシステムは今日世界中でほ
   とんどありませんが、ローカル問題とローカル情報に関心がありとローカル
   言語を使う母集団がインターネットを使うから、インターネットでそうでな
   いシステムが増加することが予想されます。例えば、アラブ語あるいはタイ
   の文字を使い、そしてローマ文字のアルファベットに基づく文字あるいは入
   力装置に定常アクセスを持たない母集団を想像することは、かなり容易です。

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ベース内の解決はいずれも
   実行可能ではないように思われます。それらは実行可能であるように思われ
   ないあまりに多くの仮定に基づきます−−人々は深く確立した言語習慣を、
   コンピュータが簡単なものに適合する;「現時点で凍結させ、このエリアの
   変更は必要ない」ユニコードと名前前処理の決定を我々が作れる;ACEは
   キーやローマ字表示の能力のない環境(あるいはユーザの経験がこの様な字
   の形を他と区別できない環境)でもアプリケーション問題を穏やかにするで
   しょう;ユニコードコンソーシアムが決してDNSの非互換性の危険を発生
   する方法で誤り訂正を決めないであろう;我々がEDNS[RFC2671]を展開で
   きるか、あるいは長い名前が本当に重要ではない;日本や中国のコンピュー
   タ・ユーザ(そして他ユーザ)がローカルもしくはIS2022ベース文字
   コードによる解決をあきらめるか(そのためにユニコードへの百万近くの新
   しいコードポイントの追加が確実に必要で、しかし恐らく十分条件ではない)、
   漏れがなく完璧に正確な境界での変換メカニズムを作るだろう;アウトバン
   ド、又は、環境の情報が、常に、「文字の字形を描く」問題の解決に十分あ
   る、など。それぞれの場合に、およそ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)
   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つのディレクトリ(たとえ機能的に、そして多分管理的に分散していても)
   最も良くサポートされるか、地域的に適応した探索と(そして、そして最も
   重要な、一致)関数を持つ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.
   地域的に適応した捜索とマッピングはどの文字列が他と一致するかの解釈、
   異なる土地で異なる規則、つまり区別できるあるいは出来ない文字の一致、
   を適用する時の特に重要な取り決めは、で国毎の相違を認めるでしょう。け
   れども、もちろん、これはURLを適切に、あるいはクライアント機械の設
   定やユーザのネットワーク接続性によらない、評価を意味します。これは一
   般的な場合にユーザはURL(あるいは他のホスト参照)を共有できず、あ
   るユーザが参照をあるホストや場所から他に運べないので、一般的に望まし
   い状態でありません。

   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,
   getting back information, and then doing additional lookups
   potentially in different subtrees.  That multistage lookup will often
   be the case with, e.g., NAPTR records [RFC 2915] unless additional
   restrictions are imposed.  But additional steps, systems, and
   databases almost certainly involve some additional risks of
   compromise.
   この文書によって暗示された提案は面白いセキュリティ問題を提案します
   (すなわち、重要でないものは常に容易)。ネットワーク資源の場所を突き
   止めることに対して使うディレクトリシステムが多分DNS自身と同じぐら
   い慎重に無許可の変更に対して保護されている必要があるでしょう。特にも
   しこのようなシステムが中央の権威あるいは名前の一様性なしで設計された
   なら2以上の階層を巻き込んだ、取り決めの問題の新しい機会かもしれませ
   ん。名前を検索し情報を得て潜在的に異なる木に属する追加検索を行うDN
   Sに比べて、それらの危険がどれぐらい大きいかは不確実です。追加の制限
   が課されないなら、多段式検索はしばしばあります、例えばNAPTRレコー
   ド[RFC 2915]です。けれども追加手順は、システムとデータベースでほとん
   ど確かにある汚染の追加の危険を伴います。

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.

   [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.
                  米国規格協会(以前はアメリカ合衆国標準協会)、X3.4、
                  1968、「情報交換のUSAコード」。ANSIX3.4−
                  1968がわずかな修正でより新しい版で置き換えられまし
                  た、しかし1968の版はインターネットで最終的なままで
                  います。ASCIIが最初に標準として公式化された後、I
                  SOが国際標準646を採用し、これはASCIIをベース
                  として用います。IS646が実際に2つのコード表を含ん
                  でいました:本質的にその時のASCIIとまったく同じで
                  あった「国際参照版」(しばしばISO646−IRVと参
                  照される)と、国内使用のために多くの文字位置を指名する
                  「基本版」(ISO646−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.

                  Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
                  ADDR.ARPA delegation", RFC 2317, March 1998.

   [COM-SIZE]     Size information supplied by Verisign Global Registry
                  Services (the zone administrator, or "registry
                  operator", for COM, see [REGISTRAR], below) to ICANN,
                  third quarter 2002.

   [DNS-Search]   Klensin, J., "A Search-based access model for the
                  DNS", Work in Progress.

   [FINGER]       Zimmerman, D., "The Finger User Information Protocol",
                  RFC 1288, December 1991.

                  Harrenstien, K., "NAME/FINGER Protocol", RFC 742,
                  December 1977.

   [IAB-OPES]     Floyd, S. and L. Daigle, "IAB Architectural and Policy
                  Considerations for Open Pluggable Edge Services", RFC
                  3238, January 2002.

   [IQUERY]       Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
                  2002.

   [IS646]        ISO/IEC 646:1991 Information technology -- ISO 7-bit
                  coded character set for information interchange

   [IS10646]      ISO/IEC 10646-1:2000 Information technology --
                  Universal Multiple-Octet Coded Character Set (UCS) --
                  Part 1: Architecture and Basic Multilingual Plane and
                  ISO/IEC 10646-2:2001 Information technology --
                  Universal Multiple-Octet Coded Character Set (UCS) --
                  Part 2: Supplementary Planes

   [MINC]         The Multilingual Internet Names Consortium,
                  http://www.minc.org/ has been an early advocate for
                  the importance of expansion of DNS names to
                  accommodate non-ASCII characters.  Some of their
                  specific proposals, while helping people to understand
                  the problems better, were not compatible with the
                  design of the DNS.
                  多言語のインターネット名前コンソーシアム、
                  http://www.minc.org/は非ASCII文字を受け入れるため
                  のDNS名の拡大の重要性の初期の提唱者でした。彼らの特
                  定の提案のいくつかが人々がもっと良く問題を理解するのを
                  手伝いましたが、DNSのデザインと互換性がありませんで
                  した。

   [NAPTR]        Mealling, M. and R. Daniel, "The Naming Authority
                  Pointer (NAPTR) DNS Resource Record", RFC 2915,
                  September 2000.

                  Mealling, M., "Dynamic Delegation Discovery System
                  (DDDS) Part One: The Comprehensive DDDS", RFC 3401,
                  October 2002.

                  Mealling, M., "Dynamic Delegation Discovery System
                  (DDDS) Part Two: The Algorithm", RFC 3402, October
                  2002.

                  Mealling, M., "Dynamic Delegation Discovery System
                  (DDDS) Part Three: The Domain Name System (DNS)
                  Database", RFC 3403, October 2002.

   [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.
                  インターネット名前番号割当団体(IACNN)を作る過程
                  の初期に、「緑の紙」が合衆国政府によって発表されました。
                  その紙は新しい用語とある伝統的なDNS運用で必要ない概
                  念を紹介しました。用語「登記所」は(典型的に緑の紙が頂
                  上レベル以外に関係しなかったので、頂上レベルの)ドメイ
                  ンの実際の運用者とデータベース保有者に適用され、他方、
                  「登録人」に名前を売り込んで利用可能にする組織は「登記
                  係」として知られていました。古典的なDNSモデルで、
                  「地域管理者」の機能は、そのモデルが名前の市場を予期し
                  なかったけれども、登記所と登記係の役割の両方をカバーし
                  ました。

   [RFC625]       Kudlick, M. and E. Feinler, "On-line hostnames
                  service", RFC 625, March 1974.

   [RFC734]       Crispin, M., "SUPDUP Protocol", RFC 734, October 1977.

   [RFC811]       Harrenstien, K., White, V. and E. Feinler, "Hostnames
                  Server", RFC 811, March 1982.

   [RFC819]       Su, Z. and J. Postel, "Domain naming convention for
                  Internet user applications", RFC 819, August 1982.

   [RFC830]       Su, Z., "Distributed system for Internet name
                  service", RFC 830, October 1982.

   [RFC882]       Mockapetris, P., "Domain names: Concepts and
                  facilities", RFC 882, November 1983.

   [RFC883]       Mockapetris, P., "Domain names: Implementation
                  specification", RFC 883, November 1983.

   [RFC952]       Harrenstien, K, Stahl, M. and E. Feinler, "DoD
                  Internet host table specification", RFC 952, October
                  1985.

   [RFC953]       Harrenstien, K., Stahl, M. and E. Feinler, "HOSTNAME
                  SERVER", RFC 953, October 1985.

   [RFC1034]      Mockapetris, P., "Domain names, Concepts and
                  facilities", STD 13, RFC 1034, November 1987.

   [RFC1035]      Mockapetris, P., "Domain names - implementation and
                  specification", STD 13, RFC 1035, November 1987.

   [RFC1591]      Postel, J., "Domain Name System Structure and
                  Delegation", RFC 1591, March 1994.

   [RFC2181]      Elz, R. and  R. Bush, "Clarifications to the DNS
                  Specification", RFC 2181, July 1997.

   [RFC2295]      Holtman, K. and A. Mutz, "Transparent Content
                  Negotiation in HTTP", RFC 2295, March 1998

   [RFC2396]      Berners-Lee, T., Fielding, R. and L. Masinter,
                  "Uniform Resource Identifiers (URI): Generic Syntax",
                  RFC 2396, August 1998.

   [RFC2608]      Guttman, E., Perkins, C., Veizades, J. and M. Day,
                  "Service Location Protocol, Version 2", RFC 2608, June
                  1999.

   [RFC2671]      Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
                  2671, August 1999.

   [RFC2825]      IAB, Daigle, L., Ed., "A Tangled Web: Issues of I18N,
                  Domain Names, and the Other Internet protocols", RFC
                  2825, May 2000.

   [RFC2826]      IAB, "IAB Technical Comment on the Unique DNS Root",
                  RFC 2826, May 2000.

   [RFC2972]      Popp, N., Mealling, M., Masinter, L. and K. Sollins,
                  "Context and Goals for Common Name Resolution", RFC
                  2972, October 2000.

   [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.

   [RFC3439]      Bush, R. and D. Meyer, "Some Internet Architectural
                  Guidelines and Philosophy", RFC 3439, December 2002.

   [Seng]         Seng, J., et al., Eds., "Internationalized Domain
                  Names:  Registration and Administration Guideline for
                  Chinese, Japanese, and Korean", Work in Progress.

   [STRINGPREP]   Hoffman, P. and M. Blanchet, "Preparation of
                  Internationalized Strings (stringprep)", RFC 3454,
                  December 2002.

                  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に置くことに対して使われた特定のプ
                  ロフィールは「名前前処理」と呼ばれます、Hoffman, P.と
                  M Blanchetによって記述された「名前前処理:国際化ドメイ
                  ン名のための文字列前処理プロフィール」は進行中の仕事で
                  す。

   [TELNET]       Postel, J. and J. Reynolds, "Telnet Protocol
                  Specification", STD 8, RFC 854, May 1983.

                  Postel, J. and J. Reynolds, "Telnet Option
                  Specifications", STD 8, RFC 855, May 1983.

   [UNICODE]      The Unicode Consortium, The Unicode Standard, Version
                  3.0, Addison-Wesley: Reading, MA, 2000.  Update to
                  version 3.1, 2001.  Update to version 3.2, 2002.

   [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).

   [WHOIS]        Harrenstien, K, Stahl, M. and E. Feinler,
                  "NICNAME/WHOIS", RFC 954, October 1985.

   [WHOIS-UPDATE] Gargano, J. and K. Weiss, "Whois and Network
                  Information Lookup Service, Whois++", RFC 1834, August
                  1995.

                  Weider, C., Fullton, J. and S. Spero, "Architecture of
                  the Whois++ Index Service", RFC 1913, February 1996.

                  Williamson, S., Kosters, M., Blacka, D., Singh, J. and
                  K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5",
                  RFC 2167, June 1997;

                  Daigle, L. and P. Faltstrom, "The
                  application/whoispp-query Content-Type", RFC 2957,
                  October 2000.

                  Daigle, L. and P. Falstrom, "The application/whoispp-
                  response Content-type", RFC 2958, October 2000.

   [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.

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.
   多くの人々がこの文書の版やこの文書の考えに貢献しました。著者は特に特
   定の提案や以前の版の仮定と提示の挑戦とそれらを改善する方法の示唆に対
   してHarald AlvestrandとRob AusteinとBob BradenとVinton CerfとMatt
   CrawfordとLeslie DaigleとPatrik FaltstromとEric A. HallとTed Hardie
   とPaul HoffmanとErik NordmarkとZita Wenzelに感謝することを好むでしょ
   う。

9. Author's Address
9. 著者のアドレス

   John C. Klensin
   1770 Massachusetts Ave, #322
   Cambridge, MA 02140

   EMail: klensin+srch@jck.com

   A mailing list has been initiated for discussion of the topics
   discussed in this document, and closely-related issues, at
   ietf-irnss@lists.elistx.com.  See http://lists.elistx.com/archives/
   for subscription and archival information.
   この文書で論じられたトピックと強く関係する問題の議論のために、メーリ
   ングリストietf-irnss@lists.elistx.comが始められました。定期受信契約
   と記録文書の情報のために http://lists.elistx.com/archives/ を見てく
   ださい。

10. Full Copyright Statement
10. 著作権表示全文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.
   著作権(C)インターネット学会(2003)。すべての権利は保留される。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.
   上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
   この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
   を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
   版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
   ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
   や他のインターネット組織は著作権表示や参照を削除されるような変更がで
   きません、インターネット標準を開発する場合はインターネット標準化プロ
   セスで定義された著作権の手順に従われます。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.
   上に与えられた限定された許可は永久で、インターネット学会やその後継者
   や譲渡者によって無効にされません。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   この文書とここに含む情報は無保証で供給され、そしてインターネット学会
   とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
   報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、すべての保証を拒否します。

Acknowledgement
謝辞

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
   RFCエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So