要約

  • 旧称AUTH48であるRFCのFinal Reviewは、いずれかの出版ストリームがInternet-Draftを承認した後に始まる。著者は全文、マークアップ、各形式を確認し、出版を承認する。実効的な完全性検査だが、IETFの二度目の投票ではない。
  • 文書がキューに入ると、RFC Production Centerは出版用コピーの変更管理を担う。編集上の修正はその管理下で進められるが、追加、削除、技術的変更など編集を越えるものは、元のストリームの承認を要する。
  • 2025～2026年のkramdown-rfc／GitHub試行は、この境界を見える形にした。2026年8月27日時点でRFC-to-be 10025にはFinal Reviewページと公開リポジトリがあり、RFC 10025の情報ページはまだ404だった。
  • 最終確認のレシートには、承認済みdraft、ストリーム判断、RPCの編集集合、論点と変更区分、著者およびストリームの承認、最終出力のハッシュ、出版告知を残すべきである。実装と運用採用は別の証拠である。

二度目の採決に見えたpull request

画面に表示された情報は正しかった。誤っていたのは、情報同士の結び方である。

技術調査担当者が公開リポジトリを開く。RPC-editsブランチがあり、issuesが並び、pull requestが一つ残り、全著者の最終承認はそろっていない。二値の台帳なら「未承認」に入れたくなる。さらに強い言葉を使えば、「著者が拒否」「標準が再審議」「GitHub上で再投票」となる。

Final Reviewは、二つの制度的行為の間にある。前には、IETF、IAB、IRTF、Independent、Editorialのいずれかのストリームによる出版承認がある。後には、RPCが特定のHTML、PDF、TXT、XMLを公開し、RFCとして告知する行為がある。その間で、編集済みの版が承認内容を正しく表し、各出力が壊れていないかを確認する。

これは飾りの工程ではない。ABNFの崩れ、コードの欠落、誤ったIANA指示、規範文の意味を変える一語は、公開後に長く参照される。しかし、損害が大きいからといって権限まで無制限になるわけではない。RPCは問いを立て、著者は忠実性を確認し、ストリームは実質変更を判断する。

GitHub試行の価値は、参加者を増やすことより、行為を区別できることにある。承認された起点、RPCが提案した差分、質問、回答、必要な承認が別々に残る。公開性は全員を決定者にするのではなく、誰が何を決めたかを追跡可能にする。

承認はキューより前にある

現行のRFC出版案内は、文書がRPCへ渡る前から説明を始める。五つのストリームのいずれかがInternet-Draftを出版対象として承認し、その後に出版キューへ入る。RPCは技術案をゼロから採否判断するのではなく、既に承認された文書を受け取る。

キューに入ると、RPCが出版用コピーの変更管理を持つ。著者は承認済みファイルを勝手に差し替えず、RPCを通して変更を出す。追加、削除、技術的意味の変更など編集の境界を越えると判断されれば、元のストリームへ承認を求める。

RFC 9920は役割を明記する。各ストリームの承認機関はその内容に責任を負い、RFC Editor機能は制作と配布を担う。RPCは編集履歴と著者との対話を保存し、技術的影響を持ち得る変更を特定し、説明を求め、出版準備を確認し、最終成果物を公開する。

どちらの仕事も軽くない。ストリームが内容を承認しても、読めない出力を放置すればシリーズは信頼を失う。RPCが美しい文書を作っても、承認されていない技術判断を挿入すれば忠実性を失う。著者も最終校正を使って合意済みの内容を独自に変更できない。

したがって台帳の最初には、承認されたdraftの正確な版とハッシュが必要である。次にストリームと承認主体を記す。そこから後の差分に初めて意味が生まれる。

著者は何を承認するのか

Final Reviewはdiffだけを見る儀式ではない。著者はRPCの質問に答え、共著者の変更を確認し、全文を読み、著作権表示と意味上のマークアップを点検し、HTML、PDF、TXTの表示を確認する。場合によっては複数回の往復や代替表現の検討が必要になる。

kramdown-rfc試行の手順では二段階の承認を求める。まずmarkdownがRFCXMLへ変換できるほど安定したことを確認し、次に内容と全形式を最終承認する。ソースが正しくても、変換後のコード、図、表、参照、インデントが正しいとは限らないからである。

著者承認は、出版用成果物が自分の責任ある内容を忠実に表すという証明である。それは重要だが、ストリーム承認後に新しい技術方針を個人で持ち込む権限ではない。

連絡不能の著者に対する規則も、この設計を示す。残る著者はその人を謝辞またはContributorsへ移すことができる。重要な貢献を理由に著者表記を維持したい場合は、ストリーム管理者が代わって承認できる。貢献の記録と出版継続を両立し、到達不能な受信箱に永久拒否権を与えない。

もちろん、未承認を無視してよいわけではない。本人だけが見抜ける意味の変化もある。連絡状況、代替経路、承認者、理由を残す必要がある。違いは、問題に手続があるか、説明不能な個人権力として扱うかである。

GitHubのmergeが越えられない線

RPCは2025年9月1日からkramdown-rfc試行を始めた。多くの著者が利用する形式で編集し、内容に焦点を当てた明瞭なdiffを得ることが狙いだった。当初は月に少なくとも五件を受け付け、経験を積みながら改善するとされた。

2026年にはAUTH48がFinal Reviewと呼ばれるようになった。48は二日間の保証ではなかったため、新名称の方が実態に近い。GitHubでは、RPCの変更が独立ブランチに置かれ、質問がissuesになり、提案がpull requestsになり、対話がアーカイブされる。

HTTP Cookie仕様の改訂であるRFC-to-be 10025の公開リポジトリは、境界を具体的に示す。READMEによれば、最初のmarkdownは出版承認されたInternet-Draftのコピーである。RPCの編集は別ブランチにあり、著者は内容と形式を承認し、編集を越える変更はArea Directorが承認する。WG chairsとdocument shepherdも参加し、必要ならメール方式へ戻れる。

2026年8月27日には、Final Reviewステータスページとリポジトリが公開されていた一方、RFC 10025情報URLは404だった。リポジトリには十五件のissuesと一件のpull requestが見えた。しかし、その数を技術欠陥、反対者、停止決定の件数として読むことはできない。公開された作業項目の数にすぎない。

状態は記事公開後に変わり得る。だから観測時刻が要る。番号が予約され、出力候補が閲覧できても、出版記録と告知がなければpublishedではない。

RFC 9991でAD承認を要した一語

実際のエスカレーションは、役割分担を端的に示す。

RFC 9991となった文書のFinal Reviewで、著者はBCP 14キーワードの追加を提案した。大文字の規範語は技術的義務を変え得るため、句読点の修正とは異なる。公開メールでRPCはArea Directorに確認と承認を求め、ADは承認した。

記録の価値は動詞の分離にある。著者が提案し、RPCが境界を認識して照会し、ADが承認し、その後RPCがRFCを出版した。mergeだけで承認を代用していない。ADの承認だけで出版完了とも扱っていない。

最終本文しか残さなければ、遅い段階の規範変更がどの権限で入ったか分からない。承認メールだけでは、その語が全形式へ正しく反映されたか分からない。RFC番号だけなら、保管の連鎖全体が消える。

また、この照会はRPCの越権を示すのではない。自らの権限の終点を認識し、適切な主体へ返した証拠である。

48は期限ではなかった

AUTH48は48時間の約束に見える。RFC 8963は2018年に制作されたRFCの標本を調べ、RPC編集、AUTH48、合意後の出版待ちを分けた。その標本ではAUTH48は平均一か月超で、ばらつきも大きかった。理論上は、編集済み文書を著者が最終確認し、必要なら最後の修正を求める段階と説明されている。

RFC 8700には「48日」「48週」という冗談も残る。それ以上に重要なのは、AUTH48中の技術変更には関連するArea Directorまたはストリーム管理者の承認が必要だという経験である。

時間だけで失敗とは言えない。時差のある共著者、連絡不能、IANA処理、規範参照、Stream Hold、生成ツールの問題は、それぞれ違う責任主体を持つ。経過日数は質問を始める指標であり、責任の答えではない。

Final Reviewへの改称は誤った時計を外した。代わりに誤った投票箱を置くべきではない。ここで行うのは、権限を限定した最終化である。

最終確認のレシート

項目 保存する証拠 意味
承認済みソース draft名、版、バイト、ハッシュ ストリームが決めた基準
ストリーム判断 ストリーム、機関、日付、URL 出版承認の主体
RPCへの引渡し キュー入り時刻と状態 判断と制作管理を分離
編集集合 ブランチ、diff、ハッシュ 承認後の変更を可視化
論点 質問、担当、回答、アーカイブ 不確実性を帰属
変更区分 編集、形式、技術、編集外 必要な承認を決定
著者承認 人物、範囲、時刻 最終出力との結び付け
ストリーム承認 AD等のレシート 内容権限を保護
外部保留 IANA、参照、ストリーム、ツール 本当の停止要因を示す
最終成果物 HTML、PDF、TXT、XMLのハッシュ 何を承認したかを固定
出版 告知、RFC URL、時刻 RFC-to-beからRFCへの移行
採用 実装、試験、運用 文書と稼働実態を分離

このレシートは判断を自動化しない。判断した役割を消さないためにある。「著者の出力確認待ち」「技術追加のAD承認待ち」「IANA処理待ち」と正確に書ければ、拒否や再投票を発明する必要はない。

情報源

RFC-to-be 10025に関する記述は2026年8月27日の観測である。issuesを欠陥数とせず、出版時期も予測しない。