要約

  • RFC 3269は、信頼性マルチキャストを単一の汎用トランスポートではなく、アプリケーションごとに異なる設計の集合として扱った。ビルディングブロック方式を文書上の契約にし、各部品に適用範囲、インターフェース、依存関係、故障境界の開示を求める一方、プロトコル・インスタンスには全体像を説明させた。
  • 中心にある警告は合成時の問題だ。二つずつなら動く部品でも、三つを組み合わせると失敗しうる。したがって再利用性は設計目標であり、互換性、安全性、展開、採用の証明ではない。

モジュール性を支える境界

Reliable Multicast Transport（RMT）が向き合ったのは、実務上の要件差だった。大量ファイル配布、対話的な共同作業、ストリーミングでは、グループ規模、遅延、順序、送信者数、不完全な配達を許容できるかが異なる。RFC 2357はすでに、要件の違いと輻輳への外部影響を提案審査の理由としていた。RFC 3269が問うたのは別の点である。すべてに合う単一プロトコルがないなら、部品を再利用する前に仕様は何を明らかにすべきか。

答えは、各部品が完全に独立していると装うことではなかった。RFC 3269は文脈に依存するビルディングブロックがあると認める。AとB、BとCはそれぞれ動いても、A、B、Cを同時に組み合わせると動かないことがある。二者の組み合わせでは見えない依存関係が、もう一つの部品を加えたときに非互換となりうる。構成図に箱が描かれているだけでは、その境界が実在する証拠にならない。

そこで部品の仕様書には、なぜその粒度を選んだのか、提供する機能と外部インターフェース、適用場面、既知の故障と検出方法、対象環境、他の部品との競合、関連するセキュリティやコードポイントの扱いを記すよう求めた。該当する場合はパケットフィールドと他の部品への要求も明示する。読者は名称から移植性を推測せず、新しい場面にその部品が合うかを判断できる。

部品と完成したプロトコルは別物

RFC 3269は、複数の部品を組み合わせて完成したプロトコルにする「プロトコル・インスタンス」の文書にも境界を設けた。対象アプリケーションと規模、含める環境と対象外の環境、既知の弱点、構成、採用部品、組み合わせ方、設計上のトレードオフを記述する必要がある。また抽象的な部品文書にない詳細を実装者に推測させず、完全なアルゴリズムとパケット形式を示さなければならない。

適合性の文言は「完全」という主張の単位を明確にした。プロトコル・インスタンスと引用する各ビルディングブロック文書がそろって、先行するRFC 2357の要件を満たす動作可能なRMTプロトコルを完全に規定する、という単位である。RFC 3269自体が試験報告になるわけでも、実装間の相互運用性を保証するわけでもない。「動作可能なプロトコル」という主張を評価する前に、読者が確認できる文書要件を定めたのだ。

パケット形式の規則はその境界をよく示す。RMTのインスタンスは当初UDP上での利用を定義し、専用IPプロトコル番号に値するかどうかは、十分に展開され理解されるまで判断を延期する。設計の完成、希少なレジストリ番号の割り当て、後の採用実績を別々に扱った。ただし、この規則は文書上の区切りであり、特定のプロトコルが広く展開された証拠ではない。

RFC 3048は、再利用できるビルディングブロックとプロトコル固有のコアの分離を説明した。RFC 3269は、著者がその分離を読み取れる形で示すための義務を整えた。2009年のRFC 5651は、初期のLCTビルディングブロック仕様を更新する際、RFC 3269のガイドラインに従ったと明記した。これは文書の系譜をたどれる例だが、全体的な遵守や展開の結果までは示さない。

歴史的な要点は「モジュール化すれば成功する」ではない。RFC 3269は適用範囲を開示した場合に再利用を論じられるようにし、完全性を各部品ではなく組み上げたプロトコルの性質として置いた。著者がレビューに供する情報は増やせるが、別々の仕様が安全に合成されることを宣言だけで保証することはできない。

出典