はじめに

Network 上の通信が入出力の特殊な場合にすぎないように見せることには、多くの立派な理由があり、おそらく一つか二つは悪い理由もあるでしょう――少なくとも、ユーザープログラミングに関する限りは。たとえば、HOST-HOST プロトコルと Network Control Program を実装するための Harvard のアプローチでは、各リンクを PDP-10 の用語で「論理デバイス」として扱っています。接続の設定はローカルなデバイスの割り当てに似ており、リンク上の通信は標準のシステム入出力 UUO を利用することになります。これにより、既存のプログラムを変更なしに Network と組み合わせて使うことが可能になります――少なくとも、相手が他の PDP-10 である場合には。

しかしながら、これで済むのはそこまでです。PDP-10 には「論理デバイス」という考え方は存在しません。それが存在するのは IBM 360 です（ここではオペレーティングシステムとユーザープログラムのインターフェースのレベルで話しています）。さらに、整数や実数などの固定表現を要求する Network 標準が存在しない場合（私なら反対しますが）、任意の一対のユーザープロセスはローカルな合意に達しなければならず、必要に応じてデータ変換の負担を一方または双方が負わなければなりません。どんな標準プロトコルであっても、そのような合意を表現できるようにし、少なくともそのような合意が実際に機能するための最小限の制御情報を収容すべきです。最後に、IMP-IMP プロトコルと HOST-HOST プロトコルは、ユーザープロセスが要求した動作が実際に相手のプロセスによって達成されたかどうかを検査する手段を提供していないことに注意しなければなりません。この種の問題は、常に USER-USER プロトコルのレベルで扱われるべきものと見なされてきました。

この提案は、上記の三種類の問題に、ある程度までは対処しようとするものです。その程度は、私がどんな USER-USER プロトコル提案でも判断に用いるであろう基準を述べることによって、最もよく説明できるでしょう。

（論理的な）record という考え方が存在すべきであり、message という考え方は抑圧されるべきです。(FORTRAN プログラマにとって、FORMAT を伴わない一つの WRITE 文で書かれるものがレコードです。OS/360 の機械語プログラマにとって、PUT が書き込むものがレコードです)。
HOST システムおよび／またはライブラリルーチンにおいてプロトコルをそのように実装し、現在存在するユーザープログラムがプログラムを変更することなく Network 内のどこにあるファイルにもアクセスできるようにすることが可能であるべきです。(少なくとも当初は、この能力は同じタイプの HOST システムに限定されなければなりません)。
プロトコルは、任意の HOST システムにおいて SVC または UUO のレベルで実装可能であるべきです（必ずしも実装される必要はありません)。関係する相手 HOST の特性に関する特定の知識は不要であるべきです。

上記は、少なくとも第二の基準が成り立たないそれぞれの場合において、一部のユーザープログラムが相手 HOST の性質を認識していなければならないことを意味していることに注意すべきです。現在その基準が成り立たない場合について前進する（あるいは見切りをつける）につれて、システムの違いを吸収する負担は、プロトコル（すなわち HOST システム）における実装へ、あるいは既定ではユーザープログラムへと移っていくでしょう。

きわめて明らかなことですが、今日開始されるどんな提案も、それが最終的な問題をどの程度「解決」するかという点で疑わしいものとされるべきです。どれほど野心的であるべきかは、まったく好みの問題です。現段階では、私は、われわれ全員が使えると信じるもの（したがって、やる価値のあるもの）で、われわれの短期的な問題の解決に向けて相応の距離を進み、実行が容易で、長期的な観点でも存続の見込みを与えてくれるものを試すことを好みます。以下では、提案そのものを、その各部分について（願わくば）適切な動機づけの議論とともに述べるつもりです。その後、われわれが Harvard で PDP-10 向けに行っている具体的な実装を概観し、それを Network 内の他の PDP-10 上へのファイルの格納という具体的な場合にどう適用するつもりかを述べます。