はじめに

我々は、Meyer 提案 (Note #46) が、彼が列挙したとおりの理由、すなわち簡潔であり、ネットワークの計画されたほとんどの用途に十分であり、実装が容易であり、拡張可能であるという理由から、これまでで最も受け入れられるものであると考える。ただし、最近提案されたすべてを網羅しているわけではない。しかしながら、我々は提案された項目には同意しており、欠けている機能は、争って仕様の策定を遅らせるほどの価値はおそらくないと考える。

我々は、Note #47 で提起された七つの問題について以下のコメントを行う。

我々は、動的再接続が後にネットワークのより高度な用途のために必要となるという Steve の意見に同意する。また、初期には不要であるという Project MAC の人々の意見にも同意する。ネットワークの使用経験とその用途の具体的な必要性があれば、動的再接続はよりよく実現できるであろう。
INT は実装が容易であり、有用な目的に資する。
我々は、インスタンスタグ識別子のためのサブフィールドを含めることを支持する。両方の場合に必要があると考える。a) 複数のプロセスが区別できないように見えるべき場合、および b) 複数のプロセスを所有する特定のユーザーがそれらを区別しなければならない場合である。プロセスを区別すべきでないプログラム部分は、単にインスタンスタグを無視すればよい。ユーザー番号サブフィールドの一部を使うという Tom の提案は、サブフィールドの合計長を 32 ビットから 24 ビットに減らすだけであり、問題は残る。
我々は、送信されるデータに特別な構造を課すべきではないという点で、Steve と MAC の双方に同意しない。我々は、E. I. Ancona が Note #42 の 1 ページ目で述べた「message data type」を好む。その使用例は Note #39 の 2 ページ目に引用されており、transmit 対 broadcast である。標準文字セットについては、当初から採用することを強く支持し、とくに ASCII を支持する。ほとんどのサイトが以前から ASCII を提案していたことを我々は観察している。異議を唱える者はいるだろうか。
ワード境界の整列は二重パディングよりも魅力的である。
RFC を短期的にキューイングするという Steve の提案は、選択肢として受け入れられる。
我々は Note #46 の UCC を支持する。主な理由は三つある。
1. 一般に、ユーザーは自分が通信したいプロセスの遠隔ソケットコードを知るべきではない。
2. 追加の二重接続は、プロセスの動作に対してある程度の監視的な制御を提供でき、場合によっては割り込み手順と組み合わせて用いることができる。
3. その他の提案された方法のほとんどはキューイングを必要とする。
標準の UCC が存在しなければならないと考えるが、並行的な実験的 UCC を奨励する。

我々は、Note #47 で繰り返されなかった Note #46 に関する二つの追加コメントを行う。

BLK と RSM は以前の提案よりも明快であり、与えられたリンク上での多重化を否定しない。リンクの使用については、中間 IMP が停止して誰かの RFNM を食ってしまったという Bob Kahn の例を挙げる。これは再接続を必要とすべきではない。

Note #46 の 6 ページ目にある、UCC が死んだプロセスへの接続を閉じる能力を持つという記述は、設置環境に依存する。我々の特定のケースでは、NCP はプロセス障害を直接通知される。すべてのプロセス (NCP を含む) が通信しなければならない特定のソフトウェアインターフェースによるものである。

JFH:hs

注: 本 RFC は、Gary Okada によって 7/97 に、オンライン RFC アーカイブへの登録のために機械可読形式にされた。