要約

  • Verifiedは報告が審査され正確と判断されたことを示す。しかし修正文は、通常のTXT、PDF、XML版へ組み込まれない。
  • 正誤表が扱えるのは公開時点から存在した誤りである。新しい発想、後年の能力、当初の合意を変える提案は、技術共同体へ戻し、新たなRFCで決める必要がある。

原文の横に残る訂正

実装担当者がRFC内の矛盾を見つけ、正誤表ページでVerifiedの報告を発見する。そこには原文、修正文、日付、確認者が並ぶ。修正文に従うことは適切でも、それが最初からRFC本文だったと扱えば、意思決定の履歴が失われる。

RFCは、特定時点で審査と承認を通過した共同記録である。正誤表は、その後に下された、記録上の欠陥についての限定的判断である。前者は何が承認されたかを示し、後者は字面どおりの実装が危険になり得ることを示す。

RFC Editorは上書きではなくリンクで二つを結ぶ。Verifiedの修正は実装者から見える一方、通常の公開版には混入しない。訂正を公開しながら、後日の確認権限を標準制定権限と同一視しない設計だ。

本文を直接差し替えれば、その瞬間の読みやすさは上がる。しかし後の監査では、承認された文面、確認された訂正、各組織の採用判断を区別できなくなる。

四つの状態は別々の判断である

Reportedは、主張が提出されたという事実しか示さない。正しいか、文脈を誤読したか、大きな変更を小さく見せているかは未決である。製品がこの段階を自動適用してはならない。

Verifiedは、適用される基準の下で有効であり、実装・運用者が参照すべきだという判断である。最も強い状態だが、当初意図に沿って誤りを直す範囲を越えない。

Rejectedは、この訂正経路では成立しないという判断である。報告が誤っている場合も、変更が大きく、更新または置換RFCを必要とする場合もある。

Held for Document Updateは、現RFCへの必須訂正ではないが、将来の改訂で検討できる論点を保存する。現時点の義務でも、遅れて発効する承認でもない。

四状態を「最新文面」一列へ潰すと、申立て、認定、否定、将来への保留が同じ効力を持ってしまう。簡単なデータ構造のために、判断の意味を捨てることになる。

確認権限は公開ストリームに従う

RFC SeriesにはIETF、IAB、IRTF、Independent Submission、Editorialの各ストリームがある。目的と承認主体が異なるため、正誤表を確認する当事者も由来に応じて決まる。

IETFストリームの技術的報告は、著者、ワーキンググループ議長、Area Directorへ送られる。処理責任はArea Directorにあり、本人が評価することも委任することもできる。明白な編集上の誤りはRFC Editorが初期対応し、技術的含意があればArea Directorへ渡る。

この分担により、公開システムの運用者がそのままプロトコル政策を決める事態を防ぐ。同時に、技術専門家が公開手続きの痕跡なしにアーカイブの意味を変えることも防ぐ。

したがって監査では、Verifiedという語だけでなく、ストリーム、確認者、日付、根拠を読む必要がある。状態表示は、権限の所在から切り離せない。

当初意図が訂正の上限になる

2021年の有効なIESG声明は、正誤表を公開時点ですでに存在した誤りに限定する。公開後の新知識、新能力、より良い設計、あるいは承認内容への異論は、正誤表ではなく関係する技術共同体へ持ち込む。

当初意図に沿う明確な技術解決はVerifiedにできる。解決に議論が必要ならHeldとする。承認時の合意とは異なる動作へ変えるものは、原則Rejectedである。IANA登録手続きのようなプロセスを変える提案も、元の合意を変えるならこの経路を使えない。

変更文字数は権力の大きさを表さない。規範語、既定値、コードポイント範囲の一箇所で、相互運用性と危険負担は変わる。確認者はワーキンググループ議論、Last Call、IESG審査、アルゴリズム全体、既知の実装を参照しなければならない。

そこから唯一の訂正が立証できないなら、不確実性を残す方が正確である。小さな入力欄が、参加者のいない再決定の場になってはならない。

再発行は意味の変更を許さない

RFC 9720は、RFCXMLの決定版と各公開版を限定的理由で再発行できると定めた。XML構造の更新、XML上の誤り、生成ツールの変更などが該当する。旧版は保存され、再発行の日付と理由も公開される。

2026年2月のRFC 9920はRFC 9280を廃止し、安定性をRFC Seriesの歴史的特性として引き継いだ。同時に表示の一貫性を保つ再発行を認めるが、元の意味を最大限保存することが中心条件である。

切れた図や誤った文字表現を直すことと、プロトコルの振る舞いを変えることは違う。公開媒体の整備、リンクされた訂正判断、新しい規範決定は、それぞれ別の権限を持つ。

この区分は障害調査にも効く。二つの実装が異なる規則を読んだのか、同じ意味の別レンダリングを見たのかを切り分けられるからだ。

実装参照は複合的で日付を持つ

「RFC 1234準拠」だけでは再現性がない。利用した公開版、更新・廃止した後続RFC、正誤表を確認した日、採用したVerified項目を記録すべきである。

試験は各訂正を観測可能な挙動へ結び付ける。相手実装が元の文面に従う可能性があれば、リリースノートで互換性を説明する。セキュリティ上の誤りは、アーカイブを変えなくても直ちに緩和が必要になり得る。

Heldは将来設計の注意点にはなるが、自動的な不適合判定ではない。Rejectedも、ある読み方が検討され、訂正として認められなかった証拠を残す。

この方法なら、アーカイブを無謬とみなさず、訂正管理者を立法者ともみなさない。運用上の参照集合を進化させながら、判断の出所を保持できる。

薄い共通台帳

Heng Luの考え方は、共通層を必要最小限にし、将来判断を適格な主体へ残し、実装の自発的採用で改善を試す。正誤表制度は、述べる内容を狭く保てばこの構造に合う。

共通台帳はRFC、節、原文、修正案、種別、状態、確認者、日付、理由を記録できる。全ベンダーの採用、Heldの義務性、活動停止したグループの沈黙による同意までは証明しない。

この節度が訂正の信頼を高める。正当性は「どこが誤りで、誰が、どの範囲まで判断したか」を正確に語ることから生まれ、後日の注記が過去を消したという演出からは生まれない。

情報源