要約

  • DATA は一個のピリオドだけの行で終わるため、本文の同じ行には可逆な透明化が必要だった。
  • 送信側は行頭ピリオドを二重化し、受信側は単独行を終端とし、それ以外から一個を除いた。
  • CHUNKING は正確なオクテット数と明示的な最終チャンクで境界を示し、権威を内容走査から計数へ移した。

一本のチャネルが役割を変える

RFC 821 の対話はコマンドと応答を順番に進める。DATA の間だけ同じストリームが本文になるため、いつ本文を終えて対話へ戻るかを識別しなければならない。

単独ピリオド行は簡潔だが、利用者が書ける文字列でもある。通常データと制御が同じ表現空間で衝突した。

透明化は双方の約束だった

送信側は各行を調べ、ピリオドで始まればもう一個を加える。受信側は単独ピリオドを終端とし、ほかの該当行から先頭の一個を削る。

線上の形式は変わっても、配送時に元へ戻る。RFC 821 は特にリレー変換の可逆性を求めた。片側が処理を欠けば本文は早く終わるか、余計な文字が残る。

小さな例外が全行処理へ広がった

RFC 5321 も規則を維持し、透明化で増えたピリオドを 1000 オクテットの行長制限から除外する。バッファ、ログ、リレー、試験は、保存形式・標準形式・線上形式のどれを見ているか知る必要がある。

バイト数が禁止行を消した

RFC 3030 は CHUNKING と BDAT を定義した。BDAT は直後の正確なオクテット数を宣言し、LAST が最終ブロックを示す。内容から終端を探さないため、単独ピリオド行は特別でなくなる。

サーバーは EHLO で能力を示し、クライアントは確認後だけ BDAT を使う。対応サーバーも DATA を受け続ける。新方式は旧相手を再定義せず追加された。

数えることが境界を支配した

誤った長さは境界を動かし、後続データをチャンクへ飲み込ませたり、本文をコマンド解析器へ露出させたりする。BINARYMIME が CHUNKING を必須とするのは、任意オクテットを行終端で安全に囲めないからだ。

信頼は消えず、可逆変換から正確な算術と事前合意へ移った。

情報源と限界

根拠は RFC 821、RFC 5321、RFC 3030 である。普及率は示さない。DATA は残り、透明化は暗号化や認証ではない。