この文書はRFC1の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 翻訳者はこの文書の配布を制限しません。
Network Working Group Steve Crocker
Request for Comments: 1 UCLA
7 April 1969
Title: Host Software
Author: Steve Crocker
Installation: UCLA
Date: 7 April 1969
Network Working Group Request for Comment: 1
CONTENTS
目次
INTRODUCTION
はじめに
I. A Summary of the IMP Software
I. IMPソフトウェアの要約
Messages
メッセージ
Links
リンク
IMP Transmission and Error Checking
IMP転送とエラー検出
Open Questions on the IMP Software
IMPソフトウェア上の未解決の問題
II. Some Requirements Upon the Host-to-Host Software
II. ホストからホストへのソフトウェアのいくつかの必要条件
Simple Use
単純な使用
Deep Use
濃い使用
Error Checking
エラー検出
III. The Host Software
III. ホストソフトウェア
Establishment of a Connection
接続の確立
High Volume Transmission
大量伝送
A Summary of Primitives
プリミティブの要約
Error Checking
エラー検査
Closer Interaction
近い相互作用
Open Questions
未解決の問題
IV. Initial Experiments
IV. 最初の実験
Experiment One
実験１
Experiment Two
実験２
Introduction
はじめに
The software for the ARPA Network exists partly in the IMPs and
partly in the respective HOSTs. BB&N has specified the software of
the IMPs and it is the responsibility of the HOST groups to agree on
HOST software.
ＡＲＰＡネットワークのためのソフトウェアは、一部はＩＭＰに、一部はそ
れぞれのホストに存在します。BB&NがＩＭＰのソフトウェアを指定しました、
そしてホストソフトウェアを合意するのはホストグループの責任です。
During the summer of 1968, representatives from the initial four
sites met several times to discuss the HOST software and initial
experiments on the network. There emerged from these meetings a
working group of three, Steve Carr from Utah, Jeff Rulifson from SRI,
and Steve Crocker of UCLA, who met during the fall and winter. The
most recent meeting was in the last week of March in Utah. Also
present was Bill Duvall of SRI who has recently started working with
Jeff Rulifson.
１９６８年の夏のから、最初の４つのサイトの代表者がネットワーク上のホ
ストソフトウェアと最初の実験を論じるために数回会いました。この打合せ
から、ユタのスティーブ・カーとＳＲＩのジェフ・ルイグソンとＵＣＬＡの
スティーブ・クロッカーの３人の作業グループが結成され、彼らは秋と冬の
間に会いました。最も最近のミーティングはユタで３月の最後の週にありま
した。同じくＳＲＩでジェフ・ルイグソンと共に働きはじめたビル・デュバ
ルが加わりました。
Somewhat independently, Gerard DeLoche of UCLA has been working on
the HOST-IMP interface.
これとは独立にＵＣＬＡのジェラード・デロッチェがホストＩＭＰインタ
フェースに取り組んでいました。
I present here some of the tentative agreements reached and some of
the open questions encountered. Very little of what is here is firm
and reactions are expected.
私はここで達成した仮合意とある遭遇した未解決の問題を提示します。ここ
にあるものはほとんど確実ではありません、そして反応が予想されます。
I. A Summary of the IMP Software
I. ＩＭＰソフトウェアの要約
Messages
メッセージ
Information is transmitted from HOST to HOST in bundles called
messages. A message is any stream of not more than 8080 bits,
together with its header. The header is 16 bits and contains the
following information:
情報がメッセージと呼ばれる束でホストからホストへ伝達されます。メッセー
ジはヘッダ付きで８０８０ビット以下の流れです。ヘッダー１６ビットで、
次の情報を含みます：
Destination 5 bits
宛先 5 ビット
Link 8 bits
リンク 8 ビット
Trace 1 bit
追跡 1 ビット
Spare 2 bits
予備 2 ビット
The destination is the numerical code for the HOST to which the
message should be sent. The trace bit signals the IMPs to record
status information about the message and send the information back to
the NMC (Network Measurement Center, i.e., UCLA). The spare bits are
unused.
宛先はメッセージが送られるべきホストの数値コードです。追跡ビットはＩ
ＭＰにメッセージの状態情報を記録し、情報をＮＭＣ（ネットワーク測定セ
ンター)に送り返すように指示します。予備のビットは使われていません。
Links
リンク
The link field is a special device used by the IMPs to limit certain
kinds of congestion. They function as follows. Between every pair of
HOSTs there are 32 logical full-duplex connections over which messages
may be passed in either direction. The IMPs place the restriction on
these links that no HOST can send two successive messages over the
same link before the IMP at the destination has sent back a special
message called an RFNM (Request for Next Message). This arrangement
limits the congestion one HOST can cause another if the sending HOST
is attempting to send too much over one link. We note, however, that
since the IMP at the destination does not have enough capacity to
handle all 32 links simultaneously, the links serve their purpose only
if the overload is coming from one or two links. It is necessary for
the HOSTs to cooperate in this respect.
リンクフィールドはＩＭＰの使う特殊デバイスで、ある種の輻輳を制限しま
す。これらは次のように作用します。すべてのホスト対の間で両方向にメッ
セージを転送する３２本の論理的な全二重の接続があります。宛先のＩＭＰ
がＲＦＮＭ（次のメッセージの要求）と呼ばれる特別なメッセージを返送す
るまで、ホストが２つの連続したメッセージを同じリンク上で送れないよう
に、ＩＭＰはこれらのリンクに制限をします。この取り決めは輻輳を制限し
ます、もし送信ホストがあまりに多くのメッセージを１つのリンクを送ろう
と試みるなら、他のホストで輻輳を起こします。しかし我々は次の事に気づ
きました、宛先のＩＭＰが同時にすべての３２のリンクを処理する十分な容
量を持っていないので、過度のメッセージが１つか２つのリンクにだけに来
る限りリンクは目的通り動きます。ホストがこの点に関して協力することが
必要です。
The links have the following primitive characteristics. They are
always functioning and there are always 32 of them.
リンクは次の基本特性を持っています。リンクは常に稼動していて、常に
３２本あります。
By "always functioning," we mean that the IMPs are always prepared to
transmit another message over them. No notion of beginning or ending
a conversation is contained in the IMP software. It is thus not
possible to query an IMP about the state of a link (although it might
be possible to query an IMP about the recent history of a link --
quite a different matter!).
「常に稼動する」ことは、ＩＭＰが常にリンク上にもう１つのメッセージを
送信する用意ができていることを意図します。対話の開始や終了の考えがＩ
ＭＰソフトウェアに含まれません。このためリンクの状態についてＩＭＰに
質問することは可能ではありません（リンクの最近の活動記録についてＩＭ
Ｐに質問することは可能かもしれないけれが、これはかなり異なる意味です！）。
The other primitive characteristic of the links is that there are
always 32 of them, whether they are in use or not. This means that
each IMP must maintain 18 tables, each with 32 entries, regardless of
the actual traffic.
他のリンクの基本特性は、使用中か否かにかかわらず、常に３２あるという
ことです。これはＩＭＰが実際のトラヒックに関係なく各３２の項目を持つ
１８のテーブルを維持しなくてはならないことを意味します。
The objections to the link structure notwithstanding, the links are
easily programmed within the IMPs and are probably a better
alternative to more complex arrangements just because of their
simplicity.
リンク構造に対する欠点にもかかわらず、リンクはＩＭＰ中で容易にプログ
ラムでき、その単純さのため、恐らく、より複雑な取り決めよりも、良い選
択です。
IMP Transmission and Error Checking
ＩＭＰ転送とエラー検出
After receiving a message from a HOST, an IMP partitions the message
into one or more packets. Packets are not more than 1010 bits long
and are the unit of data transmission from IMP to IMP. A 24 bit
cyclic checksum is computed by the transmission hardware and is
appended to an outgoing packet. The checksum is recomputed by the
receiving hardware and is checked against the transmitted checksum.
Packets are reassembled into messages at the destination IMP.
ホストからメッセージを受け取った後で、ＩＭＰがメッセージを１つ以上の
パケットに分割します。パケットは長さが１０１０ビット以下で、ＩＭＰか
らＩＭＰまでのデータ伝送単位です。２４ビット周期チェックサムが送信ハー
ドウェアで計算され、送信パケットに付けられます。チェックサムは受信ハー
ドウェアで再計算され、伝達されたチェックサムと照合されます。パケット
が最終目的地のＩＭＰでメッセージに組み立てられます。
Open Questions on the IMP Software
ＩＭＰソフトウェア上の未解決の問題
1. An 8 bit field is provided for link specification, but only 32
links are provided, why?
1. ８ビットフィールドがリンク仕様で提供されます、しかし３２本のリン
クだけが供給されます、なぜでしょう？
2. The HOST is supposed to be able to send messages to its IMP. How
does it do this?
2. ホストはＩＭＰにメッセージを送ることが可能となっています。どのよ
うにこれをしますか？
3. Can a HOST, as opposed to its IMP, control RFNMs?
3. ホストがＩＭＰと対向したホストが、ＲＦＮＭを制御できますか？
4. Will the IMPs perform code conversion? How is it to be
controlled?
4. ＩＭＰはコード変換を行うでしょうか？どのようにそれは制御されますか？
II. Some Requirements Upon the Host-to-Host Software
II. ホストからホストへのソフトウェアのいくつかの必要条件
Simple Use
単純な使用
As with any new facility, there will be a period of very light usage
until the community of users experiments with the network and begins
to depend upon it. One of our goals must be to stimulate the
immediate and easy use by a wide class of users. With this goal, it
seems natural to provide the ability to use any remote HOST as if it
had been dialed up from a TTY (teletype) terminal. Additionally, we
would like some ability to transmit a file in a somewhat different
manner perhaps than simulating a teletype.
あらゆる新しい設備と同じく、ユーザー共同体がネットワークを使って実験
始めてから、ネットワークを信頼し始めるまで、非常に軽く使える時期があ
るでしょう。我々のゴールの１つが広い範囲のユーザーにすぐ簡単に使って
もらうことに違いありません。このゴールが、TTY（テレタイプ）端末からダ
イアルアップしたかのように、あらゆる遠隔地のホストでも使う機能の提供
なのは自然と思われます。さらに、我々はテレタイプを真似するのと異なる
方法でファイルを転送する能力が欲しいです。
Deep Use
濃い使用
One of the inherent problems in the network is the fact that all responses
from a remote HOST will require on the order of a half-second or so,
no matter how simple. For teletype use, we could shift to a
half-duplex local-echo arrangement, but this would destroy some of the
usefulness of the network. The 940 Systems, for example, have a very
specialized echo.
ネットワークでの固有の問題の１つがすべての遠隔ホストからの回答が、ど
んな簡単な方法でも、半秒程度かかるという事実です。テレタイプ使用のた
めに、我々は半二重通信とローカルエコーをする事にしました、しかしこれ
はネットワークの有用性のいくらかを犠牲にするでしょう。940システムは、
例えば、非常に専門的なエコーを持っています。
When we consider using graphics stations or other sophisticated
terminals under the control of a remote HOST, the problem becomes more
severe. We must look for some method which allows us to use our most
sophisticated equipment as much as possible as if we were connected
directly to the remote computer.
我々が遠隔ホストの制御下でグラフィックスステーションや他の高度な端末
を使うことを考える時、問題はいっそうひどくなります。我々が直接遠隔コ
ンピュータに接続してるかのように、我々の高度な端末を我々が使える方法
を探さなくてはなりません。
Error Checking
エラー検出
The point is made by Jeff Rulifson at SRI that error checking at major
software interfaces is always a good thing. He points to some
experience at SRI where it has saved much dispute and wasted effort.
On these grounds, we would like to see some HOST to HOST checking.
Besides checking the software interface, it would also check the
HOST-IMP transmission hardware. (BB&N claims the HOST-IMP hardware
will be as reliable as the internal registers of the HOST. We believe
them, but we still want the error checking.)
主要なソフトウェアインタフェースでのエラー検査は常に良いという点をSRI
のジェフ・ルリフソンが示しました。彼はSRIでの経験を示し、これは多くの
議論と無駄な努力を省きます。これらの理由で、我々はホストからホストへ
の検査をしたいです。ソフトウェアインタフェースでの検査は、同じくホスト
−IMP送信ハードウェアの検査をするでしょう。（BB&NはホストIMPハードウェ
アがホストの内部レジスタと同じぐらい信頼性が高いと主張します。我々は
彼らを信じますが、我々はまだエラー検査がしたいです）。
III. The Host Software
III. ホストソフトウェア
Establishment of a Connection
接続の確立
The simplest connection we can imagine is where the local HOST acts as
if it is a TTY and has dialed up the remote HOST. After some
consideration of the problems of initiating and terminating such a
connection , it has been decided to reserve link 0 for communication
between HOST operating systems. The remaining 31 links are thus to be
used as dial-up lines.
我々が想像することができる最も単純な接続はローカルホストがTTYで遠隔ホ
ストにダイアルアップしたかのように行動をする事です。接続開始と終了の
問題を考えた後で、ホストオペレーティングシステム間の交信のためにリン
ク０を確保する決断がされました。残りの３１本のリンクはダイアルアップ
ラインに用いられるはずです。
Each HOST operating system must provide to its user level programs a
primitive to establish a connection with a remote HOST and a primitive
to break the connection. When these primitives are invoked, the
operating system must select a free link and send a message over link
0 to the remote HOST requesting a connection on the selected link.
The operating system in the remote HOST must agree and send back an
accepting message over link 0. In the event both HOSTs select the same
link to initiate a connection and both send request messages at
essentially the same time, a simple priority scheme will be invoked in
which the HOST of lower priority gives way and selects another free
link. One usable priority scheme is simply the ranking of HOSTS
by their identification numbers. Note that both HOSTs are aware that
simultaneous requests have been made, but they take complementary
actions: The higher priority HOST disregards the request while the
lower priority HOST sends both an acceptance and another request.
各ホストオペレーティングシステムがユーザーレベルプログラムに接続の確
立のプリミティブと接続の開放のプリミティブを提供しなくてはなりません。
これらのプリミティブが呼び出されると、オペレーティングシステムは空い
たリンクを選び、リンク０上で、遠隔ホストに、選択されたリンクの接続を
求めるメッセージを送らなくてはなりません。遠隔ホストのオペレーティン
グシステムは同意し、リンク０上で受入れメッセージを返送しなくてはなり
ません。両方のホストが接続を始めるため同じリンクを選択し、本質的に同
時に接要求メッセージを送る場合、単純な優先付けで、優先度の低いホスト
が他の開いてるリンクを選ぶでしょう。１つの利用できる優先付け案はホス
トの識別番号順です。両方のホストが同時の要求がされ、補足的な行動をと
ることが必要とわかることに注意してください：優先順位の高いホストは優
先順位のホストは承認と他の要求を送る間、要求を無視します。
The connection so established is a TTY-like connection in the
pre-log-in state. This means the remote HOST operating system will
initially treat the link as if a TTY had just called up. The remote
HOST will generate the same echos, expect the same log-in sequence and
look for the same interrupt characters.
確立された接続はログイン前の状態のTTYのような接続です。これは遠隔ホス
トオペレーティングシステムが、TTYがちょうど電話をしたところのように、
リンクを初期状態に扱うことを意味します。遠隔ホストは同じエコーを生み
出し、同じログイン手順を期待し、同じ割り込み文字を探すでしょう。
High Volume Transmission
大量伝送
Teletypes acting as terminals have two special drawbacks when we
consider the transmission of a large file. The first is that some
characters are special interrupt characters. The second is that
special buffering techniques are often employed, and these are
appropriate only for low-speed character at time transmission.
ターミナルの役を務めているテレタイプが、我々が大きいファイルの送信を
考慮する時、２つの特別な欠点を持っています。最初はある文字が特別な割
り込み文字であるということです。第２はバッファの特別な技術がしばしば
使用され、これらは時間的な伝達が低速の文字にだけ適切です。
We therefore define another class of connection to be used for the
transmission of files or other large volumes of data. To initiate
this class of link, user level programs at both ends of an established
TTY-like link must request the establishment of a file-like connection
parallel to the TTY-like link. Again the priority scheme comes into
play, for the higher priority HOST sends a message over link 0 while
the lower priority HOST waits for it. The user level programs are, of
course, not concerned with this. Selection of the free link is done
by the higher priority HOST.
従って我々はもう１つのファイルあるいは他の大量のデータの送信に使われ
る接続のクラスを定義します。このリンクのクラスを始めるために、ユーザー
レベルプログラムが繋がった擬似ＴＴＹリンクの両端で擬似ＴＴＹリンクに
平行して擬似ファイルリンクを接続しなければなりません。優先順位案が再
び使われます、高い優先順位のホストがメッセージをリンク０の上に送り、
低い優先順位のホストがそれを待ちます。ユーザーレベルプログラムは、も
ちろん、これに関係していません。自由なリンクの選択がより高い優先順位
ホストでされます。
File-like links are distinguished by the fact that no searching for
interrupt characters takes place and buffering techniques appropriate
for the higher data rates takes place.
擬似ファイルリンクが、割り込み文字の検索がされず、より高いデータ率に
適切なバッファ技術が使われるという事実によって区別されます。
A Summary of Primitives
プリミティブの要約
Each HOST operating systems must provide at least the following
primitives to its users. This list knows not to be necessary but not
sufficient.
それぞれのシステムを操作しているホストがそのユーザーに少なくとも次の
プリミティブを供給しなくてはなりません。このリストは必要ではないが十
分であることを知っています。
a) Initiate TTY-like connection with HOST x.
a) 擬似ＴＴＹ接続をホストｘと開始する。
b) Terminate connection.
b) 接続を終える。
c) Send/Receive character(s) over TTY-like connection.
c) 擬似ＴＴＹ接続で文字を送受信する。
d) Initiate file-like connection parallel to TTY-like connection.
d) 擬似ＴＴＹ接続と平行して擬似ファイルリンクを開始する。
e) Terminate file-like connection.
e) 擬似ファイルリンクを終了する。
f) Send/Receive over file-like connection.
f) 擬似ファイル接続で送受信する。
Error Checking
エラー検査
We propose that each message carry a message number, bit count, and a
checksum in its body, that is transparent to the IMP. For a checksum
we suggest a 16-bit end-around-carry sum computed on 1152 bits and
then circularly shifted right one bit. The right circular shift every
1152 bits is designed to catch errors in message reassembly by the IMPs.
我々はそれぞれのメッセージ本体にメッセージ番号とビットカウントとチェッ
クサムを入れることを提案します、これはIMPを通過します。チェックサムの
ために我々は１１５２ビットを「キャリ周りの終わり」合計の１６ビット値
を右回りシフトした値を提案します。１１５２ビット毎の右回りはIMPがメッ
セージを組み立てる際のエラーを受け取るよう意図される。
Closer Interaction
近い相互作用
The above described primitives suggest how a user can make simple use
of a remote facility. They shed no light on how much more intricate
use of the network is to be carried out. Specifically, we are
concerned with the fact that as some sites a great deal of work has
gone into making the computer highly responsive to a sophisticated
console. Culler's consoles at UCSB and Englebart's at SRI are at
least two examples. It is clear that delays of a half-second or so
for trivial echo-like responses degrade the interaction to the point
of making the sophistication of the console irrelevant.
上記プリミティブはどのようにユーザーが遠隔機能を単純に使用できるか提
案します。これは、ネットワークの複雑な使用がどれぐらい実行されるかに
ついて、光を流しません。特に、我々はあるサイトが高応答コンピュータと
精巧なコンソールに力を注いでいるという事実に関心があります。UCSBのクー
ラーのコンソールとSRIのエングレバートが少なくとも２つの例です。つまら
ないエコーのような回答のための半秒かそこらの遅れがコンソール能力を不
適切にするくらい対話を悪くすることは明確です。
We believe that most console interaction can be divided into two
parts, an essentially local, immediate and trivial part and a remote,
more lengthy and significant part. As a simple example, consider a
user at a console consisting of a keyboard and refreshing display
screen. The program the user is talking typing into accumulates a
string of characters until a carriage return is encountered and then
it processes the string. While characters are being typed, it
displays the characters on the screen. When a rubout character is
typed, it deletes the previous non-rubout character. If the user
types H E L L O <- <- P <CR> where <- is rubout and <CR> is
carriage-return, he has made nine keystrokes. If each of these
keystrokes causes a message to be sent which in return invokes
instructions to our display station we will quickly become bored.
我々はたいていのコンソール対話が２つの役割、本質的にローカルで即時の
つまらない部分と、そして遠隔で長く重要な役割に分けれると信じます。単
純な例として、コンソールユーザーがキーボードとリフレッシュディスプレ
イスクリーンから成り立つと考えてください。ユーザーがタイピングで話し
ているプログラムはキャリッジリターンに会うまで文字列を蓄積し、次に文
字を処理します。文字がタイプされている間、プログラムはスクリーンの上
に文字を示します。削除文字がタイプされると、プログラムは前の非削除文
字を削除します。削除が<-で<CR>がキャリッジリターンとし、もしユーザー
がH E L L O <- <- P <CR>とタイプしたら、彼は９つのキーストロークをし
ました。もしこれらのキーストロークのそれぞれが指示を返すようなメッセー
ジの送信を起こすなら、我々のディスプレイステーションは我々はすぐ退屈
になるでしょう。
A better solution would be to have the front-end of the remote program
-- that is the part scanning for <- and <CR> -- be resident in our
computer. In that case, only one five character message would be
sent, i.e., H E L P <CR>, and the screen would be managed locally.
もっと良い解決が遠隔プログラムのフロントエンドを作ることで、これは<-
と<CR>を検出し、我々のコンピュータの中にあるでしょう。このような場合、
ただ１つの５文字のメッセージが送られるでしょう、すなわちH E L P <CR>
と、スクリーンはローカルに管理されるでしょう。
We propose to implement this solution by creating a language for
console control. This language, current named DEL, would be used by
subsystem designers to specify what components are needed in a
terminal and how the terminal is to respond to inputs from its
keyboard, Lincoln Wand, etc. Then, as a part of the initial protocol,
the remote HOST would send to the local HOST, the source language text
of the program which controls the console. This program would have
been by the subsystem designer in DEL, but will be compiled locally.
我々はコンソール制御の言語を作ることでこの解決を実施することを提案し
ます。今はDELという名前のこの言語は、何の要素が端末で必要か、どのよう
に端末ががキーボードに反応するか、リンカーンワンドなどを明示するため
にサブシステムデザイナーによって使われるでしょう。それから、初期化プ
ロトコルの一部として、遠隔ホストはローカルホストに、コンソールをコン
トロールするプログラムのソース言語テキストを送るでしょう。このプログ
ラムはサブシステムデザイナーによってDELで作られるが、ローカルにコンパ
イルされるでしょう。
The specifications of DEL are under discussion. The following
diagrams show the sequence of actions.
DELの仕様書は審査中です。次の図は動作の連続を示します。
A. Before Link Establishment
A. リンクが繋がる前
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| | | |
| | | |
| | | |
| +-----+-----+ +-----------+ |
| | | | Request connection | | | |
UCLA { | | | -> over link 25 | | | } SRI
| | +-+-+ | +-+ +-+ | +-+-+ | |
| | | OS|---+-=|I|----------|I|=-+---| OS| | |
| | +-+-+ | +-+ +-+ | +---+ | |
| | | | | |
| | | | | |
| +-----------+ +-----------+ |
| HOST: UCLA HOST: SRI |
\ /
b. After Link Establishment and Log-in
b. リンクが繋がり、ログインする
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| | | |
| | | |
| | | |
| +-----+-----+ "Please send front"+-----------+ |
| | | | end control" | | | |
UCLA { | | | -> | | | } SRI ___
| | +-+-+ | +-+ +-+ | +--+---+ | | / |
| | | OS|---+-=|I|----------|I|=-+--|OS|NLS| +----+---| |
| | +-+-+ | +-+ +-+ | +------+ | | |___/
| | | DEL prog. | | | | |
| | | <- | | | |____|
| +-----------+ +-----------+ |
| HOST: UCLA HOST:SRI |
\ /
c. After Receipt and Compilation of the DEL program
c. DELプログラムの受信とコンパイルの後
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| |Trivial | |
| |Responses | |
| | | |
| +-----+------+ +-----------+ |
| | | | | | | |
UCLA { | | | Major Responses | | | } SRI ___
| | +--+--+ | +-+ +-+ | +--+---+ | | / |
| | |DEL |---+-=|I|----------|I|=-+--|OS|NLS| +---+---| |
| | |front| | +-+ +-+ | +------+ | | |___/
| | | end | | | | | | |
| | |prog.| | | | | |____|
| | +-----+ | | | |
| | | OS | | | | |
| | +-----+ | | | |
| | | | | |
| +------------+ +-----------+ |
| HOST: UCLA HOST: SRI |
\ /
Open Questions
未解決の問題
1. If the IMPs do code conversion, the checksum will not be correct.
1. もしIMPがコード変換をするなら、チェックサムは正しくないでしょう。
2. The procedure for requesting the DEL front end is not yet
specified.
2. DELフロントエンドを求める手順はまだ指定されません。
IV. Initial Experiments
IV. 最初の実験
Experiment One
実験１
SRI is currently modifying their on-line retrieval system which will
be the major software component on the Network Documentation Center so
that it can be operated with model 35 teletypes. The control of the
teletypes will be written in DEL. All sites will write DEL compilers
and use NLS through the DEL program.
ＳＲＩは現在、モデル３５テレタイプで操作できるように、ネットワークド
キュメンテーションセンターの主要なソフトウェアコンポーネントであるオ
ンラインの検索システムを修正しています。テレタイプの制御はDELで書かれ
るでしょう。すべてのサイトはDELコンパイラを書いて、DELプログラムを通
してNLSを使うでしょう。
Experiment Two
実験２
SRI will write a DEL front end for full NLS, graphics included. UCLA
and UTAH will use NLS with graphics.
ＳＲＩがグラフィックを含む完全なNLSのためにDELフロントエンドを書くで
しょう。UCLAとUTAHはグラフィックスで NLS を使うでしょう。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Celeste Anderson 3/97 ]
[ このＲＦＣは９７年３月にセレステ・アンダーソンにより機械 ]
[ 可読形式にされオンラインＲＦＣアーカイブに入れられました ]