要約

  • RFC 3485 は全 SIP/SDP SigComp 実装に同一の不変かつバイト単位で確定した静的状態を持たせ、最初のメッセージから共通知識を参照可能にした。
  • 附属書の語句表は材料の説明であり、相互運用を支えた規範は第3節のバイナリ値、識別子、長さ、正確なアクセス区間だった。

圧縮は通常、以前のメッセージから反復を学ぶ。最初の SIP メッセージには以前がない。RFC 3485 は、通信前に同じ辞書を両端へ置き、まだ存在しない共有履歴を先に作った。

その仕組みには厳しい条件があった。SIP/SDP 用 SigComp 実装は一つの固有辞書を必ず持ち、その辞書は SIP や SDP の発展に合わせて変化してはならない。一度だけ定義し、そのまま残す。だから最初の送信前に相手の版を確認する必要がなかった。

合意対象は語句の概念ではなく、特定の SigComp 状態だった。第3節は完全な状態識別子、0x12E4 の長さ、最小アクセス長六オクテット、全バイナリ値を固定した。例の STATE-ACCESS は六オクテットの部分識別子を使うが、SigComp の照合規則によって同じ完全状態を選ぶ。

附属書 A と B は SIP/SDP の入力文字列、優先度、オフセット、長さ、根拠文書を読みやすく示す。しかし情報提供である。規範的な辞書は第3節のバイナリ表現だ。同じ単語を集めても一バイトの配置が違えば、同じ状態ではない。

状態値は二領域を連結した。文字列サブセットは各材料を部分文字列として含む。表サブセットは一バイトの長さと二バイトのオフセットを持ち、オフセットへ 1024 を加えて UDVM アドレス 1024 の状態を直接参照できる。LZ78 系は表を初期トークンにも使えた。

共通部分は重ねて節約された。一つの接頭辞から複数のヘッダーを組み立て、応答コードはコード単独と推奨理由句付きの別エントリーを持てた。論理上は二つでも、物理的には同じバイト領域を共有できる。

メッセージの書式も証拠だった。照合は大文字小文字を区別し、ヘッダーは前の CRLF、コロン、期待される空白まで含む場合が多い。文法上有効な別の空白を使えば、辞書の利益は小さくなり得る。同じ意味は同じバイトではない。

一から五の優先度は出現頻度の設計予想であり、実測ではない。低い番号ほど頻出と考えられ、一部アルゴリズムが効率よく参照できる位置へ置かれた。後年のネットワークのトラフィック分布を証明しない。

優先度はメモリ制約時の切り出しにも使われた。優先度一だけ、一から二、一から三、一から四について、文字列と表の正確なオフセットと長さが示された。小さい区間を読むことは別版の交渉ではなく、同じ不変状態の範囲選択だった。

したがって「静的辞書を使用」というログだけでは足りない。部分識別子、オフセット、長さ、文字列か表か、優先度区間を保存する必要がある。それでも証明するのはアクセスであり、解凍成功ではない。

解凍成功も SIP/SDP の妥当性、認証、配送、セッション成功ではない。RFC 3320 は UDVM と永続状態のアプリケーション認可を扱い、RFC 3321 は動的状態の確認と寿命、RFC 3322 は性能モデルを扱う。RFC 3485 はそれ以前の静的共有記憶だけを所有する。

RFC 3486 は SIP での SigComp 表示、RFC 4464 は利用ガイド、RFC 4465 はアクセス試験、RFC 4896 は優先配置の説明、RFC 5049 は SIP 実装の対応義務を示した。RFC 5112 は presence 用に別状態を作り、元の辞書を更新しなかった。

セキュリティ節は RFC 3320 を参照し、既知の追加リスクなしとしただけである。正しい辞書識別子は送信者の身元、権限、完全性、配送を証明しない。

実運用の圧縮率も示していない。最初のメッセージに有利という設計理由と、特定回線での観測値は別である。アルゴリズム、内容、書式、切片、回線条件が結果を左右する。

Heng Lu の現実レイヤーに従えば、完全状態のハッシュとメタデータを最初に確認する。次に部分識別子と STATE-ACCESS の全オペランドを保存し、対象バイトを解決する。解凍トレースを照合し、その後にだけプロトコル解析、認証、配送、結果を結ぶ。

RFC 3485 は最初のメッセージに借り物の過去を与えた。その過去が共有できたのは、辞書が改訂可能な本ではなく、封印されたバイト列だったからである。

出典