要約

  • 成熟したFTPでは回線上の転送バイトは常に8ビットだったが、TYPE Lの第二引数は、それとは別の論理バイト幅を宣言した。
  • 受信機は自分の語長に合わせて保存形式を選べる。ただし変換は可逆で、同じパラメータで保存・取得すれば同一ファイルを返せなければならない。
  • TYPE Iは連続したビット列を運び、TYPE Lは論理単位の境界も伝える。転送成功は、その値の意味や現在の実装普及を証明しない。

受信側の都合は、切り捨ての権限ではない

RFC 959は、36ビット浮動小数点値を32ビット語のホストへ送る例を挙げる。TYPE L 36で届いた論理バイトを64ビットのダブルワードに置けば、受信側の機械で扱いやすくできるという。空いた28ビットはFTP回線から届いた新しい内容ではない。受信機が選んだ容器の余白である。

この例の要点は古い計算機の珍しさではない。送信者、共通回線、受信者がそれぞれ別の単位を持つとき、どの層が何を決めるかである。送信者は36ビットを一つの論理単位として提示する。FTPのデータ接続は8ビット単位で運ぶ。受信者は32ビット語しか持たなくても、元へ戻せる配置を選ぶ。

受信者に保存方法の自由を与えるだけなら、36ビットの上位4ビットを捨てて32ビットに収める方が簡単だった。しかしそれでは同じパラメータで取り出しても元のファイルにならない。FTPがローカル変換に求めたのは便利さだけでなく、可逆性だった。

「バイト」は最初から一種類ではなかった

1971年のRFC 114に並ぶ型は、現在の「テキストかバイナリか」という二択よりはるかに多い。ASCIIの複数形式、EBCDIC、SIXBIT、十進・八進・十六進表現、符号方式の異なる整数、IBM 360やPDP-10の浮動小数点まで含まれていた。整数型の記述には1から255ビットまでの幅を入れられた。

型情報は解釈のためにあった。受け入れたホストは、自分の内部表現に適した形へ変換できる。36ビット語の機械が7ビットASCIIを一語に五文字詰める場合と、8ビットや9ビットの文字を四つ収める場合では、同じ物理語でも境界が異なる。

これはRFC 959のTYPE構文ではない。後世の命令を1971年の一覧へ読み込んではならない。それでも、この一覧は設計対象をよく見せる。初期ネットワークは同じ語長、文字コード、数値表現を持つ機械だけを結んだのではない。ファイル転送は、位が届いたかだけでなく、受信後にどこで単位を切るかという問題も負っていた。

1972年には回線の単位まで可変だった

RFC 354は表現型とデータ接続のバイト幅を分けた。ASCIIや印刷用表現では8ビットが決まっていた一方、ImageとLocal Byteでは別に選んだ転送バイト幅を使えた。サーバーはすべての幅を受け入れる必要がなく、効率的に扱えるものだけ実装してよいとされた。

Local Byteの変換は、転送幅とホスト固有の事情に依存した。各サイトは方法を公表し、同じ型と幅で保存したファイルを同じ条件で取得すれば同一になるよう、変換を可逆にしなければならなかった。利用者は使った表現と幅を覚えておく責任を負った。

この配置は異種機械に細かな自由を与えたが、データ接続の実装面を広げた。6ビット、8ビット、9ビット、36ビットを内部で理解できても、ネットワーク接続がそれらすべてを効率よく送受信できるとは限らない。意味の多様性と回線単位の多様性が同じ交渉面に載っていた。

回線を8ビットに固定しても、論理境界は残った

1980年のRFC 765は転送バイトを8ビットに固定した。RFC 959もその整理を継承し、FTPには区別すべき二つのバイト幅があると明記した。一つはファイルを解釈する論理バイト幅、もう一つはデータ接続で使う8ビットの転送幅である。どちらも受信機の物理的な保存語と同一とは限らない。

TYPE Lでは第二引数が必須で、十進整数として論理幅を指定する。省略時の値はない。TYPE Lと言っただけでは、連続する位列のどこを一単位として切ればよいか決められないからだ。

回線の単純化は、非8ビットデータの禁止ではなかった。可変幅の仕事を端点の詰め替えへ移したのである。送信側は論理バイトを隙間なく連結し、8ビットずつ切って送る。受信側は既知の論理幅で再び境界を立てる。

九つの転送バイトに二つのホスト語

RFC 765とRFC 959は、36ビット語を使う二台がTYPE L 36を選ぶ例を示す。二語は72ビットなので、8ビットの転送バイト九つで運ばれる。最初の論理語は四つの転送バイトを越え、五つ目の途中で終わる。二つ目はその同じ五つ目から始まる。

したがって転送バイト境界を論理境界として扱う実装は、位を一つも落とさなくてもファイルを壊せる。八ビット列のチェックサムが一致しても、36ビット境界を忘れれば元の二語を再構成できない。

逆に、この算術だけから数値形式は決まらない。36ビットを整数、浮動小数点、命令語、画像要素のどれと読むかは別の情報である。TYPE L 36は境界を示すが、符号、指数、バイト順、アプリケーション意味を普遍化しない。

パディングは末尾だけに置ける

論理幅が8の倍数でなければ、最後の論理単位を送ったあと転送バイトが満たされないことがある。仕様は必要なパディングを末尾に置くことを認める。各論理バイトを受信機の都合で8ビット境界へ丸めることは認めていない。

途中へ入れたゼロは、原データのゼロと区別できない恐れがある。末尾なら、ファイルやレコードの終端と選択パラメータを使って余りを判断できる。境界情報を持たない中継が「整形」の名で各36ビット後にゼロを足せば、それは保存変換ではなく別の符号化を作る。

Image型にも保存境界のためのゼロ詰めがある。そこでもファイルまたはレコードの末尾に限られ、取得時に除けるよう識別方法が必要だった。ゼロが見えたという観測だけではパディングと断定できない。終端、型、幅がそろって初めて説明できる。

Imageは位列、Localは単位も宣言する

Image型はデータを連続したビットとして送り、8ビット転送単位へ詰める。受信側も連続したビットとして保存しなければならない。内部構造をFTP自身に解釈させない二進ファイルには自然な選択である。

Local型も回線上では連続して詰めるが、論理幅を付ける。受信側はその境界に基づき、自機で操作しやすい可逆な形へ変換できる。二つの型は特定の機械では同じ結果になり得るが、同じ証拠を提示しているわけではない。

8ビット機でTYPE L 8を使うとImageと等価であり、二台のmビット語機でTYPE L mを使う場合もImageと同じ効果になるべきだとRFC 1123は説明する。等価性は条件付きである。未知の位列を受信側が勝手に36ビット値へ分けてよいという一般許可ではない。

共通の最低線はIとL 8だった

RFC 1123はFTPプログラムにTYPE IとTYPE L 8の対応を求める。メモリがmビット語で構成され、mが8の倍数でない機械はTYPE L mにも対応してよい。ここでのMAYは重要である。非8ビット幅を表現できることと、任意の相手がその幅を受け入れることは別だ。

TYPE L 36への否定応答は、そのセッションでその表現が受理されなかった証拠にすぎない。ネットワーク障害、ファイル損傷、容量不足を示さない。送信側はImageを選ぶ、共通の外部形式へ先に変換する、または転送を中止する判断を持つ。拒否を黙ってTYPE L 8へ読み替えると、境界を保存するという依頼そのものが消える。

同じパラメータという条件

Local変換の同一性保証には条件がある。保存時と取得時に同じパラメータを使うことだ。36ビットとして格納したものを、後日8ビットとして要求しても同一になるとは書かれていない。表現、論理幅、構造、モードは単なる接続時の操作履歴ではなく、再現に必要な来歴である。

ここでFTPの再開機構とも境界が生じる。既発表のrestart marker研究は、保存変換を行う受信側が再開位置を自分の状態として符号化する必要を扱った。今回の論点は、その変換が何を単位としているかである。マーカーが正しくても論理幅が失われれば、同じ表現を続けられない。

ALLOは論理バイトを数えるが、定義はしない

FTPのALLOは必要な保存量を論理バイトで申告できた。しかしALLOは事前資源の要求であり、活動中のTYPEがその単位を与える。36ビット論理バイトを百個と数えることと、実際のファイルを36ビット境界で可逆保存することは別の処理である。

先のALLO記事は、肯定応答が物理予約を証明しない点を扱った。本稿は、数える単位と8ビット回線の関係を扱う。正しい単位で量を申告しても予約されない場合があり、予約があっても誤った型で送れば論理構造を失える。資源の証拠と表現の証拠を一つの成功表示へまとめてはならない。

登録されたTYPEは、受理された幅ではない

IANAのFTP Commands and Extensions登録簿はTYPEをRepresentation Type命令として記録し、基礎仕様を示す。これは名称と参照先を安定させる。

登録簿から、あるサーバーが36を受け入れるか、どの保存変換を行うか、現在どれほど利用されるかは分からない。規格上の命令、実装能力、個別セッションの受理、同一ファイルの往復確認は、順に強くなる別の証拠である。

回線は運び方を定め、意味のすべては定めなかった

FTPの変化は、異種性を消去した歴史ではない。初期の大きな型一覧から、可変の転送幅を経て、8ビット回線と明示的な論理幅へ共同面を縮めた。中間の仕組みは単純になり、端点は自分の記憶装置へ合わせる余地を保った。

その代わり、パラメータを捨てることが危険になった。八ビット列だけを保存して「binary」と呼べば、転送は再現できても36ビットの単位は再現できない。FTPが線上で定義しなかったものは不要だったのではない。権威ある解釈者が後で使えるよう、端点に残されたのである。

資料と限界

根拠はRFC 114、RFC 354、RFC 765、RFC 959、RFC 1123およびIANA登録簿である。これらは設計と規範を示すが、現行サーバーの対応率、特定製品の保存形式、任意の36ビット値の意味、現在のトラフィック量を示さない。