要約

  • RFC 1921は、BullのVIP端末を画面、プリンター、画面コピー印刷という三つのアドレス付きフローに分け、同じアドレスでは未完了要求を一つに限った。
  • 先の応答より前に次の要求が届くと、その要求は削除された。ただしPROTOCOL-VIOLATIONは先の応答を送った後で返し、番号のない要求と応答の対応を崩さなかった。
  • Terminal-TypeとEORは共通の表現形式とレコード境界を合意するだけである。Mailbox、ACK、READYのいずれも、利用者の権限やホスト処理、紙への出力を証明しない。

接続単位では粗すぎた

RFC 1921は1996年3月、InformationalとしてTNVIPを記述した。対象はBullのVisual Information Projection端末である。通常のNVTと異なり、VIP端末はデータをブロックとして扱い、画面に加えてプリンターを持つことがあった。サーバーはしばしばDSAのTerminal Managerとホストアプリケーションへのゲートウェイを務めた。

この構成では、TCP接続が生きているかどうかだけを見ても足りない。TNVIPメッセージの固定ヘッダーは二オクテットで、最初のアドレスが処理面を分けた。画面は0x60、プリンターは0x68、画面コピー印刷は0x69である。

二番目のコマンド・オクテットの下位二ビットは、応答不要のindication、応答を待つrequest、待ちを閉じるresponse、そして一つを閉じると同時に次を開くresponse-and-requestを区別した。したがって状態は「接続に一つ」ではない。三つのアドレスごとに、いま何を待っているかがあった。

同じアドレスだけは追い越し禁止

要求には一般的なトランザクション番号が付かなかった。その代わり、あるアドレスで応答を待っている間は、そのアドレスへ別の要求を出してはならなかった。

二つ目が届けば、受信側はそれを削除する。それでも違反をただちに返すことはできない。次のresponseは、まだ最初の要求に属しているからだ。最初の応答を出した後で、削除した二つ目に対するPROTOCOL-VIOLATIONを送る。

エラーを遅らせることが、エラーの意味を守った。先に返せば、送信側は最初の要求が拒否されたのか、二つ目の順序が不正だったのかを区別できない。黙ってキューに入れれば、削除された事実と再送の責任が消える。TNVIPは「捨てた」と言い、その報告順も状態機械の一部にした。

一方、禁止は同じアドレスに限られている。画面の応答待ちを、プリンターや画面コピーの状態と同一視してはいけない。一本のストリームを時間順に読むだけでは、別々の台帳が見えない。

LDAP Message IDの歴史は逆方向の設計を示す。LDAPは複数操作を混在させ、番号で応答を戻した。TNVIPは番号を持たず、局所的な直列化で同じ目的を果たした。優劣ではなく、許す並行性と保持する状態の交換である。

EORは処理済みの印ではない

VIP端末はメッセージ全体を組み立ててから送る。そこでTNVIPは各メッセージをIAC EORで閉じた。RFC 885のEnd-of-Recordを、RFC 854のTelnet上で使ったのである。

受信側はこれでブロックの末尾を知る。しかし、画面が内容を処理したか、プリンターバッファに入ったか、DSAアプリケーションが受け取ったかは別である。そのためにTNVIP独自の結果コードが必要だった。境界は受領の前提であって、結果ではない。

RFCはTNVIPメッセージの内部へTelnetコマンドを挿入することも強く避けた。エスケープされたIAC IAC以外のコマンドは処理しなければならないが、実装はメッセージ途中ですぐ処理しても、メッセージ後まで遅らせてもよかった。同じバイト列でも制御とデータの相対順序が揺れる。レコード間へ出せば、その曖昧さを減らせた。

端末型とMailboxは入口を選ぶ

TNVIPへ移るにはTerminal-TypeとEORの成功した交渉が必須だった。端末型の文字列はVIPモデルを示し、任意で@Mailbox-nameを付けられた。DSAゲートウェイではMailboxが特定のアクセス点を指定し、付けなければ汎用アクセスを使えた。長さは十二文字までで、小文字は大文字として扱われた。

これはサーバー内部の選択情報であって、本人確認ではない。RFC 1091のTerminal-Type交渉も、端末モデルを述べる仕組みである。RFC 1921のSecurity Considerationsは安全性を扱っていないと明記し、特定端末を利用してよいユーザーかどうかは将来の認証課題だとした。

八ビット文字を使う場合はRFC 856のBinary Transmissionを必要に応じて交渉した。DSAのturnと送信をGAで同期させない場合はRFC 858のSuppress-Go-Aheadを使えた。これらはビットの解釈と発話順を決める。誰が話してよいかは決めない。

結果コードは住所を失うと意味を失う

画面のACKは、直前の画面データが正しく処理された場合にも、LOCAL状態要求が受け入れられた場合にも使われた。プリンターのREADYは状態照会への答えで、データ要求へのACKではない。文字列だけ抜き出したログは、異なる事実を同じ成功にする。

失敗側も細かい。ERRORは処理不良、BUSYは装置状態による削除、ABORTEDは端末オペレーターやリセットによる中断、PURGEDはpurgeによる中止、NOT-AVAILABLEは未対応装置、UNKNOWN-COMMANDは不明命令、PROTOCOL-VIOLATIONは順序違反を表した。

不明なindicationは削除して無視できた。不明なrequestは応答待ちを開いているため、明示的な返答が必要だった。重要なのは未知であること以上に、相手が結果を待つ契約を作ったかどうかである。

LOCALでも端末全体が沈黙するわけではない

端末はテストや設定変更のためLOCALへ切り替えられた。クライアントは先にLOCAL-STATE requestを送り、サーバーがACKすると、ONLINE-STATE indicationが来るまで画面とプリンターへの下りを停止した。

それでもサーバーから該当データが届けば、クライアントは削除した。画面requestならBUSYを返せた。TCPは正常で、EORも正しく、コマンドも既知なのに、結果は意図的な不受理となる。

しかしクライアント画面からの送信や別アドレスのメッセージは許された。LOCALは接続全体の障害ではなく、方向と装置に限定された運用状態だった。

一つのメッセージが許可を閉じ、結果待ちを開く

画面コピーをローカル印刷するとき、クライアントは勝手に共有プリンターを使わなかった。画面コピー用アドレスでCOPY-REQを送り、サーバーの許可を待った。許可するLOCAL-COPYはresponse-and-requestだった。

つまり、開始してよいという質問に答えると同時に、印刷結果を報告せよという新しい質問を開いた。クライアントは後でACK、ERROR、BUSY、ABORTED、PURGED、NOT-AVAILABLEのいずれかを返す。

許可と完了を一メッセージに圧縮しなかった点が重要である。サーバーは共有資源の利用を調整できる。クライアントはローカル装置を動かせる。だが紙面を見たという証拠はどちらにも自動では生まれない。RFC 1318の記事が扱う物理信号とも別の層である。

purgeは返答後の過去を消せない

各フローにはpurge indicationがあった。まだ応答していなければ、受信側は処理を止めようとし、PURGEDを返す。すでに返答済みならpurgeを削除して無視した。

取消権には時点があった。遅いpurgeは、すでに外へ出た応答を訂正したことにはならない。装置側で起きた効果を巻き戻す保証もない。プロトコル状態から外へ出た結果は、別の観測と回復手段を要する。

後世のRunning-Code Primacyは、この読み方の物差しにはなるが、RFC執筆者の動機を証明しない。文書、実装状態、物理的効果を別々の現実として扱うための現在の分析枠である。

仕様が語らない歴史を作らない

RFC 1576はTN3270の当時の慣行を記述し、既存記事がTerminal-Type、Binary、EORの組合せを扱っている。TNVIPの記事は三装置フローと要求順序を扱うのであり、同じTelnet optionを共有するだけで同じ題材にはならない。

各RFCは指定された構文と遷移を証明する。導入数、特定Bull製品の適合、実際の事故、ユーザー認証、ホスト業務の完了、印刷された紙は証明しない。Minimum Initial Specification, Localized Future Decision, and Voluntary Adoptionを現在の読みとして使えば、共通層は応答の所属を判定できるところまででよい。その先の装置判断は、観測できる実装に残る。

RFC 1921は、エラーを早く返すことより、誤った要求へ返さないことを選んだ。後着要求を捨てた事実も隠さなかった。その小さな順序規則が、一本の接続に三つの読み取れる履歴を残した。