ユーザー-ユーザープロトコル（提案）

以下のプロトコルは、メッセージ内の、マーキングビットの終わりからパディングビットの始まりまでの間のデータビットに適用されることを意図しています。現在の IMP-IMP プロトコルおよび HOST-HOST プロトコルは、この提案によって影響を受けません。

一般的な原理は、データの各セグメント（これは専門用語ではありません）の前に、その性質と範囲を指定する制御情報が置かれるというものです。基本的な方式は、SOS バッファリングシステムで用いられていたものから発展させたものです（JACM、1959 年 4 月の論文、とくに O.R. Mock によるものを参照してください）。

われわれの観点では、リンクは情報の搬送媒体です。情報は messages [1] と呼ばれる、固定の最大長をもつセグメントに載せて運ばれます。ユーザーの観点からすれば、そうなっているのは偶然にすぎません。ユーザーが連続したデータの流れを送りたいときには、一般にそれを（IMP-IMP や HOST-HOST プロトコルの観点とは）異なる仕方で分割するでしょう――われわれはユーザーのセグメントを record と呼びます。これが（物理的な）block という考え方と（論理的な）レコードとの間の関係と完全に類似していることは明らかでしょう。ちなみに、ファイル記憶システムも制御情報と状態情報を利用しています。われわれも同様に利用します。

USER-USER プロトコルのレベルでは、リンク上を伝送されるすべての情報は、フラグの並びと、それに続く（空であり得る）データブロックです。

一般的な形式は次のとおりです。

        OPERATION     COUNT     DATA

OPERATION フィールドは常に存在し、長さは 4 ビットです。COUNT フィールドは、存在する場合、データブロック内に続くデータバイトの数を示します。バイトサイズは（ほとんどの場合）直前の SIZE フラグによって設定されます。バイトは 0 ビットから 255 ビットまでの長さであり得ます（そうです、Virginia、System/360 を使っていても 0 は 0 なのです）。OPERATION フィールドと COUNT フィールド（存在する場合）はフラグと呼ばれ、データバイト（存在する場合）はデータブロックと呼ばれます。データブロックを伴うフラグ（カウントが 0 のために空である場合でも）はブロックフラグと呼ばれ、それ以外のフラグは whyte [2] フラグと呼ばれます。

注意すべきは、SIZE フラグが後続のブロックのバイトサイズを設定するため、バイトサイズは、送信側と受信側のプロセスの間のローカルな合意に応じて、送信側 HOST にとって、あるいは受信側 HOST にとって「自然な」値に設定され得るということです。特に、SIZE フラグは、（ASCII フラグを除く）どのブロックフラグよりも前に、各メッセージ内に現れることが要求されます。SIZE フラグは、プロトコルを実装するルーチンによって既定値として導入されてもよく、部分的には、ある種のクラスのエラーを検出する手段として意図されています。

COUNT フィールドの長さは 8 ビットです（EOM フラグの場合を除き、そこでは 16 ビット長です）。フラグは次のとおりです。

Whyte フラグ

フラグ	名称	意味
0	NUL	無操作 (次のフラグを検討する)
1	RS	レコード区切り (レコードの終わり)
2	GS	グループ区切り (グループの終わり)
3	FS	ファイル区切り (ファイルの終わり)
4	ESC	フラグに関するローカルな取り決めへのエスケープ
5		(後で割り当てるために予約)
6	EOM N	メッセージの終わり (N は総ビット数)
7	SIZE N	バイトサイズは N ビット
8	IGNORE N	後続のデータビットを無視する

ブロックフラグ

フラグ	名称	意味
9	SYS N	受信側 HOST システムのための N バイトのデータ
10	CONTROL N	N バイトの制御データが続く
11	STATUS N	N バイトの状態データが続く
12	LABEL N	N バイトの識別データが続く
13	KEY N	N バイトのキーデータが続く
14	ASCII N	N バイト (8 ビット) の ASCII データが続く
15	BLOCK N	N バイトのデータが続く

私は SIZE の要件についてはすでに述べました。ブロックフラグ（ASCII を除く）を含むどのメッセージにおいても SIZE フラグが存在しないことは、明確な誤りです。EOM は、部分的にはもう一つのエラー検査の仕組みであり、部分的にはパディングという難問を回避するための仕組みです。ユーザープログラムは入力時に EOM を決して見るべきではありません。ユーザーは伝送を強制するために EOM を書いてもかまいません。EOM は、メッセージ内の有用な情報の終わりを区切り、情報の欠落の可能性を検査するために、マーキングに続く最初のビットから始まり EOM カウントフィールドの最後のビットで終わる、メッセージ内の総ビット数を再掲します。これは、IMP-HOST の電気的インターフェースおよび HOST の mushyware における誤りに対する検査です。EOM は、ESC が現れない限り、各メッセージの終わりに現れなければなりません。

ESC は、（願わくば）使われないための逃げ道として意図されており、どのリンク上でも USER-USER プロトコルの 4 ビットより多くを使うことを避けたいと望む施設および／またはアプリケーションが使わないためのものです。たとえば、メッセージの境界さえ無視して、リンクをビットストリームとして使いたいと思うこともあるでしょう。無政府主義者たちがローカルな合意に達することができたなら、彼らの健闘を祈ります！

NUL と IGNORE は、後続のデータブロックの最初のビットを都合のよいアドレス境界に置けると助かる場合に備えた、スペース埋めとして意図されています。(とくに親切な HOST の割り込みルーチンは、メッセージを受信するときに、マーキングビットの上に NUL と IGNORE の組み合わせを貼り付けることさえあるかもしれません――その場合、それらのビット数は、EOM のビット数検査を補正するために GET ルーチンへと伝えられるべきです)。区切り操作は、論理レコード、グループ、ファイルという考え方を導入します。具体的には、レコードが完全に一つのメッセージ内に収まっていることや、一つのメッセージにただ一つのレコードだけが含まれることは要求されていません！さらに、一つの接続の間にただ一つのファイルだけが伝送されることも要求されていません。たとえば、ユーザーはリンクを使って一群のルーチンを伝送し、その後でそのリンクを別のことに使いたいと思うかもしれません。

したがって、ローカルな合意によって、単一のルーチンがグループを形成する多数のレコードからなっていてもよく、その全体の集まりがファイルを形成していてもよく、FS フラグを受け取った後もリンクが接続されたままであってもかまいません。

各種のブロックフラグの解釈も同様に、ローカルな合意に委ねられています。純粋なデータを伝えることを意図した二つのフラグは ASCII と BLOCK です。それらの違いは（プロトコルに関する限り）ただ一つ、バイトサイズが ASCII では暗黙であり（8 ビット）、BLOCK では明示的である（直前の SIZE フラグのカウントフィールド）という点だけです。しかし、これを超えて、ASCII に続くブロックの意味的な内容は、ASCII に関する現在の標準によって規定されます。EBCDIC の情報は ASCII ブロック内で伝送してはなりません！！

CONTROL と STATUS は、ユーザープロセス間で制御情報をやり取りするためのものであり、それらに伴うデータブロックの解釈はローカルな合意に委ねられています。一般には、CONTROL は「次のことをやってみてください」を意味し、STATUS は「でも、先生、私はこう感じているんです」を意味します。CONTROL フラグは、遅かれ早かれ、あるいは決して、STATUS フラグの返送を促します。LABEL は、ファイルまたはグループのレベルで、後続のデータ単位を識別するために用いられることを意図しています。ここでもまた、具体的な解釈はローカルな合意の問題です。KEY は、アドレスまたはキーという考え方を模倣することを意図しています――これはレコード、データ項目、あるいは物理的な記憶ブロックのレベルです。PDP-10 システムおよび／または OS/360 に馴染みのある方のために、指針として以下の対応が挙げられます。

   USER-USER protocol      OS/360            PDP-10
   __________________      ______            ______

     CONTROL               OPEN              OPEN

                           CLOSE             CLOSE

     LABEL                 DSCB              File retrieval information

     KEY                   KEY               USETI/USETO argument

     CONTROL               READ              IN/INPUT

                           WRITE             OUT/OUTPUT

                           ALLOCATE ?        ENTER

                           OPEN ?            LOOKUP

     STATUS                ?                 GETSTS

上記の「?」の表記は、きわめて直接的な対応物が存在しないことを示しています。注目に値するのは、OS/360 の GET と PUT が、レコードという考え方を具現化する USER-USER プロトコルのどんな実装においても直接の対応物をもつということです。われわれのプロトコルの実装は、IMP 通信だけでなく、ディスクおよびテープ記憶を伴うすべての PDP-10 の入出力に対して、この考え方を導入することにつながるでしょう。

MULTICS の用語を知っていれば、上記の対応物の集合をより正確に拡張できるのですが。私の用語は、明示的な入出力命令をもつシステムから取ってきたものですが、この仕組みが制御とデータの通信を一般に扱うことを意図している点を強調しておきたいと思います。MULTICS は、外部記憶と内部記憶の古典的な区別が（ユーザーの観点から）ぼやけているシステムであり、私は USER-USER プロトコルにおいても同じようにぼやけてほしいと願っています。私は SYS を、わずかな不安とともに差し出します。一般的な考え方は、外国のユーザープロセスを仲介者として経由するのではなく、外国の HOST と直接通信できるべきだというものです。SYS は UUO や SVC のようなものですが、私の HOST ではなく外国の HOST が消費するためのものです。HOST の観点からすると、実装上の問題は、どのローカルなユーザープロセスとも結びつかないプロセスコンテキストレコードを確立することにあります。しかしこれは、われわれの現在の LOGON という難問と強く結びついています。たとえば PDP-10 では、ユーザーは多かれ少なかれローカルのテレタイプ回線と同一視されており、どんなリンクもそれらのどれでもありません！したがって、外国のユーザーがログオンできるようにするには、ごまかしが必要です。OS/360 は、それ自身の流儀で同程度に（実際には、より）ひねくれています。

外国のプロセスを私のローカルシステムにログオンさせる処理は、（おそらく MULTICS を除けば）それを担当する特別な (!!) ユーザージョブが存在するという単純な話ではありません。他の何かが可能であるならば、HOST は、要求を行ったプロセスからあらゆる意味で独立したプロセスを確立するために必要な情報を与えるシステム命令（UUO や SVC など何であれ）を提供しなければなりません。そうでなければ、どんなシステムにとっても妥当な自己保護の仕組みが、われわれ全員を望ましい以上にはるかに相互依存させてしまうでしょう。これを行うには、あらゆるシステムに、正しいことを行う UUO/SVC（ATTACH だが、私のことは忘れてくれ）が存在しなければなりません。これが真であるなら、Network を介した LOGON 処理は、Network 内の別のノードによる外国の UUO/SVC の発行に等しいものとなります。これの回避策として妥当なものは私には思いつきません。もしそうなら、SYS N は必要なデータを伝えるために使うべき種類のフラグです。もしそうなら、SYS に、ユーザープログラムとオペレーティングシステムのインターフェースのレベルで任意の OS 命令の要求を伝えさせることが妥当なだけです！

実装の実際的な問題は、また別の話です！PDP-10 の場合、SYS を、場合に応じて、モニタコマンドを実行するための LOGON 要求か UUO のどちらかに変える方法は、かなりよく分かります（両者が同じであればよいのですが）。残念ながら、OS/360 はもっと洗練されています。MULTICS ならできるかもしれません。とはいえ、われわれがやりたいこと、すなわちプロトコルが反映すべきことは、特定の HOST システムの文脈でそれをどう行うかという問題とはまったく別の問題であることを明らかにしたいと思います。われわれがやりたいことは、一般的には、プロトコルに関する限り、相手にしているシステムからかなり独立しており、それらが特定の実装の実際においていかに翻訳されなければならないかが不確かであるという理由だけで、一般的な考え方をプロトコルに導入することを怠るべきではありません。