要約

  • RFC 3930 の文書視点は、人が全体として知覚する準静的なデジタル物を指す。RFC 仕様書と実装コードの対比ではない。
  • プロトコル視点では、部分ごとの処理、非同期な拡張、適切な正規化、選択的な保護、合成時の ID 衝突を先に設計する。

紙の比喩が消した経路

RFC 3930 は DOCUM と PROTO を意図的に誇張した。前者は表示まで含む完成物、後者は状態を持つプロセスが生成・消費する一時的な複合物である。公式記録は Informational で、配備状況を報告する文書ではない。

ある要素は過去のメッセージから、別の要素はローカル計算から生じる。中継者が一部だけ読み、残りを次へ渡すこともある。RFC 3023が XML の表現を識別し、RFC 3470がプロトコル利用を論じても、媒体型だけで状態遷移は証明されない。RFC 3552の脅威分析や RFC 3852の暗号構造も、権限や配送結果とは別の証拠である。

新しい部分を全員が同時に知ることはない

RFC 3930 は、版や機能の表示、可能な場合の交渉、未知部分を飛ばせる長さ、理解せず後段へ渡すための宛先表示を挙げた。これは混在を扱う手段であり、端から端までの成功証明ではない。

後の RFC 8259 は JSON、RFC 8785 は署名向けの JSON 正規化、RFC 8949 は CBOR の決定的符号化を扱った。一つの値に見えても、比較するバイトを作る規則が必要だった。

正規化には狭すぎても広すぎても危険がある

RFC 3076、RFC 3741、RFC 3275は XML の正規化と署名処理を定めた。正規化が不足すれば改行や名前空間の無意味な差で検証が壊れる。過剰なら、意味のある変更を消して署名を通す。アプリケーションが同じと見なす範囲だけが正しい境界である。

RFC 3930 自身にも小さなずれがある。本文は正規化の参照として [RFC3741] を挙げるが、参考文献欄はそのラベルを GMPLS の RFC 3471として展開する。2026年10月7日のerrata 検索には対応項目がなかった。主張を無効にする欠陥ではなく、ラベルと実対象の照合が必要だという限定的な実例である。

短い内部 ID も、別々の部品を合成すると衝突する。書き換えれば参照や署名を壊し、階層化すれば移動時にアンカーが変わる。RFC 3930 は必要な場合に十分長いランダム ID を選ぶ方向を示した。

RFC 7990が定める RFC シリーズの保存形式は別の層である。仕様文書を保存する規則は、そこに記されたプロトコルの処理規則ではない。Heng Lu の最小初期仕様と自発的採用およびランニングコード優先という視点を合わせると、公開は調整材料であり、実装・検証・運用・利用が現実化の証拠になる。人向け表示が一枚でも、その下の遷移は一枚ではない。