RFC606 日本語訳

Netork Working Group                                     L. Peter Deutsch
Request For Comments: 606                                       PARC-MAXC
                                                            December 1973

コメントを求めるNetorkワーキンググループL.ピーターのドイツ語要求: 606 PARC-MAXC1973年12月

                       Host Names On-line

オンラインで名前をホスティングしてください。

Now that we finally have an official list of host names, it seems
about time to put an end to the absurd situation where each site
on the network must maintain a different, generally out-of-date,
host list for the use of its own operating system or user
programs.

私たちにはホスト名に関する株式相場表が最終的にあるので、ネットワークに関する各サイトがそれ自身のオペレーティングシステムかユーザ・プログラムの使用のための異なって、一般に時代遅れなホストリストを維持しなければならないばかげた状況を終わらせるのはそろそろ時間に思えます。

For example, each of the TENEX sites to which I have access
( SRI-ARC, BBN-TENEX, USC-ISI, and PARC-MAXC) has a slightly
different mapping between host names and host addresses: none
is complete, and I believe each one differs in some way from
the official List.

例えば、私がアクセス(SRI-ARC、BBN-TENEX、USC-ISI、およびPARC-MAXC)を持っているそれぞれのTENEXサイトはホスト名とホスト・アドレスの間にわずかに異なったマッピングを持っています: なにも完全ではありません、そして、私は各々が公式のListと何らかの方法で異なると信じています。

Since the NIC has responsibility for maintaining the official
list, lt seems appropriate for them to maintain an on-line file,
accessible to anyone, which Lists names and host addresses ( and
certain other information which I will suggest in a moment) in an
easily machine-readable form.

NICには株式相場表を維持することへの責任があるので、ltは彼らが、容易に機械可読なフォームでオンラインだれにとっても、アクセス可能なファイルがどのLists名とホスト・アドレス(そして、私が見る間に勧めるつもりである他のある情報)であるかを支持するのが、適切に見えます。

This rules out, in my opinion, providing this information only
in the form of an NLS structured file, since there are no
facilities for accessing such files from the network and since
many sites would not want to accommodate themselves to this
structure even if there were.

これは、私の意見でNLS構造化ファイルの形だけにこの情報を供給するのを除外します、ネットワークからそのようなファイルにアクセスするための施設が全くなくて、いたとしても多くのサイトがこの構造に自分たちを収容したがっていないので。

The file I have in mind would be devoted principally to that
information needed by programs, as opposed to people, since the	;
former want their information in compact, easily parsed form,
whereas the latter appreciate more verbose expression and more
sophisticated facilities for browsing or querying. Therefore, I
propose that the following information be included in such a file:

私が考えているファイルは主にプログラムで必要であるその情報に注がれるでしょう、人々と対照的に、以来。 前者はコンパクトで、容易に分析されたフォームでそれらの情報を必要としますが、後者はブラウジングか質問のために、より冗長な表現と、より洗練された施設に感謝します。 したがって、私は、以下の情報がそのようなファイルに含まれているよう提案します:

Of course, the official name and host address for each host.
This would be the primary content of each entry.

もちろん、各ホストのための正式名称とホスト・アドレス。 これはそれぞれのエントリーの第一の内容でしょう。

Some information about the options of the various protocols
supported by the host, including ( for FTP ) the preferred byte
size and ( for TELNET) the preferred duplex mode. The former
can have an enormous effect on the efficiency of file
transfers. Since the new TELNET allows negotiation of options,
the list need not be complete or accurate.

都合のよいバイトサイズと(TELNETのための)都合のよい重複のモードを含む(FTPのために)ホストによってサポートされた様々なプロトコルのオプションの何らかの情報。 前者はファイル転送の効率に莫大な影響を与えることができます。 新しいTELNETがオプションの交渉を許すので、リストは、完全であるか、または正確である必要はありません。

The function o f the host vis-a-vis the network ( user, server,
TIP, etc.). This may aid NCPs in deciding whether to poll the
host or give useful information for statistical purposes ( e.g.
I would like to make my NCP collect statistics on traffic with
TIPs vs. other hosts).
Since the file will be generated centrally by a single program,
but used widely by a variety of programs, it follows that its
format should be organized for ease of interrogation at the
expense of ease of construction. I feel a reasonable way to
achieve this is to store it as an ASCII text file with the logical
structure of a "property list".
                                   -1-

機能、ネットワーク(ユーザ、サーバ、TIPなど)と向かいあったホストのo f。 ホストに投票するか、または統計的な目的のための役に立つ情報を与えるかを決める際にこれはNCPを支援するかもしれません(例えば、私のNCPにTIPsとの交通対他のホストのときに統計を集めさせたいと思います)。 ファイルが中心で単一のプログラムで発生しますが、さまざまなプログラムで広く使用されるので、形式が査問の容易さのために工事の容易さを犠牲にして組織化されるべきであるということになります。 私は、これを達成する合理的な方法がASCIIテキスト・ファイルとして「特性のリスト」の論理構造でそれを格納することであると感じます。 -1-

In other words, aside from the two basic facts in each entry
( name and address), the information will be expressed in the
form of <attribute, value> pairs rather than having the
attribute be recognized by format, position, etc.

言い換えれば、各エントリー(命名して、記述する)における2つの基本の事実は別として、情報は<属性の形で言い表されるでしょう、形式、位置などで属性を認識させるよりむしろ値の>組

l don't believe it matters a great deal exactly how this file is
formatted, so I will make a suggestion in the hope that no one
cares enough to protest it. ( This has never worked before in the
history of the network, but it' s still worth a try ) The
following is the proposed syntax of the file.

lが、このファイルがちょうどどのようにフォーマットされるかが大いに重要であると信じていないので、私はだれもそれについて異議を申し立てることができるくらいには気にかけないという望みで案を出すつもりです。 '、(これは以前、しかし、ネットワーク、それの歴史でトライのまだ価値があった状態で'sを一度も扱ったことがありません) ↓これはファイルの提案された構文です。

<host-name-file> ::= <entry> | <host-name-file> <entry>

<ホスト名ファイル>:、:= <エントリー>。| <ホスト名ファイル><エントリー>。

<entry> ::= <data-part> <end-of-line>

<エントリー>:、:= <データパート><行末>。

Note that this produces a blank line after the <data-part>.
<data-part> ::= <basic-part> | <data-part> <attribute-item>
<basic-part> ::= <host-name> , <host-address> <end-of-line>
<attribute-item> ::= <attribute-name> = <attribute-value>
<end-of-line>
This leaves the following terms undefined:
<end-of-line>: I don't know what end-of-line indication is in
favor in the network community these days. I personally favor
carriage-return followed by line-feed. TENEX tends to use the
single character octal 37, which is totally non-standard and
inappropriate for this application.

これが<データパート>の後に空白行を生産することに注意してください。 <データパート>:、:= <の基本的なパート>。| <データパート><属性項目>の<の基本的なパート>:、:= <ホスト名>、<ホスト・アドレス><行末><属性項目>:、:= <属性値><<属性名の>=行末>Thisは次の用語を未定義の状態でおきます: <行末>: 私は、どんな行末指示が最近ネットワーク共同体で賛成しているかを知りません。 私は個人的に復帰を支持します、続いて、改行を支持します。 TENEXは、単独のキャラクタに、8進37を使用する傾向があります。(このアプリケーションに、8進は、完全に標準的でなくて、不適当です)。

<host-name>: an official host name as specified in the recent
RFC 597 (NIC 20826) by NJN and JAKE. It is my understanding
that these names are restricted to letters, digits, hyphens,
and parentheses ( including the network name).

<ホスト名>: NJNとジェークによる最近のRFC597(NIC20826)の指定されるとしての公的ホスト役名。 私は、これらの名前が手紙、ケタ、ハイフン、および括弧に制限されるのを理解しています(ネットワーク名を含んでいて)。

<host-address>: a decimal host address, relative to its own
network ( I would assume). There has been no general discussion
of multi-network addressing -- although there is apparently an
unpublicized Internetworking Protocol experiment in progress --
and some other convention may be more desirable.
<attribute-name>: an arbitrary name containing only letters,
digits, and hyphens. We will have to agree on some names like
BEST-FTP-BYTE-SIZE (?), but I am willing to let the NIC pick
them.

<ホスト・アドレス>: それ自身のネットワークに比例した10進ホスト・アドレス(私は仮定するでしょう)。 進行中の未公開のInternetworkingプロトコル実験が明らかにありますが、マルチネットワークアドレシングのどんな一般的な議論もありませんでした、そして、ある他のコンベンションは、より望ましいかもしれません。 <属性名の>: 手紙、ケタ、およびハイフンだけを含む任意の名前。 私たちはBEST FTP BYTE-SIZE (?)のようにいくつかの名前に同意しなければならないでしょうが、私はNICにそれらを選ばせます。

<attribute-value>: an arbitrary string not containing
<end--of-line>, whose interpretation depends in general on the
attribute. For example, there might be an attribute SERVERS
whose value was a list of the servers customarily run by the
site.

<属性値>: 一般に、解釈を属性に依存する線>の<端を含まない任意のストリング。 例えば、値がサイトによって通例に走らされたサーバのリストであった属性SERVERSがあるかもしれません。

The following are some specific attributes that I think would be
worthwhile:

↓これは私が価値があると思ういくつかの特定の属性です:

NICKNAMES -- value is a list of acceptable nicknames for the
host. Any system that provides name-to-address translation is
encouraged ( although of course not required) to accept these
names as alternatives to the official host name.

NICKNAMES--値はホストにとって、許容できるあだ名のリストです。 名前からアドレス変換を提供するどんなシステムも公的ホスト役名への代替手段としてこれらの名前を認めるよう奨励されます(もちろん必要ではありませんが)。

                                     -2-

-2-

FTP-BYTE-SIZES -- value is a list of the byte sizes supported
by the FTP server. The first byte size is the one which leads
to the least computational overhead ( e.g. 36 for PDP-1O's, 32
for 36O's).

値はサイズがFTPサーバで支持したバイトのリストです。FTP-BYTE-SIZES--最初のバイトサイズは最もコンピュータでないオーバーヘッド(例えば、PDP-1O's、36O'sのための32のための36)につながるものです。

ECHOING -- value is L or R depending on whether the host
expects the terminal to echo ( Remote) or expects to do its own
echoing (Local).

ECHOING--ホストが、端末が反響する(リモート)と予想するか、または(地方)でそれ自身の反響をすると予想するかによって、値は、LかRです。

Note that no attribute is actually required and that the values
under a given attribute need not be complete. In other words,
this list is meant not to replace option negotiation,
word-of-mouth, or any other means bo which one host discovers
the properties of another, but merely to provide an alternate
source of information which can be accessed in a simple and
uniform way.

属性は全く実際に必要でなく、与えられた属性の下における値が完全である必要はないことに注意してください。 言い換えれば、このリストはオプション交渉、口コミ、またはそれの1人のホストが別のものの特性を発見するいかなる他の手段棒も置き換えるのではなく、単に、簡単で一定の方法でアクセスできる交互の情報源を提供することになっています。

I realize that there is a time-honored pitfall associated with
suggestions such as the present one: it represents a specific
solution to a specific problem, and as such may not be compatible
with or form a reasonable basis for more general solutions to more
general problems. However, ( 1) this particular problem has been
irking me and others I have spoken to for well over a year, and it
is really absurd that it should have gone unsolved this Long; (2)
no one seems particularly interested in solving any more general
problem.

私は、現在のものとして関連しているそのような提案で由緒ある落とし穴があるとわかります: それは、そういうものとしてより一般的な問題の、より一般的な解決の特定の問題の特定の解決を表して、コンパチブルかフォームa合理的基礎でないかもしれません。( 1) しかしながら、この特定の問題が私が1年間井戸と話している私と他のものをうんざりさせていて、未解決になったのが本当にとんでもない、このLong。 (2) だれも特にそれ以上の一般的問題を解決するのに関心を持つように見えません。

Except the Datacomputer: PLEASE, if there is an easy way to
accomplish the same function through the Datacomputer, someone
write un RFC specifying it.

Datacomputerを除いて: Datacomputerを通して同じ機能を達成する簡単な方法があれば、だれかが、それを指定しながら、不-RFCに書いてください。

                                       -3-

-3-