RFC830 日本語訳
0830 Distributed system for Internet name service. Z. Su. October 1982. (Format: TXT=31597 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Request for Comments: 830
コメントを求めるワーキンググループ要求をネットワークでつないでください: 830
A Distributed System for Internet Name Service
インターネット名前サービスのための分散システム
by
Zaw-Sing Su
Zaw歌っているSu
+-------------------------------------------------------------+
| |
| This RFC proposes a distributed name service for DARPA |
| Internet. Its purpose is to focus discussion on the |
| subject. It is hoped that a general consensus will |
| emerge leading eventually to the adoption of standards. |
| |
+-------------------------------------------------------------+
+-------------------------------------------------------------+ | | | このRFCはDARPAのために分配された名前サービスを提案します。| | インターネット。 目的は焦点議論にオンです。| | 受けることがある。 全体的な合意がそうすることが望まれています。| | 結局規格の採用に通じながら、現れてください。 | | | +-------------------------------------------------------------+
October 1982
1982年10月
SRI International
333 Ravenswood Avenue
Menlo Park, California 94025
SRIインターナショナル333レーヴンズウッド・Avenueメンローパーク、カリフォルニア 94025
(415) 859-4576 RFC 830 October 1982
(415)859-4576RFC830 1982年10月
A Distributed System for Internet Name Service
インターネット名前サービスのための分散システム
1 INTRODUCTION
1つの序論
For many years, the ARPANET Naming Convention "<user>@<host>" has
served its user community for its mail system. The substring "<host>"
has been used for other user applications such as file transfer (FTP)
and terminal access (Telnet). With the advent of network
interconnection, this naming convention needs to be generalized to
accommodate internetworking. The Internet Naming Convention [1]
describes a hierarchical naming structure for serving Internet user
applications such as SMTP for electronic mail, FTP and Telnet for file
transfer and terminal access. It is an integral part of the network
facility generalization to accommodate internetworking.
何年も、「<ユーザ>@<ホスト>」がメールシステムのためのユーザーコミュニティに役立ったアルパネットNaming Conventionのために。 サブストリング「<ホスト>」はファイル転送(FTP)と端末のアクセス(telnet)などの他のユーザ応用に使用されました。 ネットワーク相互接続の到来で、この命名規則は、インターネットワーキングを収容するために一般化される必要があります。 インターネットNaming Convention[1]はファイル転送と端末のアクセサリーのために電子メール、FTP、およびTelnetのためのSMTPなどのアプリケーションをインターネットユーザにサービスするための階層的な命名構造について説明します。 インターネットワーキングを収容するのは、ネットワーク施設一般化の不可欠の部分です。
Realization of Internet Naming Convention requires the
establishment of both naming authority and name service. In this
document, we propose an architecture for a distributed System for
Internet Name Service (SINS). We assume the reader's familiarity with
[1], which describes the Internet Naming Convention.
インターネットNaming Conventionの実現は権威を命名して、名前サービスの両方を設立に要求します。 本書では、私たちは分配されたSystemのためにインターネットName Service(SINS)にアーキテクチャを提案します。 私たちは[1]への読者の親しみを仮定します。([1]はインターネットNaming Conventionについて説明します)。
Internet Name Service provides a network service for name
resolution and resource negotiation for the establishment of direct
communication between a pair of source and destination application
processes. The source application process is assumed to be in
possession of the destination name. In order to establish
communication, the source application process requests for name service.
The SINS resolves the destination name for its network address, and
provides negotiation for network resources. Upon completion of
successful name service, the source application process provides the
destination address to the transport service for establishing direct
communication with the destination application process.
インターネットName Serviceは1組のソースと目的地アプリケーションプロセスとの名前解決のためのネットワーク・サービスとダイレクトコミュニケーションの確立のためのリソース交渉を提供します。 ソースアプリケーション・プロセスが目的地名の所有物にあると思われます。 コミュニケーションを確立するために、ソースアプリケーションは名前サービスを求める要求を処理します。 SINSはネットワーク・アドレスのために目的地名を決議して、交渉をネットワーク資源に供給します。 うまくいっている名前サービスの完成のときに、ソースアプリケーション・プロセスは目的地アプリケーション・プロセスとのダイレクトコミュニケーションを確立するための輸送サービスに送付先アドレスを提供します。
2 OVERVIEW
2概要
2.1 System Organization
2.1 システム構成
SINS is a distributed system for name service. It logically
consists of two parts: the domain name service and the application
interface (Figure 1). The domain name service is an application
independent network service for the resolution of domain names. This
resolution is provided through the cooperation among a set of domain
SINSは名前サービスのための分散システムです。 それは2つの部品から論理的に成ります: ドメイン名サービスとアプリケーションは(図1)を連結します。 ドメイン名サービスはドメイン名の解決のためのアプリケーションの独立しているネットワーク・サービスです。 ドメインのセットの中で協力でこの解決を提供します。
1
RFC 830 October 1982
1RFC830の1982年10月
name servers (DNSs). With each domain is associated a DNS.* The reader is referred to [2] for the specification of a domain name server. As noted in [1], a domain is an administrative but not necessarily a topological entity. It is represented in the networks by its associated DNS. The resolution of a domain name results in the address of its associated DNS.
ネームサーバ(DNSs)。 各ドメインと共に、関連a DNSがあります。*読者はドメイン名サーバの仕様のための[2]を参照されます。ドメインは、[1]に述べられるように管理実体であるというわけではありませんが、必ず位相的な実体であるというわけではありません。 それはネットワークで関連DNSによって表されます。 ドメイン名の解決は関連DNSのアドレスをもたらします。
Application Application
Process Process
| |
SINS | |
-------|---------------------------------------------|----- Application
| AIP AIP | Interface
| | | | . . . . . . .
| DNS - - - DNS - - - DNS - - . . . - - DNS | Domain Name
----------------------------------------------------------- Service
アプリケーションアプリケーション・プロセスプロセス| | 罪| | -------|---------------------------------------------|----- アプリケーション| AIP AIP| インタフェース| | | | . . . . . . . | DNS--、--、--DNS----、--DNS----、…--、--、DNS| ドメイン名----------------------------------------------------------- サービス
Figure 1 Separation of Application Interface
図1 HTTPサーバとNETSCAPE間のインタフェースの分離
The application interface provides mechanisms for resolution beyond
that of destination domain and negotiation to ensure resource
availability and compatibility. Such negotiation is sometimes referred
to as the "what-can-you-do-for-me" negotiation. The application
interface isolates domain name service from application dependence. It
thus allows sharing of domain name service among various user
applications.
アプリケーション・インターフェースは目的地ドメインと交渉のものを超えたリソースの有用性と互換性を確実にする解決にメカニズムを提供します。 そのような交渉は時々「あなたは組版がことにできる」という交渉と呼ばれます。 アプリケーション・インターフェースはアプリケーションの依存からドメイン名サービスを隔離します。 それで、その結果、様々なユーザアプリケーションの中でドメイン名サービスを共有します。
The application interface consists of a set of application
interface processes (AIPs) one for each endpoint domain. For operation
efficiency, the AIP is assumed to be combined with its associated DNS
forming an endpoint DNS (Figure 2).
アプリケーション・インターフェースはそれぞれの終点ドメインへの1セットのアプリケーション・インターフェースプロセス(AIPs)1から成ります。 操作効率において、AIPによって終点DNS(図2)を形成する関連DNSに結合されると思われます。
Application Application
Process Process
| |
SINS | |
-------|---------------------------------------------|-------
| Endpoint Endpoint |
| DNS - - - DNS - - - DNS - - . . . - - DNS |
| |
-------------------------------------------------------------
アプリケーションアプリケーション・プロセスプロセス| | 罪| | -------|---------------------------------------------|------- | 終点終点| | DNS--、--、--DNS----、--DNS----、…--、--、DNS| | | -------------------------------------------------------------
Figure 2 Distribution of Name Service Components Among Domains
図2 ドメインの中の名前サービスコンポーネントの分配
-------------------- * For reasons such as reliability, more than one DNS per domain may be required. They may be cooperating DNSs or identical for redundancy. In either case, without loss of generality we may logically view the association as one DNS per domain.
-------------------- * 信頼性などの理由で、1ドメインあたり1DNSが必要であるかもしれません。 彼らは冗長にDNSsか同じ状態で協力しているかもしれません。 どちらの場合ではも、一般性の喪失がなければ、私たちは1ドメインあたり1DNSであると協会を論理的にみなすかもしれません。
2 RFC 830 October 1982
2 RFC830 1982年10月
2.2 Domain Resolution
2.2 ドメイン解決
For name service, the source application process presents to its
local AIP the destination name, and the application service it requests.
For most applications, the application service the source application
process requests would be the service it offers. The destination name
is assumed to be fully qualified of the form:
名前サービスのために、ソースアプリケーション・プロセスは目的地名、およびそれが要求するアプリケーション・サービスを地方のAIPに提示します。 ほとんどのアプリケーションのために、ソースアプリケーション・プロセスが要求するアプリケーション・サービスはそれが提供するサービスでしょう。 フォームについて目的地名が完全に資格があると思われます:
<local name>@<domain>.<domain>. ... .<domain>
<地方名>@<ドメイン><ドメイン>。 ... . <ドメイン>。
The domains named in the concatenation are hierarchically related [1]. The left-to-right string of simple names in the concatenation proceeds from the most specific domain to the most general. The concatenation of two domains,
連結で指定されたドメインは階層的に関係づけられます。[1]。 左から右への連結における単純名のストリングは最も特定のドメインから最も多くの一般まで続きます。 2つのドメインの連結
... .<domain A>.<domain B>. ...
... . <ドメインA><ドメインB>。
implies the one on the left, domain A, to be an immediate member (i.e., the first-generation descendent) of the one on the right, domain B. The right-most simple name designates a top-level domain, a first-generation descendent of the naming universe.
左のもの、ドメインAが即座のメンバーであることを含意する、(すなわち、第一世代、下降、)、右(最も権利単純名が最上位のドメイン、命名宇宙における下降の第一世代を指定するドメインB.)のもの
For domain resolution, the AIP consults the domain name service. It
presents the co-located DNS with the fully qualified domain
specification:
ドメイン解決のために、AIPはドメイン名サービスに相談します。 それは完全に適切なドメイン仕様を共同見つけられたDNSに与えます:
<domain>.<domain>. ... .<domain>
<ドメイン><ドメイン>。 ... . <ドメイン>。
The DNSs participating in a resolution resolve the concatenation from the right. The source endpoint DNS resolves the right-most simple name and acts as a hub polling the other DNSs. It resolves the right-most simple name into an address for the DNS of the specified top-level domain, then polls that DNS with a request for further resolution. When polled, a DNS resolves the next right-most simple domain name. Upon successful resolution, an intermediate DNS may have a choice of either returning the resulting address or forwarding the request to the next DNS for continuing resolution. When a intermediate DNS receives a reply from the next DNS, it must respond to the request it has received. To simplify the domain name service protocol, an intermediate DNS is not allowed to act as a hub for further polling.
解決に参加するDNSsは右から連結を決議します。 ソース終点DNSは最も権利単純名を決議して、ハブポーリングとして他のDNSsを機能させます。 それは指定された最上位のドメインのDNSのためのアドレスに最も権利単純名に変えて、次に、投票はさらなる解決を求める要求があるそのDNSです。 投票されると、DNSは次の最も権利の簡単なドメイン名を決議します。 うまくいっている解決のときに、中間的DNSには、予算継続決議のために結果として起こるアドレスを返すか、または次のDNSに要求を転送することの選択があるかもしれません。 中間的DNSが次のDNSから回答を受け取るとき、それは受け取った要求に応じなければなりません。 ドメイン名サービスプロトコルを簡素化するために、中間的DNSはさらなる世論調査のためのハブとして機能できません。
2.3 Application Interface
2.3 HTTPサーバとNETSCAPE間のインタフェース
Addressing for destination endpoint domain is in general not
sufficient for the source application process to establish direct
communication with the destination application process. In order to
establish direct communication, further addressing may be necessary.
Addressing beyond destination endpoin domain may be necessary when the
addressing of application process cannot be derived from the address of
the endpoint domain. To provide such derivation capability permanent
binding and universal binding convention, such as TCP port number
assignment, may be necessary.
一般に、目的地終点ドメインに扱うのは、そうです。ソースアプリケーション・プロセスが目的地アプリケーション・プロセスとのコミュニケーションをダイレクトに証明するように、十分ではありません。 ダイレクトコミュニケーションを確立するために、さらなるアドレシングが必要であるかもしれません。 終点ドメインのアドレスからアプリケーション・プロセスのアドレシングを得ることができないとき、目的地endpoinドメインを超えたアドレシングが必要であるかもしれません。 TCPポートナンバー課題などのように、そのような派生の能力の永久的な拘束力があって普遍的な拘束力があるコンベンションを供給するのが必要であるかもしれません。
3
RFC 830 October 1982
3 RFC830 1982年10月
Beyond addressing, negotiation for resource availability and
compatibility is often found necessary. The application interface
provides a "what-can-you-do-for-me" negotiation capability between the
source and destination endpoint domains. Such negotiation mechanisms
provided in this design include those for the availability and
compatibility of transport service, e.g., TCP or UDP, and application
service, e.g., SMTP for mail transport. The availability of such
negotiation service may allow dynamic binding and variations in system
design.
アドレシングを超えて、しばしばリソースの有用性と互換性のための交渉が必要であることがわかります。 アプリケーション・インターフェースは「あなたは組版がことにできる」という交渉能力をソースと目的地終点ドメインの間に提供します。 このデザインに提供されたそのような交渉メカニズムは有用性のためのそれらと例えば、輸送サービスかTCPかUDPと、アプリケーション・サービス(例えば、メール輸送のためのSMTP)の互換性を含んでいます。 そのような交渉サービスの有用性はシステム設計のダイナミックな結合と変化を許容するかもしれません。
The application interface offers an integrated service for various
"what-can-you-do-for-me" negotiation capabilities.
アプリケーション・インターフェースは「あなたは組版がことにできる」という様々な交渉能力のために統合サービスを提供します。
2.4 Example
2.4 例
Let us assume that a request is made at ISID for remote file
transfer using NIFTP to SRI-TSC. The domain name for ISID is
D.ISI.USC.ARPA,* and TSC.SRI.ARPA for SRI-TSC. The hierarchical
relationship between these two domains is as depicted in Figure 3 below.
The NIFTP process (an application process) at ISID forwards the domain
name TSC.SRI.ARPA" to the local AIP in domain D for name service. The
AIP forwards the fully qualified domain name, "TSC.SRI.ARPA", to its co-
located DNS for domain resolution.
遠隔ファイル転送のためにISIDでSRI-TSCにNIFTPを使用することで要求をすると仮定しましょう。 ISIDのためのドメイン名は、SRI-TSCのためのD. ISI.USC.ARPAと、*とTSC.SRI.ARPAです。 これらの2つのドメインの間の上下関係が以下の図3に表現されるようにあります。 名前サービスのためのドメインDの地方のAIPに「ISIDのNIFTPプロセス(アプリケーション・プロセス)はドメイン名TSC.SRI.ARPAを進めます」。 AIPはドメイン解決のために完全修飾ドメイン名、"TSC.SRI.ARPA"を共同見つけられたDNSに送ります。
ARPA, the right-most simple name, is assumed to designate a top-
level domain. The DNS of D recognizes this simple name, resolves it
into the address of the ARPA domain DNS, and forwards the request to
that DNS with a pointer pointing to the next domain "SRI". The ARPA DNS
recognizes "SRI" as one of its subdomains, resolves the address of the
subdomain's DNS. It has a choice at this point whether to return this
address to the source endpoint DNS or to forward the request to the DNS
of SRI.
ARPA(最も権利単純名)が先端の平らなドメインを指定すると思われます。 DのDNSは、この単純名を認識して、ARPAドメインDNSのアドレスにそれに変えて、指針と共に次のドメイン「様」を示しながら、そのDNSに要求を転送します。 サブドメインのDNSのアドレスは、ARPA DNSがサブドメインの1つとして「様」を認識すると決議します。 これが扱うリターンにか否かに関係なく、それはここにソース終点DNS、または、フォワードに選択を持っています。SRIのDNSへの要求。
naming
universe
/ \
--- ARPA (DNS)
/ |
/ SRI (DNS)
/ | \
USC (DNS) TSC (DNS/AIP)
| |
| [TCP/FTP/RFT]
ISI (DNS)
|
D (DNS/AIP)
/ \
[TCP/NIFTP/RFT] [TCP/FTP/RFT]
|
user
宇宙/\を命名します。--- アルパ(DNS)/| /様(DNS)の/| \USC(DNS)TSC(DNS/AIP)| | | [TCP/FTP/RFT] ISI(DNS)| D(DNS/AIP)/\[TCP/NIFTP/RFT][TCP/FTP/RFT]| ユーザ
-------------------- * Domain names used in the examples are for illustration purposes only. The assignment of domain names is beyond the scope of this writeup.
-------------------- * 例で使用されるドメイン名はイラスト目的だけのためのものです。 ドメイン名の課題はこの記事の範囲を超えています。
4
RFC 830 October 1982
4 RFC830 1982年10月
If it returns the address, the source endpoint DNS at D, would continue polling by forwarding the request to the SRI DNS. When the DNS of SRI detects TSC as the last domain in the concatenation, it resolves the address for the DNS at TSC, and returns it to the source DNS at domain D. Upon receiving a successful domain resolution, the source DNS returns the obtained address to its associated AIP.
戻るなら、アドレス(Dのソース終点DNS)は、要求をSRI DNSに転送することによって投票し続けているでしょう。 SRIのDNSが連結における最後のドメインとしてTSCを検出するとき、TSCでDNSのためのアドレスを決議して、うまくいっているドメイン解決を受けながら、ドメインD.UponでソースDNSにそれを返します、DNSが関連AIPへの得られたアドレスを返すソース。
Since the destination AIP is co-located at this address, the source
AIP is able to forward a request with the service designation
"TCP/NIFTP/RFT" for "what-can-you-do-for-me" negotiation. Realizing
that within TSC there is no NIFTP but FTP provided for remote file
transfer, the destination AIP would respond accordingly. Since ISID
also offers FTP service, the "what-can-you-do-for-me" negotiation may
conclude successfully. The user request for file transfer may thus be
satisfied.
目的地AIPがこのアドレスに共同位置しているので、ソースAIPは「あなたは組版がことにできる」サービス名称「TCP/NIFTP/RFT」交渉と共に要求を転送できます。 そこのTSCの中のそれがNIFTPではありませんが、FTPが遠隔ファイル転送に備えたとわかって、目的地AIPはそれに従って、応じるでしょう。 また、以来、ISIDはFTPサービス、交渉が首尾よく結論づけるかもしれない「あなたは組版がことにできること」を提供します。 その結果、ファイル転送を求めるユーザ要求は満たされるかもしれません。
3 SYSTEM COMPONENTS
3 システムの部品
3.1 Component Processes
3.1 コンポーネントプロセス
The two basic distributed components of SINS are the endpoint DNS
and the intermediate DNS. An endpoint DNS is associated with each
endpoint domain. An intermediate DNS is associated with a domain
without any associated application process.
SINSの2つの基本的な分配された部品が、終点DNSと中間的DNSです。 終点DNSはそれぞれの終点ドメインに関連しています。 中間的DNSは少しも関連するアプリケーションプロセスなしでドメインに関連しています。
The intermediate DNS is rather simple. It has the resolution
capability for translating simple names of first-generation subdomains
to addresses of their associated DNS. It also communicates with other
DNS for domain resolution.
中間的DNSはかなり簡単です。 それには、それらの関連DNSのアドレスに第一世代サブドメインの単純名を翻訳するための解決能力があります。 また、それはドメイン解決のために他のDNSとコミュニケートします。
An endpoint DNS consists of an AIP and a source DNS. The source
DNS implements the polling mechanism which communicates with other DNSs
as a hub for polling. It also has capability for the resolution of top-
level domains. It responds to requests from the local AIP for domain
resolution (Section 4.2.3).
終点DNSはAIPとソースDNSから成ります。 ソースDNSは世論調査のためのハブとして他のDNSsとコミュニケートする世論調査メカニズムを実装します。 また、それには、先端の平らなドメインの解決のための能力があります。 それはドメイン解決(セクション4.2.3)のために地方のAIPから要求に応じます。
The major function of an AIP implements the intellegence of "what-
can-you-do-for-me" negotiations. A communication module realizes
negotiation exchanges between the source and destination AIPs (Section
4.2.2). As an interface between the application processes and the local
DNS, it must also implement communication capabilities for exchanges
with the DNS and the application processes.
あなたは組版ができます。AIPの主要な機能がintellegenceを実装する、「何、-、」 交渉。 コミュニケーションモジュールは、交渉がソースと目的地の間でAIPs(セクション4.2.2)を交換するとわかります。 また、アプリケーション・プロセスと地方のDNSとのインタフェースとして、それは、DNSとアプリケーション・プロセスに従った交換のためにコミュニケーションが能力であると実装しなければなりません。
3.2 Databases for Name Resolution
3.2 名前解決のためのデータベース
There is a database associated with each resolution module. The
database associated with an endpoint domain contains name-to-address
それぞれの解決モジュールに関連しているデータベースがあります。 終点ドメインに関連しているデータベースは名前からアドレスを含んでいます。
5
RFC 830 October 1982
5 RFC830 1982年10月
correspondences for the top-level domains, first-generation descendents of the naming universe. It facilitates the endpoint DNS resolving the right-most simple name of a fully-qualified domain specification.
最上位のドメインのための通信、命名宇宙の第一世代descendents。 それは完全に適切なドメイン仕様の最も権利単純名を決議する終点DNSを容易にします。
The database associated with an intermediate domain contains name-
to-address correspondences for the first-generation subdomains of this
domain. Thus, the required database contents among the intermediate DNS
databases are disjoint, and updates are local.
中間的ドメインに関連しているデータベースはこのドメインに関する第一世代サブドメインのためのアドレスへの名前通信を含んでいます。 ばらばらになって、その結果、中間的DNSデータベースの中の必要なデータベースコンテンツはそうです。アップデートは地方です。
It is also noticed that with the implementation of the SINS, there
is no need for database format standardization.
また、SINSの実装と共に、データベース形式標準化の必要は全くないのに気付かれています。
3.3 Caching
3.3 キャッシュ
The component processes and resolution databases constitute the
basic System for Internet Name Service. The distributed components are
related according to the domain hierarchy. The databases associated
with the endpoint domains are all identical. Containing only name-to-
address correspondence for top-level domains, the endpoint database
should be rather small in size. The disjoint nature of intermediate DNS
databases allows easy local updates.
コンポーネントプロセスと解決データベースはインターネットName Serviceのために基本的なSystemを構成します。 ドメイン階層構造に従って、分配されたコンポーネントは関係づけられます。 終点ドメインに関連しているデータベースはすべて同じです。 最上位のドメインのための名前からアドレスへの通信だけを含んでいて、終点データベースはサイズがかなり小さいはずです。 データベースが簡単な地方のアップデートを許す中間的DNSの自然をばらばらにならせてください。
However, communications will be very inefficient if the Internet
name service is called for the establishment of every transaction. A
standard solution to aleviate such inefficiency is the use of caching.
しかしながら、サービスというインターネット名があらゆるトランザクションの設立のために呼ばれるなら、コミュニケーションは非常に効率が悪くなるでしょう。 aleviateのそのような非能率の標準液はキャッシュの使用です。
Caching is a mechanism reusing previous resolution results. To
expedite establishment of communication, the resolution results are
stored for future reference. We do not incorporate caching as a
standard feature of the SINS. However, we assume the use of caching for
efficient operations at individual implementor's discretion.
キャッシュは前の解決結果を再利用するメカニズムです。 コミュニケーションの確立を速めるために、解決結果は後日のために保存されます。 私たちはSINSの標準装備としてのキャッシュを取り入れません。 しかしながら、私たちは個々の作成者の裁量でキャッシュの効率的な操作の使用を仮定します。
4 INTER-COMPONENT COMMUNICATIONS (THE INTERNET NAME SERVICE PROTOCOLS)
4 相互コンポーネントコミュニケーション(インターネット名前サービスプロトコル)
In this section, we present a format specification for
correspondences between various component pairs. For co-located
components, communication becomes interprocess, and the exact format
less important. For inter-host communication, the format specification
here defines a name service protocol.
このセクションでは、私たちは様々なコンポーネント組の間の通信のために書式仕様を提示します。 共同見つけられたコンポーネントのために、コミュニケーションはインタプロセスになります、そして、正確はそれほど重要でないのをフォーマットします。 相互ホストコミュニケーションに関しては、ここの書式仕様は名前サービスプロトコルを定義します。
The communicating component pairs of concern here are application
process/AIP, AIP/DNS, and AIP/AIP. The communications employ
request/response commands. A single command structure is adopted for
all three pairs; while communications between a particular pair may
employ a subset of the commands. Such uniformity allows minimum
processing and maximum code sharing for implementation.
ここで重要な交信しているコンポーネント組は、アプリケーション・プロセス/AIPと、AIP/DNSと、AIP/AIPです。 コミュニケーション雇用要求/応答命令。 ただ一つの命令系統はすべての3組採用されます。 特定の組のコミュニケーションはコマンドの部分集合を使うかもしれませんが。 そのような一様性は実装のための最小の処理と最大のコード・シェアリングを許容します。
6
RFC 830 October 1982
6 RFC830 1982年10月
4.1 Command Structure
4.1 命令系統
The basic command structure begins with two octets indicating
command type and the number of items in the command. They are followed
by the indicated number of items. The type of an item is indicated in
its first octet, followed by a one-octet content length, and then the
item content. Required presence or absence and order of the items for
each component pair are specified in this section.
2つの八重奏がコマンドにおけるコマンドタイプと件数を示していて、基本コマンド構造は始まります。 項目の示された数はそれらのあとに続いています。項目のタイプは1八重奏のコンテンツの長さ、および次に、項目内容があとに続いた最初の八重奏で示されます。 このセクションでそれぞれのコンポーネント組項目の必要な存在か不在と注文を指定します。
Command Type Number of Items
項目のコマンド形式数
Item Indicator Content Length Item Content
.
.
項目インディケータコンテンツの長さ項目内容。
Command Type
コマンドタイプ
This type coded in binary number indicates whether this command is
a request, an affirmative response, or some other type of response (see
Appendix A for the command types and their corresponding code). This
type specification implies the presence or absence and order of the
following items.
2進の数でコード化されたこのタイプは、このコマンドが要求であるかどうかを示します、肯定的な応答、またはある他のタイプの応答(コマンドタイプと彼らの対応するコードに関してAppendix Aを見てください)。 このタイプ仕様は以下の項目の存在か不在と注文を含意します。
Number of Items
件数
This number is expressed in binary number. It specifies the number
of following items. Owing to the possibility of a multiple response,
this number may vary for a particular command.
この数は2進の数で表されます。 それは次の項目の数を指定します。複数の応答の可能性のために、この数は特定のコマンドのために異なるかもしれません。
Item Indicator
項目インディケータ
This indicator defines the item type. The possible types include:
service, name, address, and comment. The type of an item implies its
content structure.
このインディケータは項目タイプを定義します。 可能なタイプは: 修理して、命名して、扱って、論評します。 項目のタイプは満足している構造について暗示します。
Content Length
コンテンツの長さ
This length specification, in binary, indicates the length of the
following content in octets. The maximum can be specified is 255, thus
the maximum length of the content. However, this maximum may also be
constrained by the total length of the command (Section 4.3).
バイナリーで、この長さの仕様は八重奏における、以下の内容の長さを示します。 最大は指定されているのが、255、その結果、内容の最大の長さであるということであるかもしれません。 しかしながら、また、この最大はコマンド(セクション4.3)の全長によって抑制されるかもしれません。
Item Content
項目内容
The contents for different items are:
Service -- Transport protocol/service protocol/service type
(ASCII). (See Appendix A for standard identifiers for
service specifications.)
Name -- Whole or partial name string according to Internet Naming
Convention [1] (ASCII).
Address -- The address is presented in binary form. In this
writeup, double quotes, " ", are used around decimal
values separated by a space to represent octets of the
binary form.
異なった項目のための内容は以下の通りです。 サービス--Transportはプロトコル/サービスタイプ(ASCII)に議定書の中で述べるか、またはサービスを提供します。 (サービス仕様のための標準の識別子に関してAppendix Aを見てください。) 名前--インターネットNaming Convention[1](ASCII)に従った全体的、または、部分的な名前ストリング。 アドレス--アドレスは二部形式に提示されます。 この記事では、引用文を倍にしてください、「「スペースによって切り離された、二部形式の八重奏を表したデシマル値の周りで使用される、」
7
RFC 830 October 1982
7 RFC830 1982年10月
Parsing of the address is implied by the specified
transport protocol. In the case of TCP, the first
four octets gives the 32-bit IP address, the 5th octet
the IP-specific protocol number, and the 6th the TCP or
UDP port number for the application service.
アドレスの構文解析は指定されたトランスポート・プロトコルによって含意されます。 TCPの場合では、最初の4つの八重奏が32ビットのIPアドレスを与えて、5番目の八重奏がIP特有のプロトコル番号であり、6番目は、アプリケーション・サービスのためのTCPかUDPポートナンバーです。
Comment -- The item is mostly optional. Its presence may allow
an intermediate server passing comment to the end user.
Error comments explaining resolution failure is an
example of its use.
コメント--項目はほとんど任意です。 存在は中間的サーバふと口に出た言葉をエンドユーザに許容するかもしれません。 解決失敗が使用に関する例であると説明しながら、誤りはコメントします。
4.2 Command Specification
4.2 コマンド仕様
In this section, we define the name service commands for the
various communication pairs.
このセクションで、私たちは軍管区という名前を様々なコミュニケーション組定義します。
4.2.1 Application Process/AIP Communication
4.2.1 アプリケーション・プロセス/AIPコミュニケーション
From the name service point of view, there is no need for
communication between the AIP and an application process at the
destination. Thus, here we discuss communications at the originating
domain.
視点の名前サービスポイントから、AIPとアプリケーション・プロセスとのコミュニケーションの必要性は全く目的地で来ていません。 したがって、ここで、私たちは起因するドメインでコミュニケーションについて議論します。
An application process initiates a dialogue by making a request for
name service to its local AIP. It provides the requested application
service and a destination name for resolution.
アプリケーション・プロセスは、地方のAIPに対する名前サービスを求める要求をすることによって、対話を開始します。 それは要求されたアプリケーション・サービスと目的地名を解決に提供します。
REQUEST
要求
Command Type Number of Items
項目のコマンド形式数
Service Indicator Length Transport Protocol/Service/Service Type
サービスインディケータ長さのトランスポート・プロトコル/サービス/サービスタイプ
Name Indicator Name Length Name String
名前インディケータ名前長さの名前ストリング
Examples:
例:
1 2 3 13 TCP/SMTP/mail 1 21 Postel@F.ISI.USC.ARPA
1 2 3 13TCP/SMTP/メール1 21 Postel@F.ISI.USC.ARPA
1 2 3 13 TCP/NIFTP/RFT 1 12 TSC.SRI.ARPA
1 2 3 13TCP/NIFTP/RFT1 12TSC.SRI.ARPA
The first example is a resolution request for the name
"Postel@F.ISI.USC.ARPA". It is 21 octets in length. The requested
application service is TCP/SMTP/mail. The second example is a
resolution request for application service NIFTP at TSC.SRI.ARPA.
" Postel@F.ISI.USC.ARPA "という名前を求めて最初の例は解決要求です。 それは長さが21の八重奏です。 要求されたアプリケーション・サービスはTCP/SMTP/メールです。 TSC.SRI.ARPAのアプリケーション・サービスNIFTPを求めて2番目の例は解決要求です。
8
RFC 830 October 1982
8 RFC830 1982年10月
AFFIRMATIVE RESPONSE
肯定的な応答
Command Type Number of Items
項目のコマンド形式数
Service Indicator Length Transport Protocol/Service/Service Type
サービスインディケータ長さのトランスポート・プロトコル/サービス/サービスタイプ
Name Indicator Name Length Name String
名前インディケータ名前長さの名前ストリング
Address Indicator Address Length Address
アドレスインディケータアドレス長さのアドレス
Examples:
例:
2 3 3 13 TCP/SMTP/mail 1 21 Postel@F.ISI.USC.ARPA 2 6 "10 2 0 52 6 25"
2 3 3 13TCP/SMTP/メール1 21 Postel@F.ISI.USC.ARPA 2 6、「10、2 0、52 6 25インチ」
2 4 3 13 TCP/NIFTP/RFT 1 12 TSC.SRI.ARPA 2 6 "10 3 0 2 6 47" 2 6 "39 0 0 5 6 47"
2 4 3 13TCP/NIFTP/RFT1 12TSC.SRI.ARPA2 6、「10、3 0 2 6、47インチ2 6、「39、0 0 5 6、47インチ」
An affirmative response implies that the destination offers the
requested service. The parsing of an address is implied by the
indicated transport protocol. In the first example, the transport
protocol is TCP. Thus, the address is composed of three fields: the
internet address ("10 2 0 52"), the protocol number ("6" for TCP [3]),
and the port number ("25" for SMTP [3]). A multiple-address response in
the second example indicates that TSC is multi-homed via both ARPANET
(net 10), and SRINET (net 39). A multiple-resolution response is
preferred. It offers the source a choice.
肯定的な応答は、目的地が要求されたサービスを提供するのを含意します。 アドレスの構文解析は示されたトランスポート・プロトコルによって含意されます。 最初の例では、トランスポート・プロトコルはTCPです。 したがって、アドレスは3つの分野で構成されます: 数を移植してください。そして、インターネットアドレス、(「10、2 0、52インチ)、プロトコル番号、(「TCP[3])のための6インチ、(「SMTP[3])のための25インチ。」 2番目の例における複数のアドレス応答が、TSCがそうであることを示す、マルチ、家へ帰り、アルパネット(ネットの10)とSRINET(ネットの39)の両方を通して。 複数の解決応答は好まれます。 それは選択をソースに提供します。
NEGATIVE RESPONSE
否定応答
Command Type Number of Items
項目のコマンド形式数
Service Indicator Length Transport Protocol/Service/Service Type
サービスインディケータ長さのトランスポート・プロトコル/サービス/サービスタイプ
Name Indicator Name Length Name String
名前インディケータ名前長さの名前ストリング
Name Indicator Name Length Partial Name String
インディケータ名前の長さを部分的な名前ストリングと命名してください。
[Comment Indicator Comment Length Comment]
[コメントインディケータコメント長さのコメント]
This indicates difficulty in resolution. Returned with this
command is the left-most portion of the specified name including the
difficulty encountered. An optional comment item may be included.
これは解決における困難を示します。 このコマンドと共に返しているのは、包含という困難が遭遇した指定された名前の最も左の部分です。 任意のコメント項目は含まれるかもしれません。
9
RFC 830 October 1982
9 RFC830 1982年10月
Examples:
例:
3 4 3 13 TCP/SMTP/mail 1 16 Postel@F.ISI.USC 1 16 Postel@F.ISI.USC 9 18 Resolution Failure
3 4 3 13TCP/SMTP/メール1 16 Postel@F.ISI.USC 1 16 Postel@F.ISI.USC 9 18解決失敗
3 4 3 13 TCP/NIFTP/RFT 1 13 TSC..SRI.ARPA 1 5 TSC.. 9 17 Syntactic Anomaly
3 4 3 13TCP/NIFTP/RFT1 13TSC。SRI.ARPA1 5TSC。 9 17の構文の異常
In the first example, the resolution failed because USC is not top-level domain. The syntactic error of adajacent dots in the second example is obvious.
最初の例では、USCが最上位のドメインでないので、解決は失敗しました。 2番目の例における、adajacentドットの構文の誤りは明白です。
INCOMPATIBLE SERVICE
両立しないサービス
This response indicates no compatible application and/or transport
service is available at the destination. For example, the requested
application service may be SMTP, while only FTP-mail is available at the
destination. Return with this command is the available corresponding
available service, if any, and its address. If no service is available
for that service type, an empty string for service specification is
returned.
この応答は、コンパチブルアプリケーション、そして/または、どんな輸送サービスも目的地で利用可能でないことを示します。 例えば、要求されたアプリケーション・サービスはSMTPであるかもしれませんが、FTPメールだけが目的地で利用可能です。 いずれかと、そのアドレスであるなら、このコマンドによるリターンは利用可能な対応する利用可能なサービスです。 どんなサービスもそのサービスタイプに利用可能でないなら、サービス仕様のための空のストリングを返します。
Command Type Number of Items
項目のコマンド形式数
Service Indicator Length Transport Protocol/Service/Service Type
サービスインディケータ長さのトランスポート・プロトコル/サービス/サービスタイプ
Name Indicator Name Length Name String
名前インディケータ名前長さの名前ストリング
Service Indicator Length Transport Protocol/Service/Service Type
サービスインディケータ長さのトランスポート・プロトコル/サービス/サービスタイプ
[Address Indicator Address Length Address]
[アドレスインディケータアドレス長さのアドレス]
Examples:
例:
9 3 3 14 TCP/NIFTP/mail 1 21 Postel@F.ISI.USC.ARPA 3 0
9 3 3 14TCP/NIFTP/メール1 21 Postel@F.ISI.USC.ARPA 3 0
9 5 3 13 TCP/NIFTP/RFT 1 12 TSC.SRI.ARPA 3 11 TCP/FTP/RFT 2 6 "10 3 0 2 6 21" 2 6 "39 0 0 5 6 21"
9 5 3 13TCP/NIFTP/RFT1 12TSC.SRI.ARPA3 11TCP/FTP/RFT2 6、「10、3 0 2 6、21インチ2 6、「39、0 0 5 6、21インチ」
10
RFC 830 October 1982
10 RFC830 1982年10月
4.2.2 AIP/AIP Communication
4.2.2 AIP/AIPコミュニケーション
Communication between the AIPs accomplishes the "what-can-you-do-
for-me" negotiation. Examples in this section correspond to those of
Section 4.2.1.
AIPsのコミュニケーションが達成する、「何、-、-、あなた、-、組版をするか、」 交渉できる。 このセクションの例はセクション4.2.1のものに対応しています。
REQUEST
要求
Command Type Number of Items
項目のコマンド形式数
Service Indicator Length Transport Protocol/Service/Service Type
サービスインディケータ長さのトランスポート・プロトコル/サービス/サービスタイプ
Examples:
例:
1 1 3 13 TCP/SMTP/mail
1 1 3 13TCP/SMTP/メール
1 1 3 13 TCP/NIFTP/RFT
1 1 3 13TCP/NIFTP/RFT
AFFIRMATIVE RESPONSE
肯定的な応答
Command Type Number of Items
項目のコマンド形式数
Service Indicator Length Transport Protocol/Service/Service Type
サービスインディケータ長さのトランスポート・プロトコル/サービス/サービスタイプ
Address Indicator Address Length Address
アドレスインディケータアドレス長さのアドレス
Examples:
例:
2 2 3 13 TCP/SMTP/mail 2 6 "10 2 0 52 6 25"
2 2 3 13TCP/SMTP/メール2 6、「10、2 0、52 6 25インチ」
2 3 3 14 TCP/NIFTP/RFT 2 6 "10 3 0 2 6 47" 2 6 "39 0 0 5 6 47"
2 3 3 14TCP/NIFTP/RFT2 6、「10、3 0 2 6、47インチ2 6、「39、0 0 5 6、47インチ」
An affirmative response implies that the destination offers the
same service as that of the originator. A multi-resolution response is
possible. The parsing of an address is implied by the indicated
transport protocol. In the second example, the transport protocol is
TCP. Thus, the address is composed of three fields: the internet
address (10 2 0 52), the protocol number (6 for TCP), and the port
number (25 for SMTP). The returned address(es) is to be relayed to the
originating application process.
肯定的な応答は、目的地が創始者のものと同じサービスを提供するのを含意します。 マルチ解決応答は可能です。 アドレスの構文解析は示されたトランスポート・プロトコルによって含意されます。 2番目の例では、トランスポート・プロトコルはTCPです。 したがって、アドレスは3つの分野で構成されます: インターネットアドレス、(10 52、)プロトコル番号(TCPのための6)、およびポートが達する2 0(SMTPのための25)。 返されたアドレス(es)は起因するアプリケーション・プロセスにリレーされることです。
11
RFC 830 October 1982
11 RFC830 1982年10月
INCOMPATIBLE SERVICE
両立しないサービス
Command Type Number of Items
項目のコマンド形式数
Service Indicator Length Transport Protocol/Service/Service Type
サービスインディケータ長さのトランスポート・プロトコル/サービス/サービスタイプ
Service Indicator Length Transport Protocol/Service/Service Type
サービスインディケータ長さのトランスポート・プロトコル/サービス/サービスタイプ
Address Indicator Address Length Address
アドレスインディケータアドレス長さのアドレス
This response indicates no compatible application and/or transport
service available serving the destination. For example, SMTP may be the
requested application service, while only NIFTP-mail is available
serving the destination. Return with this command is the available
service of that type. If no service available for that service type, a
empty text string is returned.
この応答は目的地に役立つ利用可能なコンパチブルアプリケーション、そして/または、どんな輸送サービスも示しません。 例えば、SMTPは要求されたアプリケーション・サービスであるかもしれませんが、NIFTP-メールだけが、目的地に役立ちながら、利用可能です。 このコマンドによるリターンはそのタイプの利用可能なサービスです。 そのサービスタイプに利用可能なサービスでないなら、空のテキスト文字列を返します。
Examples:
例:
9 2 3 14 TCP/NIFTP/mail 3 0
9 2 3 14TCP/NIFTP/メール3 0
9 4 3 13 TCP/NIFTP/RFT 3 11 TCP/FTP/RFT 2 6 "10 3 0 2 6 21" 2 6 "39 0 0 5 6 21"
9 4 3 13TCP/NIFTP/RFT3 11TCP/FTP/RFT2 6、「10、3 0 2 6、21インチ2 6、「39、0 0 5 6、21インチ」
In the first example, the destination does not offer any kind of mail service. The second example indicates that there is no NIFTP, but FTP available for remote file transfer service at the destination.
最初の例では、目的地はどんな種類のメールサービスも提供しません。 2番目の例は、NIFTPがない、しかし、遠隔ファイル転送サービスに利用可能なFTPが目的地にあるのを示します。
4.2.3 AIP/DNS Communication
4.2.3 AIP/DNSコミュニケーション
The source AIP presents its associated DNS with a fully qualified
domain specification for resolution. The expected resolution result is
the network address for the destination endpoint DNS. We assume no need
for communication between the DNS and AIP at the destination.
ソースAIPは解決のための完全に適切なドメイン仕様を関連DNSに与えます。 予想された解決結果は目的地終点DNSへのネットワーク・アドレスです。 私たちは目的地でDNSとAIPとのコミュニケーションの必要性を全く仮定しません。
REQUEST
要求
Command Type Number of Items
項目のコマンド形式数
Name Indicator Name Length Name String
名前インディケータ名前長さの名前ストリング
Examples:
例:
1 1 1 14 F.ISI.USC.ARPA
1 1 1、14F.ISI.USC.ARPA
1 1 1 12 TSC.SRI.ARPA
1 1 1、12TSC.SRI.ARPA
12
RFC 830 October 1982
12 RFC830 1982年10月
AFFIRMATIVE RESPONSE
肯定的な応答
Command Type Number of Items
項目のコマンド形式数
Name Indicator Name Length Name String
名前インディケータ名前長さの名前ストリング
Service Indicator Service Length Transport Protocol
サービスインディケータサービス長さのトランスポート・プロトコル
Address Indicator Address Length Address
アドレスインディケータアドレス長さのアドレス
Examples:
例:
2 3 1 14 F.ISI.USC.ARPA 3 3 UDP 2 6 "10 2 0 52 17 42"
2 3 1 14F.ISI.USC.ARPA3 3UDP2 6、「10、2 0、52 17、42インチ」
2 4 1 7 TSC.SRI.ARPA 3 3 UDP 2 6 "10 3 0 2 17 42" 2 6 "39 0 0 5 17 42"
2 4 1 7TSC.SRI.ARPA3 3UDP2 6、「10、3 0 2、17、42インチ2 6、「39、0 0 5、17 42インチ」
An affirmative response returns an address of the destination endpoint DNS. This returned address is that of the destination DNS. The destination transport service needs to be indicated for guiding the parsing of the destination address.
肯定的な応答は目的地終点DNSのアドレスを返します。 この返されたアドレスは目的地DNSのものです。 目的地輸送サービスは、送付先アドレスの構文解析を誘導するために示される必要があります。
NEGATIVE RESPONSE
否定応答
Command Type Number of Items
項目のコマンド形式数
Name Indicator Name Length Name String
名前インディケータ名前長さの名前ストリング
Name Indicator Name Length Partial Name String
インディケータ名前の長さを部分的な名前ストリングと命名してください。
[Comment Indicator Comment Length Comment]
[コメントインディケータコメント長さのコメント]
This response indicates that the domain name service is unable to
resolve the given destination domain name. It could be caused by an
unknown simple name, which may result from, for example, misspelling.
Returned with this command is the left-most portion of the specified
name containing the cause of resolution failure.
この応答は、ドメイン名サービスが与えられた目的地ドメイン名を決議できないのを示します。 それは未知の単純名によって引き起こされる場合がありました。(それは、例えばスペルミスから生じるかもしれません)。 このコマンドと共に返しているのは、解決失敗の原因を含む指定された名前の最も左の部分です。
Example:
例:
1 3
1 9 F.ISI.USC
1 9 F.ISI.USC
9 18 Resolution Failure
1 3 1 9F.ISI.USC1 9F.ISI.USC9 18解決失敗
13
RFC 830 October 1982
13 RFC830 1982年10月
4.2.4 DNS/DNS Communication
4.2.4 DNS/DNSコミュニケーション
The domain name service is an application independent network
service. It provides the resolution of domain names. For the
specification of this service the reader is referred to [2].
ドメイン名サービスはアプリケーションの独立しているネットワーク・サービスです。 それはドメイン名の解決を提供します。 このサービスの仕様について、読者は[2]を参照されます。
4.3 Transport Protocol
4.3 トランスポート・プロトコル
For generality, this specification is intentionally transport
protocol independent. Implications for the use of TCP and UDP are
specifically considered.
一般性において、この仕様は故意にトランスポート・プロトコルから独立しています。 TCPとUDPの使用のための含意は明確に考えられます。
Typically, for distributed name service a server A makes a request
to a server B, server B may need to in turn contact other servers to
complete a resolution. TCP is a connection-oriented protocol. It
offers reliable transport, but also imposes certain amount of overhead
for connection establishment and maintenance. For most cases, the use
of TCP is not recommended.
サーバAがサーバBへの要求を出す分配された名前サービスに、通常、サーバBは、解決を終了するために順番に他のサーバに連絡する必要があるかもしれません。 TCPは接続指向のプロトコルです。 それは、コネクション確立とメインテナンスのために信頼できる輸送を提供しますが、ある量のオーバーヘッドをまた課します。 ほとんどのケースにおいて、TCPの使用は推薦されません。
UDP is a datagram service offering a transport capacity per
datagram in excess of 500 octets. Such capacity should suffice most
conceivable commands within this specification. However, it does impose
a limit on the total length of a command. In order to enhance
reliability, the request is incorporated as part of every response
command.
UDPはデータグラムより多くの500八重奏あたり1つの輸送能力を提供するデータグラムサービスです。 そのような容量はこの仕様の中の想像できるほとんどのコマンドを満足させるべきです。 しかしながら、それはコマンドの全長で指し値します。 信頼性を高めるために、要求はあらゆる応答命令の一部として法人組織です。
5 NCP TO TCP TRANSITION
TCP変遷への5NCP
The Internet Naming Convention, "<user>@<domain>. ... . <domain>"
[1], is a generalization of "<user>@<host>", the ARPANET Naming
Convention. It is a generalization in the sense that the ARPANET Naming
Convention can be considered as a partially qualified form of the subset
"<user>@<host>.ARPANET". (We assume here ARPANET is a top-level domain
name.)
インターネット命名規則、「<ユーザ>@<ドメイン>。」 ... . 「<ドメイン>」[1]は「<ユーザ>@<ホスト>」の一般化であり、アルパネットはNaming Conventionです。 それは部分集合「<ユーザ>@<ホスト>.ARPANET」の部分的に適切なフォームであるとアルパネットNaming Conventionをみなすことができるという意味で一般化です。 (私たちは、ここでアルパネットが最上位のドメイン名であると思います。)
For the transition from NCP to TCP, we may initially treat each
host name entry in the current host table as a subdomain of the top-
level domain ARPANET. Thus, initially there would be a very flat domain
structure. This structure can be gradually changed after the transition
toward a hierarchical structure when more and more domains and
subdomains are defined and name servers installed. In the process of
this change, the host table would be gradually converted into
distributed domain tables (databases). For the newly created domain
tables, no standard format would be required. Each individual domain
table may have its own format suitable to the design of its associated
domain name server.
NCPからTCPまでの変遷のために、私たちは初めは、先端の平らなドメインアルパネットに関するサブドメインとして現在のホストテーブルでそれぞれのホスト名エントリーを扱うかもしれません。 このようにして、そして、初めは、非常に平坦なドメイン構造があるでしょう。 ますます多くのドメインとサブドメインが定義されて、ネームサーバがインストールされたとき、この構造は変遷の後に徐々に階層構造に向かって変わることができます。 この変化の途中に、ホストテーブルは徐々に分配されたドメインテーブル(データベース)に変換されるでしょう。 新たに作成されたドメインテーブルに関しては、標準書式は全く必要でないでしょう。 それぞれの個々のドメインテーブルで、それ自身の形式は関連ドメイン名サーバの設計に適するようになるかもしれません。
14
RFC 830 October 1982
14 RFC830 1982年10月
REFERENCES
参照
[1] Su, Z. and J. Postel, "The Domain Naming Convention for Internet User Applications," RFC 819, SRI International (August 1982).
[1]SuとZ.とJ.ポステル、「インターネットユーザアプリケーションのためのドメイン命名規則」、RFC819、SRIインターナショナル(1982年8月)。
[2] Postel, J., "Domains Name Server," RFC XXX, USC/Information Sciences Institute (to appear).
[2] ポステル、J.、「ドメインネームサーバ」、RFC XXX、USC/情報Sciences Institute(現れる)。
[3] Postel, J., "Assigned Numbers," RFC 790, USC/Information Sciences Institute (September 1981).
[3] ポステル、J.、「規定番号」、RFC790、USC/情報科学は(1981年9月)を設けます。
15
RFC 830 October 1982
15 RFC830 1982年10月
Appendix A
付録A
CONVENTION ASSIGNMENTS
コンベンション課題
Command Types
コマンドタイプ
Request 1
Affirmative Response 2
Negative Response 3
Imcompatible Service 9
要求1肯定的な応答2否定応答3Imcompatibleサービス9
INDICATORS
インディケータ
Name Indicator 1
Address Indicator 2
Service Indicator 3
Comment Indicator 9
名前インディケータ1アドレスインディケータ2サービスインディケータ3コメントインディケータ9
TRANSPORT PROTOCOLS: TCP, UDP, NCP
プロトコルを輸送してください: TCP、UDP、NCP
SERVICES
サービス
Service Protocols Service Type
プロトコルサービスがタイプするサービス
MTP mail
SMTP mail
FTP (FTP mail) mail
NIFTP (NIFTP mail) mail
MMDF mail
MTPメールSMTPメールFTP(FTPメール)メールNIFTP(NIFTPメール)メールMMDFメール
FTP RFT (remote file transfer)
FTP RFT(遠隔ファイル転送)
Telnet RTA (remote terminal access)
telnet RTA(遠隔端末アクセス)
16
16
一覧
スポンサーリンク
