要約

  • RFC 913は、Simple File Transfer ProtocolにASCII、Binary、Continuousの三種類を提案した。36ビット語を512個含むTOPS-20の一ページは、文書の例では順に2560、2048、2304個の八ビットバイトとして送られる。
  • Binaryは一語から四バイトを取り、残る四ビットを送らない。Continuousは語の境界をまたいで全ビットを詰める。転送が正しく終わったとしても、何が届くかはモード選択で先に決まっている。

「完了」と表示されたのでファイルを開いた。何かが足りない。そんなとき回線を責める前に、出発時の荷造りを見たい。Mark Lottorの1984年のRFC 913は、その荷造りをはっきり書いている。提案されたSimple File Transfer ProtocolはTCPの115番ポートを使う古いSFTPで、後年のSSH系ファイル転送とは同じ略称を持つ別の仕組みだ。TFTPより機能を増やし、FTPより実装を軽くし、一本のTCP接続で扱う。その中の短い命令TYPEが、ファイルをどういう単位で持ち出すかを決めた。

文書はTOPS-20を例に取る。一語は36ビット。512語のディスクページには合計1万8432ビットが入る。ASCIIモードでは、一語から七ビット文字を五つ取り出す。使うのは35ビットで、最後の一ビットは文字列に含めない。各文字を上位ビットがゼロの八ビット単位で送信し、行末はNETASCIIの規則でCRLFに直す。したがってページから出るのは512掛ける五、2560バイト。文章を異なる機械で読むためなら、その変換が欲しい場合もある。ディスク上の全ビットを持ち帰る旅とは目的が違う。

Binaryは名前が頼もしい。しかしこのRFCで一語から取り出すのは八ビットを四組、計32ビットだ。残りの四ビット、位置32から35までは送られない。ページは2048バイトになる。その四ビットが必要な情報だったかどうかは、元のファイルの使い方による。文書は特定の利用者の損失を報告しているわけではない。ただ、「バイナリー」を選ぶだけで36ビット語の全体が保存されると思うと危うい。ここで約束されるのは語ごとに四つの八ビット単位を扱うことだ。

Continuousは語の端で手を止めない。最初の語から四バイトを取ったあと、残り四ビットを次の語の先頭四ビットとつなげて一バイトを作る。そうして512語分の1万8432ビットを連続して詰めると、2304バイトになる。語の幅が八の倍数ならBinaryとContinuousは同じ実装になるはずだ、とRFCは述べる。36ビット語ではそうはいかない。一方は語から八ビットの塊を選び、もう一方はページ全体のビット列を守る。受け取った側がそのビット列をファイルとしてどう読むかは、また別の仕事だ。

操作は簡素だった。命令は四つのASCII文字と終端のNULでできており、型を指定しなければBinaryが選ばれる。サーバーは利用者名、口座、パスワードを求められ、ディレクトリの表示や移動、改名、削除、送受信にも対応する。だからこそ型を見落としやすい。転送手順が正常で、受信側が2048バイトを正確に受け取っても、原資料の意味する「一ページ」は別の規則では2304バイト分の連続ビットを持つ。確認すべきなのは通信の成功と、表現の選択の両方である。

RFC Editorの記録で、この提案の現在の分類はHistoric。三つのサイズは文書の計算例で、実際に損なわれたファイルの件数ではない。それでも同じ保存ページが2560、2048、2304バイトのどれにもなり得るという事実は鋭い。転送ソフトの「届きました」は正しいかもしれない。取り残された四ビットに尋ねれば、別の返事が来る。