要約

  • Obsoletesは文書の系譜について権威を持つ。新しいRFCが現行の仕様または実務を理解する一般的な起点となり、古いRFCは恒久的なアーカイブに残る。
  • この関係だけではソフトウェアは修正されず、機能も停止せず、製品も撤去されず、法的禁止も生じない。それぞれ別の主体と証拠を必要とする。
  • HTTP/2では参照文書が変わってもワイヤ上の識別子が続いた。TLSでは正式な廃止勧告の後にも旧版依存が残り、安全性と相互運用性の損失を運用者が判断しなければならなかった。
  • 完了を示すのは新しい番号ではなく、文書関係、ロード済み版、依存先、試験、例外責任者、ロールバック条件、実利用の消滅を結んだ移行記録である。

カタログだけが先に動く

RFC 9113の先頭には、RFC 7540とRFC 8740をobsoletesするという関係が記されている。RFCシリーズでは重要な変更だ。現在のHTTP/2を調べる読者はRFC 9113から始める。旧文書の記録には後継文書が示され、IANAの一部参照も更新される。新仕様への適合を主張する実装は、変更点を無視できない。

それでも出版行為はサーバーの管理権限を得ない。既に配布されたライブラリは書き換わらず、プロキシの設定は変わらず、旧優先度の挙動も自動では消えない。規範上の出来事は本物だが、最初に変わる対象は文書記録である。

この境界はIETFの力を弱めない。どの文書が現行仕様かを決めること、公開済み文書を保存すること、プロトコル登録の参照を正確にすることは、いずれも不可欠である。そこから他者の装置を変更する権限まで推定すると、障害の時刻を誰が選び、誰が損失を受け入れたかが見えなくなる。

組織には境界を消す誘惑がある。コンプライアンス表の番号を変えるのは安い。実際のクライアント、組み込み機器、中間装置、取引先を調べるのは高い。文書の更新を導入完了として報告できれば、複雑な設備を調べずに緑色の指標を得られる。

問題はカタログが弱いことではない。カタログに機械の状態まで証言させることである。

置き換えても消去しない

RFC Editorの説明では、公開済みRFCの本文は変更されない。改訂や置換には新しい番号を与える。Obsoletesは、新文書が列挙された旧文書に代わり、現行仕様または実務を理解する一般的な資料になることを示す。旧文書はRFCシリーズの恒久アーカイブに残る。

保存には実務的意味がある。古い製品が当時どの規則を実装しようとしたかを再現できる。事故時に、挙動が旧仕様由来か、新仕様への不完全な対応かを区別できる。過去を削除すれば一覧はきれいになるが、責任の証拠は弱くなる。

RFC 7322はUpdatesとObsoletesを文書ヘッダーの情報として定め、置き換えられたRFCを新しいRFCと併記して参照する場合があることも認める。本文を上書きしないシリーズは、明示的な関係によって進化する。

したがって、この関係は単なる注釈ではない。RFC 9113への適合を名乗りながら、都合のよいRFC 7540の規則だけを選ぶことはできない。一方、関係が直接証明するのは文書の現在であって、パッチ適用、設定停止、製品撤去、契約変更、行政上の禁止ではない。

「廃止」に折り畳まれる六つの行為

第一は文書の置換である。標準化手続が新しい参照文書を確定し、アーカイブが新旧を結ぶ。

第二は状態または適用範囲の変更である。Historicへの移行、Best Current Practiceの改訂、適用性声明により、許容される利用がさらに狭まることがある。

第三は機能の非推奨化である。プロトコル名を維持したまま、一つの経路や機構を削除、縮小、非推奨にできる。

第四は実装変更である。保守者がソースを直し、リリースとバックポートを作り、対応ブランチを決める。修正が存在することと、顧客がロードしたことは違う。

第五は導入判断である。運用者が対象を発見し、依存性を試験し、段階的に設定を変え、失敗を観測し、例外を期限付きで認める。この段階で停止と残余リスクを引き受ける。

第六は外部の義務である。顧客、契約、保険、調達規則、規制機関、裁判所が独自の権限で撤去を求める場合がある。その根拠はRFCヘッダーではなく、契約または法にある。

一つの行為が次を促すことは多い。だが原因と権限は同じではない。RFCがリリースを促したとしても、標準化機関が顧客設備を変更したことにはならない。

逆方向の誤りも避ける必要がある。「RFCは文書にすぎない」と言って要件を無視しながら、新仕様への適合を主張することはできない。標準は共通挙動を定義する。本稿が否定するのは規範の意味ではなく、実行権限への飛躍である。

HTTP/2は新番号になってもh2である

RFC 9113には実質的な変更がある。RFC 8740に分かれていたTLS 1.3の扱いを取り込み、検証規則を絞り、平文アップグレードや優先度の扱いを見直し、Hostと:authorityの関係を明確にした。付録Bは差分を列挙しており、単なる再版ではない。

同時に、ALPN識別子h2は残った。フレーム種別、設定、エラーコードのレジストリも続く。IANAは参照を新文書へ更新したが、改訂版HTTP/2のために別のワイヤ識別子を作らなかった。通信相手が合意するのは機能であって、RFC番号ではない。

個別機能にはより強い変化がある。HTTP2-Settingsヘッダーとh2cアップグレードトークンはobsoleteとされ、RFC 7540の優先度方式はdeprecatedとなった。それでも旧方式の意味を知るにはRFC 7540を読む必要があるとRFC 9113自身が示す。

置き換えられた文書は一般的な現行仕様ではないが、観測される旧挙動を解釈する証拠として残る。アーカイブが記憶を、現行RFCが方向を、保守者と運用者が実現時期を担う。

社内表に「RFC 9113導入済み」と書くだけでは、プロキシが削除された経路を拒否するか、古いシグナルを送るライブラリが残るか、管理機器に新ファームウェアが入ったかは分からない。番号は調査の出発点であり、ローカル状態の回答ではない。

TLSは混在を前提に書かれた

TLS 1.3を定めるRFC 8446は、TLS 1.2のRFC 5246をobsoletesする。ところが互換性付録は、旧サーバーと旧クライアントとのネゴシエーション、複数サーバーへの段階導入、古い中間装置の失敗を詳しく扱う。

新仕様の著者は、ヘッダーが旧版を世界から消すとは想定していなかった。混在する設備へ安全に入る方法を書いた。

RFC 8996はTLS 1.0と1.1にさらに強い判断を下す。正式にdeprecatedとし、文書をHistoricへ移し、実装はそれらをネゴシエートしてはならないとする。これは単なる後継関係より明確なセキュリティ境界である。

それでも運用上の考慮事項は、TLS 1.2以上を扱えないシステムが残り得ると述べる。勧告を採用すれば相互運用に失敗し、採用しなければ危険を引き受ける。移行速度は両方の損害、緩和策、更新リスクを踏まえて決める必要がある。

これは旧TLSを永久に許す文言ではない。IETFは現行実務の境界を示し、所有者は依存先を発見し、交換または隔離し、必要なら切断を受け入れ、旧版が使われないことを証明するという責任分担である。

RFC 9325はTLS 1.2と1.3の双方に個別の現行指針を与え、より古い版へのフォールバックを禁じる。RFC 9852は新しいTLS利用プロトコルにTLS 1.3を要求する。現行実務は一つの最新番号ではなく、更新関係と適用範囲の組合せである。

MUST NOTは常駐プログラムではない

大文字の規範語は重い。適用範囲内でMUST NOTは、適合を主張する実装がしてはならない挙動を定義する。試験や調達の基準にもなる。

ただし、全装置の管理権限を持つ常駐プログラムではない。保守者がコードにし、供給者が成果物を届け、運用者がロードして設定し、通信相手が結果に対応し、監査者が稼働状態を試験する。

規範権限は適合挙動を定義できる。実行権限は装置、作業時間、依存性、停止責任を持たなければならない。両者を分けるからこそ、移行失敗時に日程、試験、例外、ロールバックの責任者を特定できる。

導入済み設備は証拠であり、永久拒否権ではない

RFC 2026は、新しいInternet Standardが通常は旧版を置き換える一方、導入済み設備の要件を尊重するため、関係を明記して両方を標準として残す場合があると述べる。

相互運用性が実在するシステム間の性質である以上、この配慮は合理的だ。しかし「導入済み」は無期限の拒否権にもなり得る。測っていない依存性を重要と呼び、少数の古い相手のため全体の攻撃面を維持し、所有者も期限もない例外を残すことができるからだ。

立証責任は時間とともに移る。初期には撤去側が代替の動作と失敗条件を示す。対応版、移行事例、危険の証拠が増えた後は、例外を持つ側が必要性、隔離、終了日を示す。

棚卸しは旧機能があり得る場所を示す。ネゴシエーション計測は使われる場所を示す。遮断試験は壊れる依存を示す。ロード済み版はトラフィックを処理するコードを示す。ヘッダーは調査の契機であって、これらの測定の代わりではない。

移行完了を示す七つの欄

まず文書系譜として、新RFC、Updates、Obsoletes、後続BCP、対象となる具体的挙動を記録する。

次にロード状態として、実際の版、ビルド、ファームウェア、設定を記録する。利用可能、ダウンロード済み、承認済みは、実行中と同じではない。

依存性にはクライアント、サーバー、中間装置、組み込み機器、外部相手を含める。可視性が不足するなら観測期間と盲点を明記する。

危険と権限では、撤去理由、判断者、期限の根拠を分ける。RFCが技術的理由を与えても、契約や規制の強制力は別に示す。

試験とロールバックでは、予想する失敗、展開単位、中止条件、戻せる時間を決める。戻すと脆弱版が復活するなら、新しい承認が要る。

例外管理では、対象、所有者、代替統制、期限、再審査条件を置く。「レガシーだから」だけでは例外ではない。

最後に撤去証拠として、旧機能が交渉も呼出しもされず、警告を隠しただけではなく、後継経路がサービスを運ぶことを示す。

二つの都合のよい虚偽

一つは自動完了である。新RFCが出たので旧挙動も消えたと報告し、危険をワイヤより先に台帳から消す。中央部門にとって文書は読みやすく、分散した設備は面倒なので、この虚偽は管理を強く見せる。

もう一つは永久任意である。RFCが機械を直接変えないことを理由に、どの移行も永遠に先送りする。規範要件は意見になり、互換性は期限のない免罪符になる。

誠実な統治は二つの証拠を結ぶ。文書関係は現行の技術基準を証明し、稼働系は配備状態を証明する。その間には、責任者、期限、試験、撤去証拠が必要である。

「obsolete」と表示されたら、どの規則が変わったか、旧挙動はどこで可能か、誰が装置を支配するか、どの計測が消滅を証明するかを問うべきだ。

RFC Editorは歴史を保存し、IETFは現行仕様を示し、IANAは参照を保守し、開発者はコードを届け、運用者は変更と検証を担い、外部機関は自らの権限を説明する。これは分断ではなく、移行の証拠保全である。

Obsoletesは今日どの文書から読み始めるかを教える。昨日のコードが止まったことまでは教えない。

出典