要約

  • History Number は交渉済み圧縮バッファを選ぶ。順序、検査状態、リセット信号は履歴ごとに独立し、異なる履歴間の並び順は要求されない。
  • C/U=0 はデータ表現だけを示す。Process-Uncompressed なら、その非圧縮データでも送受信双方の履歴が更新される。
  • 1 オクテットのシーケンス、圧縮データ用 LCB、Reset-Ack は別々の境界を検査する。欠落データや PPP 上位層の到達を証明するものではない。

見えない更新

圧縮されなかったパケットは、圧縮の物語から外れたように見える。しかし RFC 1967 では、その判断は C/U だけではできない。Process Mode が Process-Uncompressed なら、原形のバイト列も履歴へ入力される。次の圧縮パケットは、その見えにくい更新を前提にできる。

Process Mode が None の場合、受信側は非圧縮データで履歴を変更しない。送信側が圧縮を試みて履歴を変えた後、MRU を守るために原形送信へ切り替えたなら、次のデータグラムまでに履歴を消去する。パケットの表面と将来の状態は同じ情報ではない。

RFC Editor と Datatracker によれば、この文書は 1996 年 8 月の Informational RFC で、Internet Standard ではない。現在の実装状況や普及率を示す資料でもない。

一つの回線に複数の時間軸

History Count が 0 なら、唯一のバッファは各データグラム冒頭で消去され、全送信パケットに R-A が付く。前のパケットに依存しないので、順序の制約は消える。その代わり、連続ストリームほどの圧縮率は期待できない。

Count 1 は継続する一つの履歴を持つ。2 以上なら各 History Number が固有のバッファ、エラー検出状態、信号状態を持つ。同一番号のパケットだけが順序を守ればよい。番号フィールドは 2–255 履歴で 1 オクテット、256 以上で 2 オクテットとなり、複数履歴を使うと圧縮・非圧縮の両方に現れる。

RFC は各履歴が論理接続を表し得ると例示するだけである。番号は加入者名でもトランザクション ID でも五つ組でもない。業務フローとの対応を主張するには、実装側の別記録が必要になる。

DCP ヘッダが往復待ちを短く見せる

RFC 1967 は、RFC 1974 の非 DCP Stac LZS 系列に、圧縮/非圧縮、R-R、R-A を持つ DCP ヘッダを与えた。RFC 1962 の一般的 CCP リセットパケットではなく、後続の LZS-DCP データパケットに履歴固有の信号を載せる。

受信失敗を検出すると、受信側は失敗した History Number で R-R を送る。逆方向に送るデータを同居させてもよい。相手は R-R をデータより先に処理して該当コンプレッサを初期化し、データを含む次の機会に R-A を返す。送るデータがなければ待つ。

R-A が証明するのは、同じパケットのデータを圧縮変換する直前に、その履歴が空だったことだけだ。送信側のシーケンス番号はリセットされず、受信側が R-A パケットを基準に期待値を合わせ直す。待機中、失敗履歴の到着データは捨てられるが、別履歴と逆方向は継続できる。

ここに復旧の上限がある。欠落、誤り、順序違反のデータグラムは戻らない。初期状態を共有し直して、その後を読めるようにするだけである。

今のサイズか、将来の辞書か

Stac LZS は最大 12.5% 拡張し得る。ヘッダ込みで相手の MRU を超えるなら、非圧縮 LZS-DCP として送らなければならない。None モードでは、拡張結果を送って履歴を残すか、原形を送って履歴を捨てるかを選ぶ。Process-Uncompressed は、原形を送りながら履歴を維持する第三の選択を可能にする。

この比較は RFC 1977 の BSD Compress、LZW、CLEAR とは別である。未圧縮パケットが辞書へ関与する点は近くても、状態機械と証拠は同一ではない。

検査値は守備範囲を越えない

履歴内シーケンスは 1 から始まり、データを含むパケットごとに modulo 256 で進む。飛びや逆順を検出するが、中身の一致は見ない。LCB は元の非圧縮データ全オクテットと 0xFF の XOR で、圧縮パケットだけに付く。1 オクテットなので衝突し得るし、暗号学的完全性ではない。

RFC 1663 の番号付き信頼転送やリンク FCS は別の層を受け持つ。IANA の PPP 登録もコードポイントの存在を示すだけで、個々のデータが正しく復号・配送されたとは言わない。

復号が成功しても、RFC 1661 の PPP プロトコル ID と Information field が上位へ渡ったかは別途確認する必要がある。RFC 1990 の Multilink シーケンス、B/E、再構成は、圧縮履歴番号とは異なる並べ替え面である。

RFC Editor の正誤表入口は調査時に利用可能な本文を返さなかったため、正誤表が空とは断定しない。また RFC 1967 自身がセキュリティ問題を論じていない。

Heng Lu の Running-Code Primacy は仕様と稼働実態を分ける編集原則を与える。Minimum Initial Specification は検証可能な最小意味を守り、Reality Layers は信号を結果へ格上げしないよう促す。Reality, Not Advocacy は構造を脚色せず記述する立場である。いずれも RFC の歴史的事実を証明する資料ではない。