要約

  • STRU RとMODE Sでは、全ビット1のエスケープに1を続けるとEOR、2ならEOF、3なら同一点でEORとEOFを示した。
  • 全ビット1そのものがデータなら二度続けた。受信側は交渉済みの構造と、読み取りをまたぐ解析状態を保持しなければならない。
  • BLOCKとCOMPRESSEDは境界を記述ビットへ移した。境界の意味はファイルに属し、TCPセグメント、受信バッファ、表示上の改行から推測するものではなかった。

一つ目だけでは決められない

全ビット1が二つ並んだとき、受信後のデータは一バイトである。RFC 765とRFC 959は、二つ目も同じ値ならセンチネルのリテラル表現として扱うよう定めた。

二つ目が1ならレコード終了、2ならファイル終了、3なら最後のレコードとファイルが同時に終わる。一つ目は単独で制御ではない。後続バイトと、制御接続で先に選んだSTRU Rが意味を完成させる。

この二重化は、制御のために予約した値をデータへ返す引用規則である。送信バイト数が復元データ数より多くても、圧縮解除や重複障害とは限らない。

ストリームとレコードは別の契約だった

STRU Fは連続するデータバイト、STRU Rは順番を持つレコード列を宣言した。一方、MODE Sはデータ接続上の表現を選んだ。構造とモードは別軸である。

順序どおり届くストリームは、元ファイルのレコード境界を知らない。FTPはレコード構造で全EORを明示し、最後のEORも省かなかった。送信ホストはローカルな区切りを共通表現へ変換し、受信ホストが自分の保存形式へ戻した。

IBM系のローカルなレコード長フィールドを別のホストが理解できる保証はない。FTPが共通化したのはディスク形式ではなく、「ここで一レコードが終わる」という意味だった。

四つの後続がデータと構造を分けた

通常データはそのまま出力できる。全ビット1を読んだ解析器だけが待機状態に入り、次の値で四通りに分岐する。リテラルを一つ出すか、EOR、EOF、または両方を発生させる。

値3の組合せは、最終レコードの後に架空の空レコードを置かずに二つの終了を表せる。二重センチネルは、予約値を含むあらゆるバイト列を復元可能にする。

センチネルを見た瞬間に境界を作る実装はリテラルを壊す。二重化した二バイトを両方データへ残す実装も壊す。生の転送列、復元データ、境界イベントは別々に数える必要がある。

読み取りはペアの途中で終わり得る

RFC 9293のTCPは、信頼できる順序付きバイトストリームを提供する。FTPのレコードや、一回の受信呼び出しに対応する単位は提供しない。

したがって、ある読み取りの最後がセンチネルで、判別値は次の読み取りに来てもよい。一つのバッファに両方が入っても意味は同じである。TCPセグメントやバッファの端をEORに変換すれば、送信側が宣言していない境界を作ることになる。

接続が正常に閉じても、センチネル待機状態なら文法は未完了である。テストは意図的にこの位置で読み取りを分割しなければならない。

STRU Fでは同じ値が普通のデータに戻る

STRU F + MODE Sでは、すべてのバイトがデータであり、データ接続の閉鎖がEOFを示す。全ビット1はエスケープではなく、二重化も不要である。

つまり、オクテット列だけを保存しても意味は確定しない。対応するSTRUとMODEの時間軸がなければ、同じ二バイトを一つへ戻すのか二つのデータとして残すのか、境界として読むのか判断できない。

終了証拠も異なる。ファイル構造では閉鎖が通常のEOFになる。レコード構造では最後を含むEORが明示される。単に「接続が閉じた」と記録するだけでは、最後のレコードが閉じたか分からない。

他モードは境界の置き場所を変えた

BLOCKモードでは各ブロックに長さと記述ビットが付いた。一つのビットがEOR、別のビットがEOFを示し、同時に設定できた。疑わしいデータと再開マーカーにも別ビットがあった。

COMPRESSEDもEOR/EOFに記述形式を使い、反復データやフィラーの表現を加えた。レコード境界の意味は維持されるが、線上の形はMODEに依存する。

同じ論理レコード図が異なる生バイトになり、同じ生バイトが異なる交渉で違う意味を持ち得る。証拠には制御交渉、転送ストリーム、復号後の構造図がすべて要る。

改行はEORの代用品ではない

FTPはend-of-lineとend-of-recordを区別した。レコード構造を持たないASCIIテキストならCRLF、EBCDICならNLを行区切りに使えた。STRU RのEORはそれとは別に明示された。

一行一レコードのファイルでは両者が一致して見える。しかしレコードは複数行を含み得るし、改行は表示上の効果かもしれない。非テキストレコードには行そのものがない。

RFC 959はASCII/EBCDICテキストでレコード構造を受け入れ、ファイル指向とレコード指向のホスト間変換を有用かつ可能な限り可逆にするよう求めた。読めることと、元の区切りを保存したことは同じではない。

後年の要件は保存方法の違いを認めた

RFC 1123は、レコード構造を必須とするのを、それを支えるファイルシステムを持つホストに限定した。持たないホストもSTRU Rを受け入れ、バイトストリームを文字どおり保存できた。

符号化された流を保存することは、ローカルなレコードを再構築したという主張ではない。正確な後日復元の材料は守れるが、アプリケーションが直ちにレコードを利用できるとは限らない。再構築、保存、平坦化、拒否を区別すべきである。

RFC 5797とIANAのFTP Commands and ExtensionsはSTRUとMODEの基礎語彙を保存する。登録はRの受理、読み取りをまたぐ状態保持、ラウンドトリップを証明しない。

デコーダも証拠の対象になる

監査記録にはTYPE、STRU、MODE、生ストリームと復元データのハッシュ、両方の長さ、全EOR/EOF位置、閉鎖、解析器の終状態、保存後の復元結果が必要である。

カナリアは二重センチネル、三つの制御、読み取りをまたぐペア、連続境界、同じ構造のSTREAM/BLOCK表現を含める。未完のエスケープ、不明な後続、最終EOR欠落、MODE変更後の状態残留は解釈失敗である。

バイトが二度必要だったのは、ネットワークが複製したからではない。FTPが制御入口を確保しながら、正当なデータ値を失わないようにしたからである。

出典