RFC881 日本語訳
0881 Domain names plan and schedule. J. Postel. November 1983. (Format: TXT=23490 bytes) (Updated by RFC0897) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Postel
Request for Comments: 881 ISI
November 1983
コメントを求めるワーキンググループJ.ポステルの要求をネットワークでつないでください: 881 ISI1983年11月
The Domain Names Plan and Schedule
ドメイン名プランとスケジュール
This RFC outlines a plan and schedule for the implementation of domain style names throughout the DDN/ARPA Internet community. The introduction of domain style names will impact all hosts on the DDN/ARPA Internet.
このRFCはDDN/ARPAインターネットコミュニティ中にドメインスタイル名の実装のためのプランとスケジュールについて概説します。 ドメインスタイル名の導入はDDN/ARPAインターネットですべてのホストに影響を与えるでしょう。
The Plan
プラン
Introduction
序論
Domain style names are being introduced in the Internet to allow a
controlled delegation of the authority and responsibility for
adding hosts to the system. This also allows a subdivision of the
task of maintaining information about hosts.
ドメインスタイル名は、ホストをシステムに追加することへの権限と責任の制御委譲を許容するためにインターネットで紹介されています。 また、これはホストの情報を保守するタスクの下位区分を許容します。
The subdivision will be based on administrative authority or
organization boundaries (not necessarily network boundaries).
Certain requirements will be placed on organizations wishing to be
"top level" domains. Initially, all the hosts in the Internet
will be in the domain "ARPA". As soon as is practical a second
domain, "DDN", will be introduced. Other domains may be added
after that, provided the requirements listed below are met.
下位区分は職務権限か組織境界(必ず、境界をネットワークでつなぐというわけではない)に基づくでしょう。 ある要件は「先端平らな」ドメインになりたがっている組織に置かれるでしょう。 初めは、インターネットのすべてのホストがドメイン「アルパ」にいるでしょう。 同じくらいすぐ、実用的であるように、2番目のドメイン"DDN"を導入するでしょう。 以下にリストアップされた必要条件が満たされるなら、他のドメインはその後に加えられるかもしれません。
Domain names will be supported in the long run by a system of
special servers called "domain servers" which will be used to
translate names to addresses. While this system of domain servers
is being created and programs are being converted to use them, the
existing host tables will evolve to include domain style names.
ドメイン名は結局、名前をアドレスに翻訳するのに使用される「ドメインサーバ」と呼ばれる特別なサーバのシステムによってサポートされるでしょう。 ドメインサーバのこのシステムが作成されていて、プログラムがそれらを使用するために変換されている間、既存のホストテーブルは、ドメインスタイル名を含むように発展するでしょう。
The domain server design also provides for mapping mailbox
addresses to the host name of the mail server for that mailbox.
This feature allows mailboxes to be related to an organization
rather than to a specific host.
また、ドメインサーバデザインはそのメールボックスのためにメールサーバのホスト名にメールボックスアドレスを写像するのに提供されます。 この特徴は、メールボックスが特定のホストにというよりむしろ組織に関係づけられるのを許容します。
This plan will be implemented in the ARPA community. After the
domain system is demonstrated in the ARPA community, the DDN
Program Management Office (DDN-PMO) will determine the schedule
for implementation of the domain system in the DDN community.
This approach will cause some extra steps in the ARPA community
implementation, and may limit communication between the ARPA and
DDN communities in some ways. The details and implications of
this two phase approach are discussed more fully below.
このプランはARPA共同体で実装されるでしょう。 ドメインシステムがARPA共同体に示された後に、DDN Program管理事務所(DDN-PMO)はDDN共同体でドメインシステムの実装のためのスケジュールを決定するでしょう。 このアプローチは、ARPA共同体実装で付加的な数ステップを引き起こして、ARPAとDDN共同体の間である点ではコミュニケーションを制限するかもしれません。 以下でこの二相アプローチの詳細と含意について、より完全に議論します。
Postel [Page 1]
ポステル[1ページ]
RFC 881 November 1983 The Domain Names Plan and Schedule
ドメイン名が計画して、計画をするRFC881 1983年11月
A Catch 22
キャッチ22
There is a problem in introducing domain style names: a great deal
of software has to be changed. Some groups would like to start
using domain style names right away, and other groups don't want
to see them or use them for a very long time. Communication
patterns are very complex and as soon as domain style names are
allowed and used by a few groups they will start showing up almost
everywhere. This argues that everyone should be prepared for them
before they are used at all. However, we know that with people
being people and with so many of people involved, the probability
of everyone being ready in any reasonable time period is nearly
zero. The way out of this situation is to set up a reasonable
schedule for experimenting with domain style names and authorizing
their use. People that get ready on schedule should have no
problems with these names.
ドメインスタイル名を紹介するのにおいて問題があります: 多くのソフトウェアを変えなければなりません。 いくつかのグループが、すぐドメインスタイル名を使用し始めたがっていて、他のグループは、非常に長い時間、彼らを見たくはありませんし、それらを使用したがっていません。 コミュニケーションパターンは非常に複雑です、そして、ドメインスタイル名がいくつかのグループによって許容されていて、使用されるとすぐに、それらはほとんどいたる所から現れ始めるでしょう。 これは、それらが全く使用される前に皆がそれらのために用意ができているべきであると主張します。 しかしながら、私たちは、どんな妥当な期間にも準備ができる皆の確率が人々である人々であってかかわる人々がとても多い、およそゼロであることを知っています。 この状況からの道はドメインスタイル名を実験して、彼らの使用を認可するための妥当なスケジュールをセットアップすることです。 スケジュール通りに用意する人々はこれらの名前に関する問題を全く持つべきではありません。
Evolution of the Table
テーブルの発展
Nearly all the hosts in the Internet now use some form of host
table based on the master file "HOSTS.TXT" maintained by the
Network Information Center (NIC).
ほとんどインターネットのすべてのホストが現在、ネットワークインフォメーション・センター(NIC)で"HOSTS.TXT"が維持した基本ファイルに基づく何らかの形式のホストテーブルを使用します。
One way to introduce domain style names is to add to the entries
in this table names in the domain style. In particular, make the
first name in each entry the official host name in the ARPA
domain.
ドメインスタイル名を紹介する1つの方法はドメインスタイルで名前を見送るようにこれのエントリーに言い足すことです。 ARPAドメインで各エントリーにおける名を公的ホスト役名に特に、してください。
For example, the current entry for USC-ISIF is:
例えば、USC-ISIFのための現在のエントリーは以下の通りです。
HOST : 10.2.0.52 : USC-ISIF,ISIF : DEC-1090T : TOPS20 :
TCP/TELNET,TCP/SMTP,TCP/FTP,TCP/FINGER,UDP/TFTP :
以下を接待してください。 10.2.0.52 : USC-ISIF、ISIF: 12月-1090T: TOPS20: TCP/telnet、TCP/SMTP、TCP/FTP、TCP/指、UDP/TFTP:
This could become:
これはなるかもしれません:
HOST : 10.2.0.52 : USC-ISIF.ARPA,USC-ISIF,ISIF : DEC-1090T :
TOPS20 : TCP/TELNET,TCP/SMTP,TCP/FTP,TCP/FINGER,UDP/TFTP :
以下を接待してください。 10.2.0.52 : USC-ISIF.ARPA、USC-ISIF、ISIF: 12月-1090T: TOPS20: TCP/telnet、TCP/SMTP、TCP/FTP、TCP/指、UDP/TFTP:
For some hosts and programs this could be done today with no
disruptions, but for others substantial problems could occur. For
example, with over five hundred entries in the table the addition
of 500 names could exceed the space allocated to store the table
in some programs. (One could argue that these programs are going
to blow up soon anyway as new host entries are added to the
table.) Another problem is that period (or dot, ".") is not now a
legal character in host names and some programs may not be able to
parse these new names.
今日分裂、他のもののためにこれをできたいくつかのホストとプログラムのために、かなりの問題が起こることができました。 例えば、500以上のエントリーがテーブルにある状態で、500の名前の追加はいくつかのプログラムにテーブルを保存するために割り当てられたスペースを超えるかもしれません。. (1つは、新しいホストエントリーがテーブルに加えられるときすぐとにかく爆発するようにこれらのプログラムが動いていると主張するかもしれません。) 「別の問題がその期間である、(ドット、」、」、)、ホスト名といくつかのプログラムにおける法的なキャラクタが分析できないかもしれない現在はこれらの新しい名前ではありませんか?
Postel [Page 2]
ポステル[2ページ]
RFC 881 November 1983 The Domain Names Plan and Schedule
ドメイン名が計画して、計画をするRFC881 1983年11月
The plan is to make such a domain style name table available in
parallel with the regular table for a few months, then to replace
the regular table with this domain style table. The dates for
these changes is given in the schedule below.
プランは、そのようなドメインスタイル名前テーブルを数カ月の通常のテーブルと平行して利用可能にして、そして、通常のテーブルをこのドメインスタイルテーブルに取り替えることです。 スケジュールでこれらの変化の日付を以下に与えます。
So far, no new domains have been introduced. Only a table with
all the entries having official names in the ARPA domain has been
provided. This should allow programs to be constructed to deal
with domain style names in a general way without any special hacks
to add or delete the string ".ARPA" to or from host names.
今までのところ、どんな新しいドメインも導入していません。 ARPAドメインに正式名称を持っているすべてのエントリーがあるテーブルだけを提供しました。 これは、プログラムがホスト名かホスト名からストリング".ARPA"を加えるか、または削除するためにザッと少しも特別なハッキングのないドメインスタイル名に対処するために組み立てられるのを許容するべきです。
The introduction of new domains is tied to the provision of domain
servers by those domains. As new domains meet the requirements
and are authorized they will also be added to the host table. No
new domains will be added before master table is converted to the
domain style entries.
新しいドメインの導入はそれらのドメインによってドメインサーバに関する条項に結ばれます。 新しいドメインが条件を満たして、認可されているので、また、それらはホストテーブルに加えられるでしょう。 マスターテーブルがドメインスタイルエントリーに変換される前にどんな新しいドメインも加えられないでしょう。
In the long run the Internet will become too complex and change
too fast to keep a master table of all the hosts. At some point
the master table will be reduced to simply the entries for the
domain servers for the top level domains. By this time all normal
translation of host names into addresses should take place by
consulting domain servers.
結局、インターネットは、複雑になり過ぎて、すべてのホストのマスターテーブルを保つことができないくらい速く変化するでしょう。 何らかのポイントでは、マスターテーブルはトップ・レベル・ドメインのためにドメインサーバのための単にエントリーに減少するでしょう。 今回までには、アドレスへのホスト名のすべての通常の翻訳がコンサルティングドメインサーバで行われるべきです。
Conversion to Servers
サーバへの変換
As soon as domain servers become available programs should be
converted to use them to translate names into addresses. The
details of these procedures are given in RFCs 882 and 883.
ドメインサーバが利用可能になるとすぐに、プログラムは、名前をアドレスに翻訳するのにそれらを使用するために変換されるべきです。 これらの手順の詳細はRFCs882と883で明らかにされます。
The general idea is that a host no longer keeps a complete host
table but rather makes a request on the domain server each time a
name must be translated to an address. The code module in the
host that implements the protocol to do this is called a
"resolver". The resolver may keep a cache of recently translated
names and addresses for improved performance.
概念はホストがもう完全なホストテーブルを保ちませんが、名前をアドレスに翻訳しなければならないたびにドメインサーバでむしろ要求をするということです。 これをするためにプロトコルを実装するホストのコードモジュールは「レゾルバ」と呼ばれます。 レゾルバは向上した性能のための最近翻訳された名前とアドレスのキャッシュを保つかもしれません。
Many hosts have a library function or system call that is used to
access the host table to translate names to addresses. It ought
to be possible to replace this function or call with the resolver
module such that most programs would not know which method was
used to accomplish the name to address translation.
多くのホストには、名前をアドレスに翻訳するためにホストテーブルにアクセスするのに使用されるライブラリ関数かシステムコールがあります。 この機能を取り替えるか、またはレゾルバモジュールで呼ぶのが、ほとんどのプログラムが、どのメソッドが翻訳を扱うために名前を達成するのに使用されたかを知らないくらい可能であるべきです。
Postel [Page 3]
ポステル[3ページ]
RFC 881 November 1983 The Domain Names Plan and Schedule
ドメイン名が計画して、計画をするRFC881 1983年11月
Requirements on a Domain
ドメインに関する要件
There are several requirements that must be met to establish a
domain. In general it must be responsibly managed. There must be
a responsible person to serve as a coordinator for domain related
questions, there must be a robust name service, it must be of at
least a minimum size, and the domain must be registered with the
central domain administrator.
ドメインを証明するために満たさなければならないいくつかの必要条件があります。 一般に、責任をもってそれを管理しなければなりません。 役立つ責任者が、それが少なくとも最小規模のものであるに違いなく、ドメイン関連する質問のためのコーディネータ、体力を要している名前サービスがあるに違いなくて、主要なドメイン管理者にドメインを登録しなければならないので、いるに違いありません。
Responsible Person:
責任者:
An individual must be identified who has authority for the
administration of the names within the domain, and who takes
responsibility for the behavior of the hosts in the domain in
their interactions with hosts outside the domain.
名前の管理のためにドメインの中で権限があって、ドメインの外のホストとの彼らの相互作用でそのドメインのホストの振舞いに責任を取る個人を、特定しなければなりません。
The operation of a name server should not be taken on lightly.
There are some difficult problems in providing an adequate
service, primarily the problems in keeping the data base up to
date, and keeping the service operating.
軽くネームサーバの操作を帯びるべきではありません。 適切なサービスを提供するのにおいていくつかの難問があります、主としてデータベースが時代について行かせて、サービスを保つことにおける問題が作動して。
If some host in a domain somehow misbehaves in interactions
with hosts outside the domain (e.g., consistently violates
protocols), the responsible person for the domain must be able
to take action to eliminate the problem.
ドメインのホストがドメイン(例えば、一貫して、プロトコルに違反する)の外のホストとの相互作用でどうにかふらちな事をするなら、ドメインへの責任者は、問題を解決するために行動を取ることができなければなりません。
Domain Servers:
ドメインサーバ:
A robust and reliable domain service must be provided. One way
of meeting this requirement is to provide at least two
independent domain servers for the domain. The data base can,
of course, be the same. The database can be prepared and
copied to each domain server. But, the servers should be in
separate machines on independent power supplies, et cetera;
basically as physically independent as can be and yet in the
same domain. They should have no common point of failure.
強健で信頼できるドメインサービスを提供しなければなりません。 この必要条件を満たす1つの方法は少なくとも2つの独立しているドメインサーバをドメインに提供することです。 データベースはもちろん同じである場合があります。 それぞれのドメインサーバにデータベースを準備して、コピーできます。しかし、サーバが独立している電源などの別々のマシンにあるべきです。 あることができますが、同じドメインで肉体的に基本的同じくらい独立しています。 彼らには、失敗のどんな一般的なポイントもあるべきではありません。
One of the difficult problems in operating a domain server is
the acquisition and maintenance of the data. In this case the
data is the host names and addresses. In some environments
this information changes fairly rapidly and keeping up-to-date
data may be difficult. This is one motivation for sub-domains.
One may wish to create sub-domains until the rate of change of
the data in a sub-domain domain server data base is easily
managed.
ドメインサーバを操作することにおける難問の1つは、データの獲得とメインテナンスです。 この場合、データは、ホスト名とアドレスです。 いくつかの環境で、この情報はかなり急速に変化します、そして、最新の資料を保つのは難しいかもしれません。 これはサブドメインに関する1つの動機です。 サブドメインドメインサーバデータベースの中のデータの増減率が容易に管理されるまで、サブドメインを作成したがっているかもしれません。
The concepts and implementation details of the domain server
are given in RFCs 882 and 883.
ドメインサーバの概念と実装詳細はRFCs882と883で明らかにされます。
Postel [Page 4]
ポステル[4ページ]
RFC 881 November 1983 The Domain Names Plan and Schedule
ドメイン名が計画して、計画をするRFC881 1983年11月
Minimum Size:
最小規模:
The domain must be of at least a minimum size. Several
measures of size may be used in combination in making this
test. Measures may include: (a) the number of host computers
in the domain, (b) the number of people with primary mailboxes
in the domain, (c) the amount of traffic that crosses the
boundary of the domain [packets/day or mail items/week].
Specific threshold values for these measures will be
established before new domains are authorized.
ドメインは少なくとも最小規模のものであるに違いありません。 サイズの数個の基準がこのテストをする際に組み合わせに使用されるかもしれません。 測定は以下を含むかもしれません。 (a) (b) そのドメインのホストコンピュータの数、プライマリメールボックスがドメイン(c) (ドメイン[パケット/日かメール項目/週]の境界に交差するトラフィックの量)にある人々の数。 新しいドメインが認可されている前にこれらの測定のための特定の閾値は確立されるでしょう。
There is no requirement to form a domain because some set of
hosts is above the minimum size.
最小規模より上には何らかのセットのホストがいるのでドメインを形成するという要件が全くありません。
Registration:
登録:
The administrator must register the domain with the central
authority. The central authority must be satisfied that the
requirements are met before authorization for the domain is
granted.
管理者は主要な権威にドメインを登録しなければなりません。 ドメインへの承認を与える前に必要条件を満たすのを主要な権威を満たさなければなりません。
The administrator of a domain is required to make sure that
host and sub-domain names within that jurisdiction conform to
the standard name conventions and are unique with in that
domain.
ドメインの管理者はその管轄の中のそのホストとサブドメイン名が確実にコンベンションという標準の名前に従って、そのドメインでユニークになるようにしなければなりません。
If sub-domains are set up the administrator may wish to pass
along some of his authority and responsibility to a sub-domain
administrator.
サブドメインがセットアップされるなら、管理者は彼の権限と責任のいくつかをサブドメイン管理者に回したがっているかもしれません。
Mailbox Support
メールボックスサポート
The design of the domain servers provides two levels of support
for mail.
ドメインサーバの設計はメールのための2つのレベルのサポートを提供します。
The first, called "agent binding", is that the right hand part of
the typical mail box (Y in X@Y) can be mapped a host that will
either accept the mail as the destination or accept the mail for
forwarding.
「エージェント結合」と呼ばれる1番目は典型的なメールボックス( X@Y のY)の右手の一部が写像されて、そうするホストが目的地としてメールを認めるか、または推進のためにメールを認めるということであるかもしれないということです。
The second, called "mailbox binding", is to map the entire mailbox
(X@Y) to a destination (this mechanism can also support some
mailing list functions).
「メールボックス結合」と呼ばれる2番目は全体のメールボックス( X@Y )を目的地に写像する(また、このメカニズムは、何らかのメーリングリストが機能であるとサポートすることができます)ことです。
Agent binding can be used to establish mailboxes that are based on
an organization name rather than a host name.
ホスト名よりむしろ組織名に基づいているメールボックスを証明するのにエージェント結合を使用できます。
For example, an organization, "BLAT", with hosts "BLAT-20" and
そして、例えば、組織、ホストがいる"BLAT"、「BLAT-20インチ、」
Postel [Page 5]
ポステル[5ページ]
RFC 881 November 1983 The Domain Names Plan and Schedule
ドメイン名が計画して、計画をするRFC881 1983年11月
"BLAT-VAX" in the ARPA domain could set up mailboxes of the
form "user@BLAT.ARPA" and use the domain server mechanisms for
mapping these to the host that accepts the mail for the
organization.
ARPAドメインの"BLAT-VAX"は、フォーム" user@BLAT.ARPA "のメールボックスをセットアップして、組織のためのメールを受け入れるホストにこれらを写像するのにドメインサーバメカニズムを使用するかもしれません。
Mailbox binding will allow different mappings for individual
mailboxes of an organization or host to the destination host. It
will also provide for aliases and mailing groups.
メールボックス結合は組織かホストの個々のメールボックスのための異なったマッピングをあて先ホストに許容するでしょう。 また、それは別名とグループに郵送するのに提供されるでしょう。
Mailbox binding requires adding information on individual
mailboxes to the domain server database. This could be a
substantial increase in the database size and management
responsibility.
メールボックス結合は、個々のメールボックスの情報をドメインサーバデータベースに追加するのを必要とします。 これはデータベースサイズと経営者の責任のかなりの増加であるかもしれません。
The ARPA Community and the DDN Community
アルパ共同体とDDN共同体
This plan will be put into effect in the ARPA community.
ARPA共同体の効果にこのプランを入れるでしょう。
The DDN community will adopt the domain style names, but will
continue with the present scheme of a centrally maintained table
copied periodically by each host. Once the use of domain servers
has been demonstrated by use in the ARPA community, the DDN-PMO
will establish a schedule for implementing the domain system in
the DDN community.
DDN共同体は、ドメインスタイル名を採用しますが、定期的に各ホストによってコピーされた中心で維持されたテーブルの現在の体系を続行するでしょう。 ドメインサーバの使用がARPA共同体での使用でいったん示されると、DDN-PMOはDDN共同体でドメインシステムを実装するためのスケジュールを確立するでしょう。
This means that there may be a period of a year or more with the
two communities using different schemes for distributing
information about host names and addresses.
これは、2つの共同体がホスト名とアドレスに関する情報伝達に異なった体系を使用している1年以上の期間があるかもしれないことを意味します。
Specifically:
明確に:
The NIC will maintain a table a "HOSTS.TXT" style table for use
by DDN hosts. This table will contain domain style names for
all DDN hosts (e.g., USC-ISIA.DDN). Since this is the only
information DDN hosts will use to translate host names to
Internet Addresses, this table must also contain names and
addresses of ARPA community hosts of interest to DDN users
(e.g., USC-ISIF.ARPA).
NICは、テーブルがDDNホストによる使用のために"HOSTS.TXT"スタイルテーブルであることを支持するでしょう。 このテーブルはすべてのDDNホスト(例えば、USC-ISIA.DDN)のためのドメインスタイル名を含むでしょう。 これがDDNホストがインターネットAddressesにホスト名を翻訳するのに使用する唯一の情報であるので、また、このテーブルはDDNユーザ(例えば、USC-ISIF.ARPA)にとって、興味深いARPA共同体のホストの名前とアドレスを含まなければなりません。
There will be a domain server with data for the DDN domain.
That is, hosts in the ARPA community that use the domain system
of resolvers and servers will be able to access servers that
have the data base covering the DDN community.
DDNドメインのためのデータがあるドメインサーバがあるでしょう。 すなわち、レゾルバとサーバのドメインシステムを使用するARPA共同体のホストはデータベースがDDN共同体をカバーするサーバにアクセスできるでしょう。
It is quite likely that the table for the use of the DDN hosts
will be incomplete with respect to coverage of the ARPA community
and any new domains that are established. One motivation for the
domain system is the subdivision of name management to avoid the
DDNホストの使用のためのテーブルがARPA共同体と確立されるどんな新しいドメインの適用範囲に関しても不完全になるのは、かなりありそうです。 ドメインシステムに関する、ある動機が避ける名前管理の下位区分です。
Postel [Page 6]
ポステル[6ページ]
RFC 881 November 1983 The Domain Names Plan and Schedule
ドメイン名が計画して、計画をするRFC881 1983年11月
difficulty of keeping a global table of all hosts. As the ARPA
community moves to significant use of the domains system the
maintenance of a global table for use by the DDN community will
become very difficult.
すべてのホストのグローバルなテーブルを保つという困難。 ARPA共同体がドメインシステムの重要な使用に移行するとき、DDN共同体による使用のためにグローバルなテーブルのメインテナンスは非常に難しくなるでしょう。
This means that DDN hosts might not be able to look up the names
of some ARPA community hosts in their local tables. In some cases
this might result in an inability establish communication from a
DDN hosts to such "unknown" ARPA community hosts.
これは、DDNホストが地元のテーブルの何人かのARPA共同体のホストの名前を調べることができないかもしれないことを意味します。 これがもたらすかもしれないいくつかの場合では、無能はコミュニケーションをDDNホストから「未知」のそのようなARPA共同体のホストまで確立します。
The most likely case is for a computer mail message sent from
an ARPA community user on a host know to name servers but not
in the central table to a user on a DDN community host that
relies on a local copy of the central table. When the DDN user
attempts to answer this message his mail program will attempt
to look up the host name. This will fail, and the most likely
result is that the mail program will tell the user that there
is no such host!
最もありそうなケースはホストの上のユーザがDDN共同体のユーザへの中央のテーブルではなく、ネームサーバにそれを接待するのを知っているARPA共同体から送られたコンピュータメール・メッセージが中央のテーブルの地方のコピーを当てにするからです。 DDNユーザが、このメッセージに答えるのを試みるとき、彼のメールプログラムは、ホスト名を調べるのを試みるでしょう。 これは失敗するでしょう、そして、最も多くの起こりそうな結果はメールプログラムが、どんなそのようなホストもいないとユーザに言うということです!
Please note that DDN community hosts are permitted (even
encouraged) to implement the domain system in parallel with the
ARPA community. However, there is no requirement that they do so
until called for in the schedule to be established by the DDN-PMO.
DDN共同体のホストがARPA共同体と平行してドメインシステムを実装することが許可されています(奨励さえされます)。 しかしながら、スケジュールでDDN-PMOによって設立されるように求められるまで彼らがそうするという要件が全くありません。
Postel [Page 7]
ポステル[7ページ]
RFC 881 November 1983 The Domain Names Plan and Schedule
ドメイン名が計画して、計画をするRFC881 1983年11月
The Schedule
スケジュール
04-Oct-83 The ARPANET/MILNET Logical Split
1983年10月4日アルパネット/MILNETの論理的な分裂
02-Nov-83 Publish Domain Name Documents
1983年11月2日はドメイン名ドキュメントを発表します。
This Plan and Schedule (RFC-881), Domain Names - Concepts and
Facilities (RFC-882), and Domain Names - Implementation
Specification (RFC-883).
ドメイン名--概念、施設(RFC-882)、およびドメイン名--このプランとスケジュール(RFC-881)、実装仕様(RFC-883)。
16-Nov-83 Make Available Domain Style Host Table
1983年11月16日は利用可能なドメイン様式ホストテーブルを作ります。
Create a copy a modified version of the HOSTS.TXT table named
DHOSTS.TXT with an additional name (as the first name) in each
entry of the form "official-host-name.ARPA".
フォーム「職員ホストname.ARPA」の各エントリーでHOSTS.TXTテーブルの変更されたバージョンが追加名前(名としての)でDHOSTS.TXTと命名したコピーを作成してください。
15-Dec-83 Final Specification of simple Query & Reply Protocol Available
簡単なQuery&ReplyプロトコルAvailableの1983年12月15日Final Specification
This specification covers the protocol procedures and message
formats for the simple queries and replies to support translating
host names to internet addresses only.
この仕様はインターネットアドレスだけにホスト名を翻訳する簡単な質問と回答がサポートするプロトコル手順とメッセージ・フォーマットを含んでいます。
15-Dec-83 Make Limited Domain Server & Resolvers Available
1983年12月15日で、株式会社ドメインサーバとレゾルバは利用可能になります。
An example limited domain server running on TOPS-20 and example
limited resolvers running on each of TOPS-20 and VAX-Berkeley-Unix
should be made available for testing and copying. This simple
version would be able to do queries and responses for host name to
internet address translation only, and the servers would still use
the global table. This simple server would not refer the resolver
to another server. This simple server and these resolvers operate
in datagram mode only. However, this would allow user programs to
begin to use the servers.
それぞれのTOPS-20の上で作業しながらTOPS-20と例の限られたレゾルバの上で作業する例の限られたドメインサーバとVAXバークレーunixをテストとコピーに利用可能にするべきです。 この簡単なバージョンはホスト名のための質問と応答がインターネットアドレス変換だけにできるでしょう、そして、サーバはまだグローバルなテーブルを使用しているでしょう。 この簡単なサーバは別のサーバにレゾルバを差し向けないでしょう。この簡単なサーバとこれらのレゾルバはデータグラムモードだけで働いています。 しかしながら、ユーザ・プログラムはこれでサーバを使用し始めることができるでしょう。
01-Feb-84 Specification of Domain Requirements Available
利用可能なドメイン要求性の1984年2月1日の仕様
Detailed requirements for qualifying a set of hosts as a domain,
and procedure for registering new domains is published.
新しいドメインを登録するのが発行されるのでドメイン、および手順として1セットのホストに資格を与えるための詳細な要件。
15-Feb-84 The ARPANET/MILNET Access Controls
アルパネット/MILNETアクセスが制御する1984年2月15日
MILNET access controls installed in the MILNET/ARPANET gateways
and TAC user access controls put into effect (see DDN MGT Bulletin
16). [Date approximate.]
MILNETアクセス制御は効果に入れられたMILNET/アルパネットゲートウェイとTACユーザアクセス制御にインストールされました(DDN MGT Bulletin16を見てください)。 [日付の大体の。]
Postel [Page 8]
ポステル[8ページ]
RFC 881 November 1983 The Domain Names Plan and Schedule
ドメイン名が計画して、計画をするRFC881 1983年11月
07-Mar-84 Replace Main Host Table with Domain Style Host Table
1984年3月7日はメインホストテーブルをドメイン様式ホストテーブルに取り替えます。
The DHOSTS.TXT becomes HOSTS.TXT.
DHOSTS.TXTはHOSTS.TXTになります。
14-Mar-84 Final Specification of Query & Reply Protocol Available
質問と回答プロトコルの利用可能な1984年3月14日の最終的な仕様
This specification covers the protocol procedures and message
formats for the all queries and replies between resolvers and
servers.
この仕様がプロトコル手順とメッセージ・フォーマットを含んでいる、すべてが、レゾルバとサーバの間で質問して、返答します。
14-Mar-84 Make Improved Domain Servers & Resolvers Available
1984年3月14日で、改良されたドメインサーバとレゾルバは利用可能になります。
An example improved domain server running on TOPS-20 and example
improved resolvers running on each of TOPS-20 and
VAX-Berkeley-Unix should be made available for testing and
copying. This version should be able to do any of the defined
query and response operations, and should support segmented data
base by refering resolvers to other servers if necessary. This
server loads zone data from local master files only, and only at
program start up. This server and these resolvers operate with
either datagram or reliable connection style communication. This
version does not support the data base update portion of the
server protocol.
それぞれのTOPS-20の上で作業しながらTOPS-20と例の改良されたレゾルバの上で作業する例の改良されたドメインサーバとVAXバークレーunixをテストとコピーに利用可能にするべきです。 このバージョンは、定義された質問と応答操作のどれかができるべきであり、必要なら、他のサーバにレゾルバをreferingすることによって、区分されたデータベースをサポートするべきです。 このサーバはローカルの基本ファイルだけと、プログラム始動だけでゾーンデータをロードします。 このサーバとこれらのレゾルバはデータグラムか信頼できる接続スタイルコミュニケーションのどちらかで働いています。 このバージョンはサーバプロトコルのデータベースのアップデート部分をサポートしません。
04-Apr-84 Domain Servers for ARPA Domain Available
利用可能なアルパドメインへの1984年4月4日のドメインサーバ
Authoritative domain servers for the ARPA domain will be available
for regular use.
ARPAドメインへの正式のドメインサーバは定期的な使用に利用可能になるでしょう。
02-May-84 Introduce New Domains in the Main Host Table
1984年5月2日はメインホストテーブルの新しいドメインを導入します。
Add the DDN domain. Most MILNET hosts will change to the DDN
domain. Authoritative domain servers for the DDN domain will be
available for regular use. HOSTS.TXT is updated.
DDNドメインを加えてください。 ほとんどのMILNETホストがDDNドメインに変化するでしょう。 DDNドメインへの正式のドメインサーバは定期的な使用に利用可能になるでしょう。 HOSTS.TXTをアップデートします。
02-May-84 Establish a New Top Level Domains Only Table
1984年5月2日はドメインが見送るだけである新しいトップレベルを確立します。
Start a new table, DOMAINS.TXT, that lists only the top level
domains and the entries for their domain servers.
新しいテーブル、それらのドメインサーバのためにトップ・レベル・ドメインとエントリーだけを記載するDOMAINS.TXTを始動してください。
16-May-84 Final Specification of Maintenance Protocol Available
メインテナンスプロトコルの利用可能な1984年5月16日の最終的な仕様
This specification covers the protocol procedures and message
formats for the data base update exchanges between servers.
この仕様はプロトコル手順をカバーしています、そして、データベースへのメッセージ・フォーマットはサーバの間の交換をアップデートします。
16-May-84 Make Improved Domain Servers & Resolvers Available
1984年5月16日で、改良されたドメインサーバとレゾルバは利用可能になります。
An example improved domain server running on TOPS-20 and example
TOPS-20と例の上で作業する例の改良されたドメインサーバ
Postel [Page 9]
ポステル[9ページ]
RFC 881 November 1983 The Domain Names Plan and Schedule
ドメイン名が計画して、計画をするRFC881 1983年11月
improved resolvers running on each of TOPS-20 and
VAX-Berkeley-Unix should be made available for testing and
copying. This version should be able to do any of the defined
query and response operations, and should support segmented data
base by refering resolvers to other servers if necessary. This
server loads zone data from local master files and remote servers,
and only at program start up. This server and these resolvers
operate with either datagram or reliable connection style
communication.
それぞれのTOPS-20の上で作業している改良されたレゾルバとVAXバークレーunixをテストとコピーに利用可能にするべきです。 このバージョンは、定義された質問と応答操作のどれかができるべきであり、必要なら、他のサーバにレゾルバをreferingすることによって、区分されたデータベースをサポートするべきです。 このサーバはローカルの基本ファイルとリモートサーバと、プログラム始動だけでゾーンデータをロードします。 このサーバとこれらのレゾルバはデータグラムか信頼できる接続スタイルコミュニケーションのどちらかで働いています。
06-Jun-84 Permit the Introduction of New Domains
1984年6月6日は新しいドメインの導入を可能にします。
Organizations meeting the requirements for establishing new
domains will be allowed to begin use of new domain names. New
domains must be registered, meet the requirements (including
running domain servers), and will be added to the HOSTS.TXT table.
新しいドメインを確立するために条件を満たす組織は新しいドメイン名の使用を始めることができるでしょう。 新しいドメインは、登録しなければならなくて、条件を満たして(ドメインサーバを実行するのを含んでいます)、HOSTS.TXTテーブルに加えられるでしょう。
18-Jul-84 Final Specification of Complete Protocol Available
利用可能な完全なプロトコルの1984年7月18日の最終的な仕様
This specification covers the protocol procedures and message
formats for the complete domain names system.
この仕様は完全なドメイン名システムのためにプロトコル手順とメッセージ・フォーマットを含んでいます。
18-Jul-84 Make Full Domain Servers & Resolvers Available
1984年7月18日で、完全なドメインサーバとレゾルバは利用可能になります。
At this point an example domain server and an example resolver
running on each of TOPS-20 and VAX-Berkeley-Unix should be made
available for testing and copying. This version should be able to
do any of the defined query and response operations, and should
support segmented data base by refering resolvers to other servers
if necessary. This version should support the data base update
portion of the server protocol, including data aging and dynamic
zone updating from remote servers. This is a full implementation
of the protocol.
ここに、例のドメインサーバ、それぞれのTOPS-20の上で作業している例のレゾルバ、およびVAXバークレーunixをテストとコピーに利用可能にするべきです。 このバージョンは、定義された質問と応答操作のどれかができるべきであり、必要なら、他のサーバにレゾルバをreferingすることによって、区分されたデータベースをサポートするべきです。 このバージョンはサーバプロトコルのデータベースのアップデート部分をサポートするべきです、リモートサーバからのデータの古くてダイナミックなゾーンアップデートを含んでいて。 これはプロトコルの完全な実施です。
05-Sep-84 Discontinue the Full Host Table for the ARPA Community
1984年9月5日は完全なホストテーブルのアルパ共同体に使用をやめます。
Stop maintaining the HOSTS.TXT table for the ARPA community. The
HOSTS.TXT table continues to be used in the DDN community with
complete data for the DDN domain, however the data for the ARPA
and other domains may no longer be complete or fully up to date.
ARPA共同体にHOSTS.TXTテーブルを維持するのを止めてください。 しかしながら、ARPAと他のドメインのためのデータは、もうHOSTS.TXTテーブルが、DDNドメインにDDN共同体で完全なデータで使用され続けてもいません、そして、完全でもなくて、完全に最新でもあるかもしれないというわけではありません。
03-Oct-84 DDN-PMO Schedules DDN Implementation
1984年10月3日のDDN-PMOスケジュールDDN実装
The DDN-PMO establishes the schedule for the implementation of the
domain system in the DDN community.
DDN-PMOはドメインシステムの実装のためのスケジュールをDDN共同体に確立します。
Postel [Page 10]
ポステル[10ページ]
一覧
スポンサーリンク
