RFC819 日本語訳
0819 Domain naming convention for Internet user applications. Z. Su,J. Postel. August 1982. (Format: TXT=35314 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Zaw-Sing Su (SRI)
Request for Comments: 819 Jon Postel (ISI)
August 1982
Zaw歌っているSu(様)がコメントのために要求するワーキンググループをネットワークでつないでください: 819 ジョン・ポステル(ISI)1982年8月
The Domain Naming Convention for Internet User Applications
インターネットユーザアプリケーションのためのドメイン命名規則
1. Introduction
1. 序論
For many years, the naming convention "<user>@<host>" has served the ARPANET user community for its mail system, and the substring "<host>" has been used for other 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. A decision has recently been reached to replace the simple name field, "<host>", by a composite name field, "<domain>" [2]. This note is an attempt to clarify this generalized naming convention, the Internet Naming Convention, and to explore the implications of its adoption for Internet name service and user applications.
何年間も、命名規則「<ユーザ>@<ホスト>」はメールシステムのためのアルパネットユーザーコミュニティに役立っています、そして、サブストリング「<ホスト>」はファイル転送(FTP)と端末のアクセス(telnet)などの他の応用に使用されました。 ネットワーク相互接続の到来で、この命名規則は、インターネットワーキングを収容するために一般化される必要があります。 決定に、最近、単純名分野、「<ホスト>」を合成名前欄、「<ドメイン>」[2]に取り替えるために達しました。 この注意はコンベンション、インターネットをNaming Conventionと命名しながら一般化されたこれをはっきりさせて、インターネット名前サービスとユーザアプリケーションへの採用の含意を探る試みです。
The following example illustrates the changes in naming convention:
以下の例は命名規則における変化を例証します:
ARPANET Convention: Fred@ISIF
Internet Convention: Fred@F.ISI.ARPA
アルパネットコンベンション: Fred@ISIF インターネットコンベンション: Fred@F.ISI.ARPA
The intent is that the Internet names be used to form a tree-structured administrative dependent, rather than a strictly topology dependent, hierarchy. The left-to-right string of name components proceeds from the most specific to the most general, that is, the root of the tree, the administrative universe, is on the right.
意図はインターネット名が厳密にaよりむしろ木で構造化された管理扶養家族を形成するのに使用されるということです。トポロジー扶養家族(階層構造)。 左から右への名前コンポーネントのストリングは最も特定であるのから最も多くの一般まで続きます、すなわち、木の根(管理宇宙)が右にあります。
The name service for realizing the Internet naming convention is assumed to be application independent. It is not a part of any particular application, but rather an independent name service serves different user applications.
インターネット命名規則がわかるための名前サービスはアプリケーション独立者であると思われます。 それはどんな特定用途の一部ではありませんがも、むしろ独立している名前サービスは異なったユーザアプリケーションに役立ちます。
2. The Structural Model
2. 構造モデル
The Internet naming convention is based on the domain concept. The name of a domain consists of a concatenation of one or more <simple names>. A domain can be considered as a region of jurisdiction for name assignment and of responsibility for name-to-address translation. The set of domains forms a hierarchy.
インターネット命名規則はドメイン概念に基づいています。 ドメインの名前は1<単純名>の連結から成ります。 名前課題のための管轄と名前からアドレス変換への責任の範囲であるとドメインをみなすことができます。 ドメインのセットは階層構造を形成します。
Using a graph theory representation, this hierarchy may be modeled as a directed graph. A directed graph consists of a set of nodes and a
グラフ理論表現を使用して、この階層構造は有向グラフとしてモデル化されるかもしれません。 有向グラフは1セットのノードとaから成ります。
Su & Postel [Page 1]
Suとポステル[1ページ]
RFC 819 August 1982;
RFC819 1982年8月。
collection of arcs, where arcs are identified by ordered pairs of distinct nodes [1]. Each node of the graph represents a domain. An ordered pair (B, A), an arc from B to A, indicates that B is a subdomain of domain A, and B is a simple name unique within A. We will refer to B as a child of A, and A a parent of B. The directed graph that best describes the naming hierarchy is called an "in-tree", which is a rooted tree with all arcs directed towards the root (Figure 1). The root of the tree represents the naming universe, ancestor of all domains. Endpoints (or leaves) of the tree are the lowest-level domains.
アークの収集。そこでは、アークが順序対の異なったノード[1]によって特定されます。 グラフの各ノードはドメインを表します。 1順序対(B、A)(BからAまでのアーク)がBがドメインAに関するサブドメインであり、BがAの子供としてBへのWeが参照するA.の中でユニークな単純名であることを示して、B. 命名階層構造について最もよく説明する有向グラフのA a親が呼ばれる、「木」、すべてのアークが根(図1)に向けられている根づいている木である。 木の根は命名宇宙を表して、すべての先祖はドメインです。 木の終点(または、いなくなる)は最も低いレベルドメインです。
U
/ | \
/ | \ U -- Naming Universe
^ ^ ^ I -- Intermediate Domain
| | | E -- Endpoint Domain
I E I
/ \ |
^ ^ ^
| | |
E E I
/ | \
^ ^ ^
| | |
E E E
U/| \ / | \U--宇宙^ ^ ^Iを命名します--中間的ドメイン| | | E--終点ドメインI E I/\| ^ ^ ^ | | | E E I/| \ ^ ^ ^ | | | E E E
Figure 1
The In-Tree Model for Domain Hierarchy
図1 ドメイン階層構造のための木のモデル
The simple name of a child in this model is necessarily unique within its parent domain. Since the simple name of the child's parent is unique within the child's grandparent domain, the child can be uniquely named in its grandparent domain by the concatenation of its simple name followed by its parent's simple name.
このモデルという子供の単純名は必ず親ドメインの中でユニークです。 子供の親の単純名が子供の祖父のドメインの中でユニークであるので、祖父のドメインで親の単純名があとに続いた単純名の連結で唯一子供を命名できます。
For example, if the simple name of a child is "C1" then no other
child of the same parent may be named "C1". Further, if the
parent of this child is named "P1", then "P1" is a unique simple
name in the child's grandparent domain. Thus, the concatenation
C1.P1 is unique in C1's grandparent domain.
子供の単純名が例えばそうである、「同じ親のC1"の当時のノー他の子供は"C1""と命名されるかもしれません。 この子供の親が命名されるなら促進する、「P1"、そして、「P1"は子供の祖父のドメインのユニークな単純名です」。 したがって、連結C1.P1はC1の祖父のドメインでユニークです。
Similarly, each element of the hierarchy is uniquely named in the universe by its complete name, the concatenation of its simple name and those for the domains along the trail leading to the naming universe.
同様に、階層構造の各原理は宇宙の中で完全な名前、命名宇宙に通じる道に沿ったドメインへの単純名とそれらの連結で唯一命名されます。
The hierarchical structure of the Internet naming convention supports decentralization of naming authority and distribution of name service capability. We assume a naming authority and a name server
インターネット命名規則の階層構造は名前サービスの権威と分配を能力と命名する分散をサポートします。 私たちは、命名が権威とネームサーバであると思います。
Su & Postel [Page 2]
Suとポステル[2ページ]
RFC 819 August 1982;
RFC819 1982年8月。
associated with each domain. In Sections 5 and 6 respectively the name service and the naming authority are discussed.
各ドメインに関連しています。 セクション5と6では、それぞれ名前サービスと命名権威について議論します。
Within an endpoint domain, unique names are assigned to <user> representing user mailboxes. User mailboxes may be viewed as children of their respective domains.
終点ドメインの中では、ユニークな名前はユーザメールボックスを表す<ユーザ>に割り当てられます。 ユーザメールボックスは彼らのそれぞれのドメインの子供として見なされるかもしれません。
In reality, anomalies may exist violating the in-tree model of naming hierarchy. Overlapping domains imply multiple parentage, i.e., an entity of the naming hierarchy being a child of more than one domain. It is conceivable that ISI can be a member of the ARPA domain as well as a member of the USC domain (Figure 2). Such a relation constitutes an anomaly to the rule of one-connectivity between any two points of a tree. The common child and the sub-tree below it become descendants of both parent domains.
ほんとうは、例外は、木の命名階層構造のモデルに違反しながら、存在するかもしれません。 重なっているドメインは複数の生まれ、すなわち、1つ以上のドメインの子供である命名階層構造の実体を含意します。 ISIがARPAドメインのメンバーとUSCドメイン(図2)のメンバーであるかもしれないことは想像できます。 そのような関係は木のどんな2の間の1接続性のポイントの規則に異常を構成します。 一般的な子供とそれの下の下位木は両方の親ドメインの子孫になります。
U
/ | \
/ . \
. . ARPA
. . | \
USC | \
\ | .
\ | .
ISI
U/| \/\アルパ。| \USC| \ \ | . \ | . ISI
Figure 2
Anomaly in the In-Tree Model
図2 木のモデルの異常
Some issues resulting from multiple parentage are addressed in Appendix B. The general implications of multiple parentage are a subject for further investigation.
複数の生まれから生じるいくつかの問題がAppendix B.で扱われます。複数の生まれの一般的な含意はさらなる調査のための対象です。
3. Advantage of Absolute Naming
3. 絶対命名の利点
Absolute naming implies that the (complete) names are assigned with respect to a universal reference point. The advantage of absolute naming is that a name thus assigned can be universally interpreted with respect to the universal reference point. The Internet naming convention provides absolute naming with the naming universe as its universal reference point.
絶対命名は、(完全)の名前が普遍的な基準点に関して割り当てられるのを含意します。 絶対命名の利点は普遍的な基準点に関して一般にこのようにして割り当てられた名前を解釈できるということです。 インターネット命名規則は普遍的な基準点として命名宇宙を絶対命名に提供します。
For relative naming, an entity is named depending upon the position of the naming entity relative to that of the named entity. A set of hosts running the "unix" operating system exchange mail using a method called "uucp". The naming convention employed by uucp is an example of relative naming. The mail recipient is typically named by a source route identifying a chain of locally known hosts linking the
相対的な命名にちなんで、実体は命名された実体のものに比例して命名実体の位置によると命名されます。 メソッドを使用することで「unix」オペレーティングシステム交換メールを実行する1セットのホストは、"uucp"と呼びました。 uucpによって使われた命名規則は相対的な命名に関する例です。 メール受取人は局所的に知られることのチェーンがリンクしながら接待する送信元経路特定で通常命名されます。
Su & Postel [Page 3]
Suとポステル[3ページ]
RFC 819 August 1982;
RFC819 1982年8月。
sender's host to the recipient's. A destination name can be, for example,
送付者の受取人のホスト。 例えば、目的地名があることができます。
"alpha!beta!gamma!john",
「アルファ!ベータ!ガンマ!john」
where "alpha" is presumably known to the originating host, "beta" is known to "alpha", and so on.
おそらく、「アルファ」が送信元ホストにとって知られているところでは、「ベータ」は「アルファ」などに知られています。
The uucp mail system has demonstrated many of the problems inherent to relative naming. When the host names are only locally interpretable, routing optimization becomes impossible. A reply message may have to traverse the reverse route to the original sender in order to be forwarded to other parties.
uucpメールシステムは相対的な命名に固有の問題の多くを示しました。 ホスト名が局所的にだけ解明できるとき、ルーティング最適化は不可能になります。 応答メッセージは、相手に送るために逆のルートを元の送り主に横断しなければならないかもしれません。
Furthermore, if a message is forwarded by one of the original recipients or passed on as the text of another message, the frame of reference of the relative source route can be completely lost. Such relative naming schemes have severe problems for many of the uses that we depend upon in the ARPA Internet community.
その上、メッセージがオリジナルの受取人のひとりによって転送されるか、または別のメッセージのテキストとして伝えられるなら、相対的な送信元経路の基準系は完全に失われる場合があります。 そのような相対的な命名体系には、私たちがARPAインターネットコミュニティで当てにする用途の多くの厳しい問題があります。
4. Interoperability
4. 相互運用性
To allow interoperation with a different naming convention, the names assigned by a foreign naming convention need to be accommodated. Given the autonomous nature of domains, a foreign naming environment may be incorporated as a domain anywhere in the hierarchy. Within the naming universe, the name service for a domain is provided within that domain. Thus, a foreign naming convention can be independent of the Internet naming convention. What is implied here is that no standard convention for naming needs to be imposed to allow interoperations among heterogeneous naming environments.
異なった命名規則を伴うinteroperationを許容するために、外国命名規則によって割り当てられた名前は、設備される必要があります。 ドメインの自治の本質を考えて、外国命名環境は階層構造でどこでもドメインとして法人組織であるかもしれません。 命名宇宙の中では、そのドメインの中でドメインのための名前サービスを提供します。 したがって、外国命名規則はインターネット命名規則から独立している場合があります。 ここで含意されることは命名のためのどんな一般的なコンベンションも、異種の命名環境の中にinteroperationsを許容するために課される必要がないということです。
For example:
例えば:
There might be a naming convention, say, in the FOO world,
something like "<user>%<host>%<area>". Communications with an
entity in that environment can be achieved from the Internet
community by simply appending ".FOO" on the end of the name in
that foreign convention.
命名規則はたとえばFOO世界で「<ユーザ>%<は>%<領域>を接待すること」に似るかもしれません。 インターネットコミュニティから名前の終わりにその外国コンベンションで単に".FOO"を追加することによって、その環境における実体とのコミュニケーションを達成できます。
John%ISI-Tops20-7%California.FOO
ジョン%ISI-Tops20-7%California.FOO
Another example:
別の例:
One way of accommodating the "uucp world" described in the last
section is to declare it as a foreign system. Thus, a uucp
name
最後のセクションで説明された「uucp世界」を収容する1つの方法は外国システムとしてそれを宣言することです。 その結果、uucp名
"alpha!beta!gamma!john"
「アルファ!ベータ!ガンマ!john」
Su & Postel [Page 4]
Suとポステル[4ページ]
RFC 819 August 1982;
RFC819 1982年8月。
might be known in the Internet community as
インターネットコミュニティで知られているかもしれません。
"alpha!beta!gamma!john.UUCP".
「アルファ!ベータ!ガンマ!john.UUCP。」
Communicating with a complex subdomain is another case which can
be treated as interoperation. A complex subdomain is a domain
with complex internal naming structure presumably unknown to the
outside world (or the outside world does not care to be concerned
with its complexity).
複雑なサブドメインで交信するのは、interoperationとして扱うことができる別のケースです。 複雑なサブドメインはおそらく、外の世界における、未知の複雑な内部の命名構造があるドメイン(外の世界は、複雑さに関係があるのを気にかけない)です。
For the mail system application, the names embedded in the message text are often used by the destination for such purpose as to reply to the original message. Thus, the embedded names may need to be converted for the benefit of the name server in the destination environment.
メールシステム応用において、メッセージ・テキストに埋め込まれた名前はそのような目的に目的地によってしばしばオリジナルのメッセージに答えるほど使用されます。 したがって、埋め込まれた名前は、目的地環境における、ネームサーバの利益のために変換される必要があるかもしれません。
Conversion of names on the boundary between heterogeneous naming environments is a complex subject. The following example illustrates some of the involved issues.
異種の命名環境の間の境界における名前の変換は複雑な問題です。 以下の例はかかわった問題のいくつかを例証します。
For example:
例えば:
A message is sent from the Internet community to the FOO
environment. It may bear the "From" and "To" fields as:
インターネットコミュニティからFOO環境にメッセージを送ります。 それは以下として“From"と“To"に分野に堪えるかもしれません。
From: Fred@F.ISI.ARPA
To: John%ISI-Tops20-7%California.FOO
From: Fred@F.ISI.ARPA To: ジョン%ISI-Tops20-7%California.FOO
where "FOO" is a domain independent of the Internet naming
environment. The interface on the boundary of the two
environments may be represented by a software module. We may
assume this interface to be an entity of the Internet community
as well as an entity of the FOO community. For the benefit of
the FOO environment, the "From" and "To" fields need to be
modified upon the message's arrival at the boundary. One may
view naming as a separate layer of protocol, and treat
conversion as a protocol translation. The matter is
complicated when the message is sent to more than one
destination within different naming environments; or the
message is destined within an environment not sharing boundary
with the originating naming environment.
"FOO"が環境を命名するインターネットの如何にかかわらずドメインであるところ。 2つの環境を境としたインタフェースはソフトウェア・モジュールで表されるかもしれません。 私たちは、このインタフェースがFOO共同体の実体と同様にインターネットコミュニティの実体であると思うかもしれません。 FOO環境の利益のために、“From"と“To"分野は、境界へのメッセージの到着のときに変更される必要があります。 別々の層のプロトコルであると命名をみなして、プロトコル変換として変換を扱うかもしれません。 異なった命名環境の中で1つ以上の目的地にメッセージを送るとき、その問題は複雑です。 または、メッセージは、環境を命名する起因すると境界を共有しないことで環境の中で運命づけられています。
While the general subject concerning conversion is beyond the scope of this note, a few questions are raised in Appendix D.
変換に関する一般的な対象がこの注意の範囲を超えている間、いくつかの疑問がAppendix Dで引き起こされます。
Su & Postel [Page 5]
Suとポステル[5ページ]
RFC 819 August 1982;
RFC819 1982年8月。
5. Name Service
5. 名前サービス
Name service is a network service providing name-to-address translation. Such service may be achieved in a number of ways. For a simple networking environment, it can be accomplished with a single central database containing name-to-address correspondence for all the pertinent network entities, such as hosts.
名前サービスは名前からアドレス変換を提供するネットワーク・サービスです。 そのようなサービスは多くの方法で達成されるかもしれません。 簡単なネットワーク環境において、ただ一つの主要なデータベースが名前からアドレスへの通信を含んでいて、すべての適切なネットワーク実体のためにそれを達成できます、ホストなどのように。
In the case of the old ARPANET host names, a central database is duplicated in each individual host. The originating module of an application process would query the local name service (e.g., make a system call) to obtain network address for the destination host. With the proliferation of networks and an accelerating increase in the number of hosts participating in networking, the ever growing size, update frequency, and the dissemination of the central database makes this approach unmanageable.
古いアルパネットホスト名の場合では、主要なデータベースはそれぞれの個々のホストにコピーされます。 アプリケーション・プロセスの起因するモジュールは、ネットワーク・アドレスをあて先ホストに得るために、地方名サービス(例えば、システムコールをする)について質問するでしょう。 ネットワークの増殖とホストの数の加速増加がネットワークに参加している状態で、このアプローチは主要なデータベースのかつて増加しているサイズ、アップデート頻度、および普及によって「非-処理しやす」されます。
The hierarchical structure of the Internet naming convention supports decentralization of naming authority and distribution of name service capability. It readily accommodates growth of the naming universe. It allows an arbitrary number of hierarchical layers. The addition of a new domain adds little complexity to an existing Internet system.
インターネット命名規則の階層構造は名前サービスの権威と分配を能力と命名する分散をサポートします。 それは容易に命名宇宙の成長に対応します。 それは階層的な層の特殊活字の数字を許容します。 新しいドメインの追加はほとんど既存のインターネット・システムに複雑さを追加しません。
The name service at each domain is assumed to be provided by one or more name servers. There are two models for how a name server completes its work, these might be called "iterative" and "recursive".
1つ以上のネームサーバによって各ドメインでの名前サービスが提供されると思われます。 ネームサーバがどう仕事を終了するか2つのモデルがあって、これらは呼ぶかもしれません。「繰り返し的であって、再帰的である」と呼ばれてください。
For an iterative name server there may be two kinds of responses.
The first kind of response is a destination address. The second
kind of response is the address of another name server. If the
response is a destination address, then the query is satisfied. If
the response is the address of another name server, then the query
must be repeated using that name server, and so on until a
destination address is obtained.
繰り返しのネームサーバのために、2種類の応答があるかもしれません。 最初の種類の応答は送付先アドレスです。 2番目の種類の応答は別のネームサーバのアドレスです。応答が送付先アドレスであるなら、質問は満たされています。 応答が別のネームサーバのアドレスであるなら、そのネームサーバなどを使用することで送付先アドレスを得るまで質問を繰り返さなければなりません。
For a recursive name server there is only one kind of response --
a destination address. This puts an obligation on the name server
to actually make the call on another name server if it can't
answer the query itself.
再帰的なネームサーバのために、1種類の応答しかありません--送付先アドレス。 質問自体に答えることができないなら、これは、実際に別のネームサーバで電話をかけるために義務をネームサーバに置きます。
It is noted that looping can be avoided since the names presented for translation can only be of finite concatenation. However, care should be taken in employing mechanisms such as a pointer to the next simple name for resolution.
翻訳のために提示された名前が有限連結のものであることができるだけであるのでループを避けることができることに注意されます。 しかしながら、解決に次の単純名への指針などのメカニズムを使うことで注意を中に入れるべきです。
We believe that some name servers will be recursive, but we don't believe that all will be. This means that the caller must be
いくつかのネームサーバが再帰的になると信じていますが、私たちは、すべてがそうになると信じていません。 これは、訪問者がそうであるに違いないことを意味します。
Su & Postel [Page 6]
Suとポステル[6ページ]
RFC 819 August 1982;
RFC819 1982年8月。
prepared for either type of server. Further discussion and examples of name service is given in Appendix C.
用意をして、サーバさらなる議論のタイプと名前サービスの例はAppendix Cで出されます。
The basic name service at each domain is the translation of simple names to addresses for all of its children. However, if only this basic name service is provided, the use of complete (or fully qualified) names would be required. Such requirement can be unreasonable in practice. Thus, we propose the use of partial names in the context in which their uniqueness is preserved. By construction, naming uniqueness is preserved within the domain of a common ancestry. Thus, a partially qualified name is constructed by omitting from the complete name ancestors common to the communicating parties. When a partially qualified name leaves its context of uniqueness it must be additionally qualified.
各ドメインでの基本的な名前サービスは子供のすべてのためのアドレスへの単純名に関する翻訳です。 しかしながら、この基本的な名前サービスだけを提供するなら、完全で(完全に適切)の名前の使用を必要とするでしょう。 そのような要件は実際には無理である場合があります。 したがって、私たちはそれらのユニークさが保存される文脈における部分的な名前の使用を提案します。 工事で、ユニークさを命名するのは共通の先祖のドメインの中に保存されます。 したがって、部分的に適切な名前は、先祖という交信に共通の完全な名前からパーティーを省略することによって、構成されます。 部分的に適切な名前がユニークさの文脈を残すとき、さらに、それに資格がなければなりません。
The use of partially qualified names places a requirement on the Internet name service. To satisfy this requirement, the name service at each domain must be capable of, in addition to the basic service, resolving simple names for all of its ancestors (including itself) and their children. In Appendix B, the required distinction among simple names for such resolution is addressed.
部分的に適切な名前の使用はサービスというインターネット名に要件を置きます。 この要件を満たすために、基本サービスに加えて、各ドメインでの名前サービスは先祖(それ自体を含んでいます)と彼らの子供のすべてにおいて単純名を決議できなければなりません。 Appendix Bでは、そのような解決のための単純名の中の必要な区別は記述されます。
6. Naming Authority
6. 権威を命名します。
Associated with each domain there must be a naming authority to assign simple names and ensure proper distinction among simple names.
そこで各ドメインに関連づけられているのは、単純名を割り当てて、単純名の中で適切な区別を確実にする命名権威であるに違いありません。
Note that if the use of partially qualified names is allowed in a sub-domain, the uniqueness of simple names inside that sub-domain is insufficient to avoid ambiguity with names outside the subdomain. Appendix B discusses simple name assignment in a sub-domain that would allow the use of partially qualified names without ambiguity.
部分的に適切な名前の使用がサブドメインで許されているなら、そのサブドメインにおける単純名のユニークさがサブドメインの外における名前であいまいさを避けるためには不十分であることに注意してください。 付録Bはあいまいさのない部分的に適切な名前の使用を許すサブドメインにおける単純名課題について議論します。
Administratively, associated with each domain there is a single person (or office) called the registrar. The registrar of the naming universe specifies the top-level set of domains and designates a registrar for each of these domains. The registrar for any given domain maintains the naming authority for that domain.
行政上、そこで各ドメインに関連づけられているのは、記録係と呼ばれる1人の人(または、オフィス)です。 命名宇宙の記録係は、最高レベル集合のドメインを指定して、それぞれのこれらのドメインに記録係を任命します。 どんな与えられたドメインへの記録係もそのドメインに命名権威を維持します。
7. Network-Oriented Applications
7. ネットワーク指向のアプリケーション
For user applications such as file transfer and terminal access, the remote host needs to be named. To be compatible with ARPANET naming convention, a host can be treated as an endpoint domain.
ファイル転送や端末のアクセスなどのユーザ応用のために、リモートホストは、命名される必要があります。 アルパネット命名規則と互換性があるように、終点ドメインとしてホストを扱うことができます。
Many operating systems or programming language run-time environments provide functions or calls (JSYSs, SVCs, UUOs, SYSs, etc.) for standard services (e.g., time-of-day, account-of-logged-in-user, convert-number-to-string). It is likely to be very helpful if such a
多くのオペレーティングシステムかプログラミング言語ランタイム環境が標準のサービス(例えば、時刻、ログインされたユーザのアカウント、結ぶ転向者番号)のための機能か要求(JSYSs、SVCs、UUOs、SYSsなど)を提供します。 それは非常に役立っていますが、そのようなaである傾向があります。
Su & Postel [Page 7]
Suとポステル[7ページ]
RFC 819 August 1982;
RFC819 1982年8月。
function or call is developed for translating a host name to an address. Indeed, several systems on the ARPANET already have such facilities for translating an ARPANET host name into an ARPANET address based on internal tables.
機能か呼び出しが、ホスト名をアドレスに翻訳するために開発されます。 本当に、アルパネットの数個のシステムには、内部のテーブルに基づくアルパネットアドレスにアルパネットホスト名を翻訳するためのそのような施設が既にあります。
We recommend that this provision of a standard function or call for translating names to addresses be extended to accept names of Internet convention. This will promote a consistent interface to the users of programs involving internetwork activities. The standard facility for translating Internet names to Internet addresses should include all the mechanisms available on the host, such as checking a local table or cache of recently checked names, or consulting a name server via the Internet.
私たちは、名前をアドレスに翻訳するための標準関数か呼び出しのこの支給がインターネットコンベンションの名前を受け入れるために広げられることを勧めます。 これはインターネットワーク活動にかかわるプログラムのユーザに一貫したインタフェースを促進するでしょう。 インターネット名をインターネット・アドレスに翻訳するための標準の施設はホストで利用可能なすべてのメカニズムを含んでいるはずです、最近チェックの名前の地方のテーブルかキャッシュをチェックするか、またはインターネットを通してネームサーバに相談するのなどように。
8. Mail Relaying
8. リレーを郵送してください。
Relaying is a feature adopted by more and more mail systems. Relaying facilitates, among other things, interoperations between heterogeneous mail systems. The term "relay" is used to describe the situation where a message is routed via one or more intermediate points between the sender and the recipient. The mail relays are normally specified explicitly as relay points in the instructions for message delivery. Usually, each of the intermediate relays assume responsibility for the relayed message [3].
リレーはシステムリレーが特に容易にするますます多くのメールによって採用された特徴です、異種のメールシステムの間のinteroperations。「リレー」という用語は、メッセージが送付者と受取人の間の中間的1ポイント以上で発送される状況について説明するのに使用されます。 通常、メール中継はリレーポイントとしてメッセージ配送のための指示で明らかに指定されます。 通常、それぞれの中間的リレーはリレーされたメッセージ[3]への責任を負います。
A point should be made on the basic difference between mail
relaying and the uucp naming system. The difference is that
although mail relaying with absolute naming can also be considered
as a form of source routing, the names of each intermediate points
and that of the destination are universally interpretable, while
the host names along a source route of the uucp convention is
relative and thus only locally interpretable.
ポイントはメールリレーとuucp命名システムの基本的な違いで指摘されるべきです。 また、絶対命名によるメールリレーがソースルーティングのフォーム、それぞれの中間的名前であるとみなされて、目的地のポイントとものは一般に解明できます、ホストがずっとuucpコンベンションの送信元経路を命名しますがことであるかもしれませんが、相対的でその結果局所的にだけ解明できる違いは、あります。
The Internet naming convention explicitly allows interoperations among heterogeneous systems. This implies that the originator of a communication may name a destination which resides in a foreign system. The probability is that the destination network address may not be comprehensible to the transport system of the originator. Thus, an implicit relaying mechanism is called for at the boundary between the domains. The function of this implicit relay is the same as the explicit relay.
インターネット命名規則は多相系の中に明らかにinteroperationsを許容します。これは、コミュニケーションの創始者が存する目的地を外国システムと命名するかもしれないのを含意します。 確率は目的地ネットワーク・アドレスが創始者の輸送システムに分かりやすくないかもしれないということです。 したがって、内在しているリレーメカニズムはドメインの間の境界で求められます。 この内在しているリレーの機能は明白なリレーと同じです。
Su & Postel [Page 8]
Suとポステル[8ページ]
RFC 819 August 1982;
RFC819 1982年8月。
9. Implementation
9. 実現
The Actual Domains
実際のドメイン
The initial set of top-level names include:
トップレベル名の始発は:
ARPA
アルパ
This represents the set of organizations involved in the
Internet system through the authority of the U.S. Defense
Advanced Research Projects Agency. This includes all the
research and development hosts on the ARPANET and hosts on
many other nets as well. But note very carefully that the
top-level domain "ARPA" does not map one-to-one with the
ARPANET -- domains are administrative, not topological.
これは国防総省防衛先端技術研究計画局の権威を通してインターネット・システムにかかわる組織のセットを表します。 これはアルパネットのすべての研究開発ホストとまた、他の多くのネットのホストを含んでいます。 しかし、最上位のドメイン「アルパ」がアルパネットで1〜1つを写像しないことに非常に慎重に注意してください--ドメインは位相的であるのではなく、管理です。
Transition
変遷
In the transition from the ARPANET naming convention to the
Internet naming convention, a host name may be used as a simple
name for an endpoint domain. Thus, if "USC-ISIF" is an ARPANET
host name, then "USC-ISIF.ARPA" is the name of an Internet domain.
アルパネット命名規則からインターネット命名規則までの変遷では、ホスト名は終点ドメインに単純名として使用されるかもしれません。 したがって、"USC-ISIF"がアルパネットホスト名であるなら、"USC-ISIF.ARPA"はインターネットドメインの名前です。
10. Summary
10. 概要
A hierarchical naming convention based on the domain concept has been adopted by the Internet community. It is an absolute naming convention defined along administrative rather than topological boundaries. This naming convention is adaptive for interoperations with other naming conventions. Thus, no standard convention needs to be imposed for interoperations among heterogeneous naming environments.
ドメイン概念に基づく階層的な命名規則はインターネットコミュニティによって採用されました。 それは位相的であるというよりむしろ管理の境界に沿って定義された絶対命名規則です。 interoperationsに、この命名規則は他の命名規則と共に適応型です。 したがって、どんな一般的なコンベンションも、interoperationsのために異種の命名環境の中で課される必要がありません。
This Internet naming convention allows distributed name service and naming authority functions at each domain. We have specified these functions required at each domain. Also discussed are implications on network-oriented applications, mail systems, and administrative aspects of this convention.
分配された名前サービスとこのインターネット命名規則は各ドメインで権威を機能と命名させること。 私たちは各ドメインで必要であるこれらの機能を指定しました。 また、議論しているのは、このコンベンションのネットワーク指向のアプリケーション、メールシステム、および管理局面での含意です。
Su & Postel [Page 9]
Suとポステル[9ページ]
RFC 819 August 1982;
RFC819 1982年8月。
APPENDIX A
付録A
The BNF Specification
BNF仕様
We present here a rather detailed "BNF" definition of the allowed form for a computer mail "mailbox" composed of a "local-part" and a "domain" (separated by an at sign). Clearly, the domain can be used separately in other network-oriented applications.
私たちがここに「メールボックス」という「地方の部分」と「ドメイン」で構成されたコンピュータメールのための許容形式のかなり詳細な"BNF"定義を提示する、(分離する、サイン) 明確に、別々に他のネットワーク指向のアプリケーションでドメインを使用できます。
<mailbox> ::= <local-part> "@" <domain>
<メールボックス>:、:= <の地方のパート>"@"<ドメイン>。
<local-part> ::= <string> | <quoted-string>
<の地方のパート>:、:= <ストリング>。| <引用文字列>。
<string> ::= <char> | <char> <string>
<ストリング>:、:= <炭の>。| <炭の><ストリング>。
<quoted-string> ::= """ <qtext> """
<引用文字列>:、:= 「「「<qtext>、「「」」
<qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
<qtext>:、:= 「\」<x>。| 「\」<x><qtext>。| <q>。| <q><qtext>。
<char> ::= <c> | "\" <x>
<炭の>:、:= <c>。| 「\」<x>。
<domain> ::= <naming-domain> | <naming-domain> "." <domain>
<ドメイン>:、:= <の命名しているドメインの>。| 「<の命名しているドメインの>」、」 <ドメイン>。
<naming-domain> ::= <simple-name> | <address>
<の命名しているドメインの>:、:= <単純名>。| <アドレス>。
<simple-name> ::= <a> <ldh-str> <let-dig>
<単純名>:、:= <は皮肉をさせている>の<ldh-str><>です。
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<ldh-str>:、:= <の皮肉をさせているhypの>。| <の皮肉をさせているhypの><ldh-str>。
<let-dig> ::= <a> | <d>
皮肉をさせている<>:、:= <は>です。| <d>。
<let-dig-hyp> ::= <a> | <d> | "-"
<の皮肉をさせているhypの>:、:= <は>です。| <d>。| "-"
<address> :: = "#" <number> | "[" <dotnum> "]"
<アドレス>:、: = 「#」<番号>。| 「[「<dotnum>」]」
<number> ::= <d> | <d> <number>
<番号>:、:= <d>。| <d><番号>。
<dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
<dotnum>:、:= 「<snum>」、」 「<snum>」、」 「<snum>」、」 <snum>。
<snum> ::= one, two, or three digits representing a decimal integer value in the range 0 through 255
<snum>:、:= 1、2、または範囲に0〜255に10進整数値を表す3ケタ
<a> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case
<a>:、:= 小文字のzを通した大文字とaのZを通した52の英字Aのいずれも
<c> ::= any one of the 128 ASCII characters except <s> or <SP>
<c>:、:= <s>か<SP>以外の128人のASCII文字のいずれも
<d> ::= any one of the ten digits 0 through 9
<d>:、:= 10ケタ0〜9のいずれも
Su & Postel [Page 10]
Suとポステル[10ページ]
RFC 819 August 1982;
RFC819 1982年8月。
<q> ::= any one of the 128 ASCII characters except CR, LF, quote ("),
or backslash (\)
<q>:、:= CR以外の128人のASCII文字のどれか(LF)が引用する、(「)、バックスラッシュ、」(\)
<x> ::= any one of the 128 ASCII characters (no exceptions)
<x>:、:= 128人のASCII文字のいずれも(例外がありません)
<s> ::= "<", ">", "(", ")", "[", "]", "\", ".", ",", ";", ":", "@",
""", and the control characters (ASCII codes 0 through 31 inclusive
and 127)
<s>:、:= "<", ">", "(", ")", "[", "]", "\", ".", ",", ";", ":", "@", """, and the control characters (ASCIIが包括的に0〜31をコード化する、127)
Note that the backslash, "\", is a quote character, which is used to indicate that the next character is to be used literally (instead of its normal interpretation). For example, "Joe\,Smith" could be used to indicate a single nine character user field with comma being the fourth character of the field.
「\」というバックスラッシュが引用文字であることに注意してください。(その引用文字は、次のキャラクタが文字通り(通常の解釈の代わりに)使用されることになっているのを示すのに使用されます)。 例えば、分野の4番目のキャラクタであるコンマでただ一つの9キャラクタユーザ分野を示すのに「ジョー\、スミス」を使用できました。
The simple names that make up a domain may contain both upper and lower case letters (as well as digits and hyphen), but these names are not case sensitive.
ドメインを作る単純名は両方の大文字と小文字手紙(ケタとハイフンと同様に)を含むかもしれませんが、これらの名前は大文字と小文字を区別していません。
Hosts are generally known by names. Sometimes a host is not known to the translation function and communication is blocked. To bypass this barrier two forms of addresses are also allowed for host "names". One form is a decimal integer prefixed by a pound sign, "#". Another form, called "dotted decimal", is four small decimal integers separated by dots and enclosed by brackets, e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet Address in four 8-bit fields. (Of course, these numeric address forms are specific to the Internet, other forms may have to be provided if this problem arises in other transport systems.)
一般に、ホストは名前によって知られています。 時々、ホストは翻訳機能に知られていません、そして、コミュニケーションは妨げられます。 また、このバリアを迂回させるために、2つのフォームのアドレスはホスト「名前」のために許容されています。 1つのフォームが1ポンドのサイン、「#」によって前に置かれた10進整数です。 「ドット付き10進法」と呼ばれる別のフォームがドットによって切り離されて、例えば括弧によって同封された4つのわずかな10進整数である、「[123.255、.37、.2]、」、4つの8ビットの分野で32ビットのアルパインターネットアドレスを示す。 (もちろん、これらの数値アドレスフォームがインターネットに特定である、この問題が他の輸送システムに起こるなら、他のフォームを提供しなければならないかもしれません。)
Su & Postel [Page 11]
Suとポステル[11ページ]
RFC 819 August 1982;
RFC819 1982年8月。
APPENDIX B
付録B
An Aside on the Assignment of Simple Names
単純名の課題の余談
In the following example, there are two naming hierarchies joining at the naming universe 'U'. One consists of domains (S, R, N, J, P, Q, B, A); and the other (L, E, F, G, H, D, C, K, B, A). Domain B is assumed to have multiple parentage as shown.
以下の例には、命名宇宙'U'で接合すると階層構造を命名する2があります。 1つはドメイン(S、R、N、J、P、Q、B、A)から成ります。 そして、もう片方(L、E、F、G、H、D、C、K、B、A)。 ドメインBには複数の生まれが示されるようにあると思われます。
U
/ \
/ \
J L
/ \
N E
/ \ / \
R P D F
/ \ | \ \
S Q C (X) G
\ / \ \
B K H
/
A
U/\/\J L/\N E/円/\R P D F/\| \\S Q C(X)G\/\\B K H/A
Figure 3
Illustration of Requirements for the Distinction of Simple Names
図3 単純名の区別のための要件のイラスト
Suppose someone at A tries to initiate communication with destination H. The fully qualified destination name would be
Aのだれかが目的地H.とのコミュニケーションを開始しようとするなら、完全に適切な目的地名はそうでしょう。
H.G.F.E.L.U
H.G.F.E.L.U
Omitting common ancestors, the partially qualified name for the destination would be
一般的な先祖を省略して、目的地への部分的に適切な名前は省略するでしょう。
H.G.F
H.G.F
To permit the case of partially qualified names, name server at A needs to resolve the simple name F, i.e., F needs to be distinct from all the other simple names in its database.
部分的に適切な名前に関するケースを可能にするのに、Aのネームサーバは、単純名Fを決議する必要があります、すなわち、Fがデータベースの他のすべての単純名と異なる必要があります。
To enable the name server of a domain to resolve simple names, a simple name for a child needs to be assigned distinct from those of all of its ancestors and their immediate children. However, such distinction would not be sufficient to allow simple name resolution at lower-level domains because lower-level domains could have multiple parentage below the level of this domain.
ドメインのネームサーバが単純名を決議するのを可能にするために、子供のための単純名は、先祖と彼らの即座の子供のすべてのものと異なった状態で割り当てられる必要があります。 しかしながら、そのような区別は、低レベルドメインがこのドメインのレベルの下で複数の生まれを持っているかもしれないので低レベルドメインで単純名解決を許すために十分でないでしょう。
In the example above, let us assume that a name is to be assigned
例では、上では、名前が割り当てられることであると仮定しましょう。
Su & Postel [Page 12]
Suとポステル[12ページ]
RFC 819 August 1982;
RFC819 1982年8月。
to a new domain X by D. To allow name server at D to resolve
simple names, the name for X must be distinct from L, E, D, C, F,
and J. However, allowing A to resolve simple names, X needs to be
also distinct from A, B, K, as well as from Q, P, N, and R.
ToがDで単純名をネームサーバを決議させるD.による新しいドメインXと、Xのための名前は決心に簡単なAが命名するLとEとDとC、FとJ.However、許容と異なるに違いありません、また、Aと異なるXの必要性、B、K、よくQ、P、N、およびRのように。
The following observations can be made.
以下の観測をすることができます。
Simple names along parallel trails (distinct trails leading from
one domain to the naming universe) must be distinct, e.g., N must
be distinct from E for B or A to properly resolve simple names.
平行な道(1つのドメインから命名宇宙まで導く異なった道)に沿った単純名が異なるに違いない、例えば、BかAが適切に単純名を決議するように、NはEと異なっていなければなりません。
No universal uniqueness of simple names is called for, e.g., the
simple name S does not have to be distinct from that of E, F, G,
H, D, C, K, Q, B, or A.
単純名のどんな普遍的なユニークさも求められません、例えば、単純名SはE、F、G、H、D、C、K、Q、B、またはAのものと異なっている必要はありません。
The lower the level at which a domain occurs, the more immune it
is to the requirement of naming uniqueness.
ドメインが起こるレベルであり、それは免疫があれば免疫があるほど、命名のユニークさの要件が、より低いです。
To satisfy the required distinction of simple names for proper resolution at all levels, a naming authority needs to ensure the simple name to be assigned distinct from those in the name server databases at the endpoint naming domains within its domain. As an example, for D to assign a simple name for X, it would need to consult databases at A and K. It is, however, acceptable to have simple names under domain A identical with those under K. Failure of such distinct assignment of simple names by naming authority of one domain would jeopardize the capability of simple name resolution for entities within the subtree under that domain.
すべてのレベルで適切な解決のための単純名の必要な区別を満たすために、命名権威は、ドメインの中でドメインを命名する終点のネームサーバデータベースのそれらと異なった状態で割り当てられるために単純名を確実にする必要があります。 例として、DがXのために単純名を割り当てるのに、Aでデータベースに相談するのが必要でしょう、そして、しかしながら、1つのドメインの権威を命名する単純名のそのような異なった課題のFailureがそうするK.の下のそれらと同じドメインAの下における単純名に下位木の中でそのドメインの下で実体のための単純名解決の能力を危険にさらさせるのにおいてK.Itは許容できます。
Su & Postel [Page 13]
Suとポステル[13ページ]
RFC 819 August 1982;
RFC819 1982年8月。
APPENDIX C
付録C
Further Discussion of Name Service and Name Servers
名前サービスとネームサーバのさらなる議論
The name service on a system should appear to the programmer of an application program simply as a system call or library subroutine. Within that call or subroutine there may be several types of methods for resolving the name string into an address.
システムにおける名前サービスは単にシステムコールかライブラリ・サブルーチンとしてアプリケーション・プログラムのプログラマにとって現れるべきです。 中では、そこのその呼び出しかサブルーチンが、ストリングという名前にアドレスに変えるためのいくつかのタイプのメソッドであるかもしれません。
First, a local table may be consulted. This table may be a
complete table and may be updated frequently, or it may simply be
a cache of the few latest name to address mappings recently
determined.
まず最初に、地方のテーブルは相談されるかもしれません。 このテーブルを完全なテーブルであるかもしれなく、頻繁にアップデートするかもしれませんか、それは単に最近決定したアドレス・マッピングへのわずかな最新の名前のキャッシュであるかもしれません。
Second, a call may be made to a name server to resolve the string
into a destination address.
2番目に、送付先アドレスにストリングに変えるのをネームサーバに電話をかけるかもしれません。
Third, a call may be made to a name server to resolve the string
into a relay address.
3番目に、リレーアドレスにストリングに変えるのをネームサーバに電話をかけるかもしれません。
Whenever a name server is called it may be a recursive server or an interactive server.
ネームサーバが呼ばれるときはいつも、それは、再帰的なサーバか対話的なサーバであるかもしれません。
If the server is recursive, the caller won't be able to tell if
the server itself had the information to resolve the query or
called another server recursively (except perhaps for the time it
takes).
サーバが再帰的であるなら、訪問者は、サーバ自体が質問を決議する情報を持っていたか、または別のサーバを再帰的に呼んだか(恐らく時間以外に、それは取ります)わからないでしょう。
If the server is iterative, the caller must be prepared for either
the answer to its query, or a response indicating that it should
call on a different server.
サーバが繰り返しであるなら、訪問者は異なったサーバを訪問するべきであるのを示す質問の答えか応答のどちらかのために用意ができていなければなりません。
It should be noted that the main name service discussed in this memo is simply a name string to address service. For some applications there may be other services needed.
このメモで議論した本名サービスが単にサービスを扱う名前ストリングであることに注意されるべきです。 いくつかのアプリケーションのために、必要である他のサービスがあるかもしれません。
For example, even within the Internet there are several procedures
or protocols for actually transferring mail. One need is to
determine which mail procedures a destination host can use.
Another need is to determine the name of a relay host if the
source and destination hosts do not have a common mail procedure.
These more specialized services must be specific to each
application since the answers may be application dependent, but
the basic name to address translation is application independent.
例えば、インターネットの中にさえ、実際にメールを移すためのいくつかの手順かプロトコルがあります。 人は、あて先ホストがどのメール手順を用いることができるかを決定することになっていなければなりません。 別の必要性はソースとあて先ホストに一般的なメール手順がないなら中継ホストの名前を決定することです。 答えがアプリケーションに依存しているかもしれないので、これらのより専門化しているサービスは各アプリケーションに特定であるに違いありませんが、アドレス変換への基本的な名前はアプリケーション独立者です。
Su & Postel [Page 14]
Suとポステル[14ページ]
RFC 819 August 1982;
RFC819 1982年8月。
APPENDIX D
付録D
Further Discussion of Interoperability and Protocol Translations
相互運用性とプロトコル変換のさらなる議論
The translation of protocols from one system to another is often quite difficult. Following are some questions that stem from considering the translations of addresses between mail systems:
プロトコルの1台のシステムから別のシステムまでの翻訳はしばしばかなり難しいです。 以下に、メールシステムの間のアドレスに関する翻訳を考えるので以下を食い止めるいくつかの質問があります。
What is the impact of different addressing environments (i.e.,
environments of different address formats)?
異なったアドレシング環境(すなわち、異なったアドレス形式の環境)の影響は何ですか?
It is noted that the boundary of naming environment may or may not
coincide with the boundary of different mail systems. Should the
conversion of naming be independent of the application system?
命名環境の境界が異なったメールシステムの限界と一致するかもしれないことに注意されます。命名の変換はアプリケーション・システムから独立しているべきですか?
The boundary between different addressing environments may or may
not coincide with that of different naming environments or
application systems. Some generic approach appears to be
necessary.
異なったアドレシング環境の間の境界は異なった命名環境かアプリケーション・システムのものと一致するかもしれません。何らかの一般的方法が必要であるように見えます。
If the conversion of naming is to be independent of the
application system, some form of interaction appears necessary
between the interface module of naming conversion with some
application level functions, such as the parsing and modification
of message text.
命名の変換がそうなら、何らかのアプリケーションによる変換をレベルと命名するインタフェース・モジュールはアプリケーション・システムから独立しています、何らかのフォームの相互作用が必要であることの間のように見えるということになるように機能します、メッセージ・テキストの構文解析や変更のように。
To accommodate encryption, conversion may not be desirable at all.
What then can be an alternative to conversion?
暗号化を収容するために、変換は全く望ましくないかもしれません。 そして、何が変換への代替手段であるかもしれませんか?
Su & Postel [Page 15]
Suとポステル[15ページ]
RFC 819 August 1982;
RFC819 1982年8月。
GLOSSARY
用語集
address
アドレス
An address is a numerical identifier for the topological location
of the named entity.
アドレスは命名された実体の位相的な位置のための数字の識別子です。
name
名前
A name is an alphanumeric identifier associated with the named
entity. For unique identification, a name needs to be unique in
the context in which the name is used. A name can be mapped to an
address.
名前は命名された実体に関連している英数字の識別子です。 ユニークな識別のために、名前は、名前が使用されている文脈で特有である必要があります。 名前をアドレスに写像できます。
complete (fully qualified) name
完全な(完全に適切な)名前
A complete name is a concatenation of simple names representing
the hierarchical relation of the named with respect to the naming
universe, that is it is the concatenation of the simple names of
the domain structure tree nodes starting with its own name and
ending with the top level node name. It is a unique name in the
naming universe.
完全な名前が命名宇宙に関して命名の階層的な関係を表す単純名の連結である、すなわち、それは最高平らなノード名でそれ自身の名前と結末から始まるドメイン構造木のノードの単純名の連結です。 それは命名宇宙の中のユニークな名前です。
partially qualified name
部分的に適切な名前
A partially qualified name is an abbreviation of the complete name
omitting simple names of the common ancestors of the communicating
parties.
部分的に適切な名前は交信パーティーの一般的な先祖の単純名を省略する完全な名前の略語です。
simple name
単純名
A simple name is an alphanumeric identifier unique only within its
parent domain.
単純名は親ドメインだけの中でユニークな英数字の識別子です。
domain
ドメイン
A domain defines a region of jurisdiction for name assignment and
of responsibility for name-to-address translation.
ドメインは名前課題のための管轄と名前からアドレス変換への責任の範囲を定義します。
naming universe
宇宙を命名します。
Naming universe is the ancestor of all network entities.
宇宙を命名するのは、すべてのネットワーク実体の先祖です。
naming environment
環境を命名します。
A networking environment employing a specific naming convention.
特定の命名規則を使うネットワーク環境。
Su & Postel [Page 16]
Suとポステル[16ページ]
RFC 819 August 1982;
RFC819 1982年8月。
name service
名前サービス
Name service is a network service for name-to-address mapping.
名前サービスは名前からアドレス・マッピングのためのネットワーク・サービスです。
name server
ネームサーバ
A name server is a network mechanism (e.g., a process) realizing
the function of name service.
ネームサーバは名前サービスの機能がわかるネットワークメカニズム(例えば、プロセス)です。
naming authority
権威を命名します。
Naming authority is an administrative entity having the authority
for assigning simple names and responsibility for resolving naming
conflict.
権威を命名するのは、単純名を割り当てるための権威と命名闘争を解決することへの責任がある管理実体です。
parallel relations
平行な関係
A network entity may have one or more hierarchical relations with
respect to the naming universe. Such multiple relations are
parallel relations to each other.
ネットワーク実体には、命名宇宙に関して1つ以上の階層的な関係があるかもしれません。 そのような複数の関係が互いとの平行な関係です。
multiple parentage
複数の生まれ
A network entity has multiple parentage when it is assigned a
simple name by more than one naming domain.
単純名が1つ以上の命名ドメインによってそれに割り当てられるとき、ネットワーク実体には、複数の生まれがあります。
Su & Postel [Page 17]
Suとポステル[17ページ]
RFC 819 August 1982;
RFC819 1982年8月。
REFERENCES
参照
[1] F. Harary, "Graph Theory", Addison-Wesley, Reading, Massachusetts, 1969.
[1] F.ハラリー、「グラフ理論」、アディソン-ウエスリー、読書、マサチューセッツ、1969。
[2] J. Postel, "Computer Mail Meeting Notes", RFC-805, USC/Information Sciences Institute, 8 February 1982.
[2] J.ポステル、「コンピュータメールミーティング注意」、RFC-805、科学が設けるUSC/情報、1982年2月8日。
[3] J. Postel, "Simple Mail Transfer Protocol", RFC-821, USC/Information Sciences Institute, August 1982.
[3] J.ポステル、「簡単なメール転送プロトコル」、RFC-821、科学が1982年8月に設けるUSC/情報。
[4] D. Crocker, "Standard for the Format of ARPA Internet Text Messages", RFC-822, Department of Electrical Engineering, University of Delaware, August 1982.
[4] D.クロッカー、「アルパインターネットテキスト・メッセージの形式の規格」、RFC-822、電気工学の部、デラウエア大学(1982年8月)。
Su & Postel [Page 18]
Suとポステル[18ページ]
一覧
スポンサーリンク
