要約

  • RFC 4714は、承認後の編集を変更管理の問題として扱った。文法や読みやすさの改善でも、合意された表現や技術的意味を変えうるためだ。
  • 2006年の情報提供文書は、変更履歴と技術側の承認、過剰なスタイル修正への抑制、技術修正用の別経路を提案した。将来の契約要件を示す文書であり、当時の出版者の成績評価ではない。

分析

問われるのは編集者の善意ではない。公開された文言が、それを承認した手続きに結び付いたままかどうかだ。

承認済みの文書に入る最後の手

仕様の承認が終わっても、公開前の作業が残る場合がある。誤字を直し、体裁をそろえ、読みづらい文を整理する。問題は、技術審査を通過した文章に、その審査とは別の経路から変更が入ることだ。編集者が意図したのは読みやすさでも、意図だけでは意味が保たれたと証明できない。

RFC 4714は2006年10月の情報提供文書で、IETFの技術出版サービスに期待する要件をまとめた。3.3節は、文法・綴り・可読性・書式・定型文・文書構造を、承認後の編集整理として挙げる。編集自体を否定するのではない。承認後の変更は通常の承認手続きの外にあるため、確認と署名の仕組みを設け、変更を最小限にすることが望ましいとした。

この文書は、スタイル修正が多くの変更を生み、著者の確認、受け入れ、再確認の往復が必要になったことがあると記す。その結果、公開まで大きく遅れることもあり、明瞭さの増分と比べて判断しなければならなかった。全RFCの遅延を示す統計や、被害を受けた個別文書は提示されていない。これは工程上の観察であり、定量的な業績調査ではない。

差分と承認者を残す

提案された方法は明快だ。承認後の変更をすべて記録し、適切な技術代表者の確認を得る。IETF標準化ストリームでは、著者、いる場合は文書シェパード、そしてエリアディレクターが対象となる。全変更の承認権限はエリアディレクターに置かれた。出版者は編集を確認するが、技術審査をやり直す役ではない。

これにより、編集者が「文体の修正」として技術的な判断を紛れ込ませることを防ぎ、著者が未記録の変更で通常の承認経路を迂回することも抑えられる。技術変更が疑わしい、または不合理と感じられる場合、出版者はエリアディレクターに知らせ、回答があるまで処理を止めるべきだともされた。

文言をそのまま残す必要がある場面もある。RFC 4714は、派生文書に適用する共通の定型文や、他組織と慎重に交渉したセンシティブな表現を挙げる。こうした箇所は逐語的に掲載する必要があり、標準化ストリームではIESGがその扱いを求められる。読みやすさより、交渉で成立した文言の正確さが優先される場合がある。

技術修正は別の判断

3.7節は、編集整理と、承認後・公開前に見つかった技術修正を分ける。技術的な欠陥は公開前に直す必要があるかもしれないが、出版者の編集レビューとは別問題だ。RFC 4714は、著者とエリアディレクターの承認を求め、シェパードには情報を共有する手続きを提案する。別々の経路を設ければ、文章の整形がいつの間にか技術設計の変更になる事態を避けやすい。

何も直さなければ修正可能な誤りが残り、直し過ぎれば確定した議論を再開し、確認回数を増やし、承認版と出版版のつながりを見えにくくする。RFC 4714が勧めるのは軽い編集と抑制だ。読みやすさの改善がわずかなのにレビュー負荷が大きい場合や、合意表現を変えうる場合には、とくに慎重であるべきだという。承認前に編集すれば、技術審査の中で変更を検討でき、承認後の別手続きが不要になる場合もある。

RFC 4714自身は主張の範囲も限定する。IETFの要求を明確にして将来の契約作成に役立てることが目的であり、当時のRFC Editorがどれほど要件を満たしたかを評価するものではない。提案を、そのまま現場で実行された記録として扱うことはできない。

後年の資料との距離

2014年のRFC 7322は、意図された意味を変えてはならず、安全な編集が保証できなければ承認機関へ戻しうると述べる。問題意識は近いが、それだけでRFC 4714が後年の規則を生んだとも、2006年の提案がすべて実装されたとも言えない。

2026年のRFC 9920は、現行のRFCシリーズで編集方針と出版実務、著者との意見相違を誰が扱うかを記述する。制度は変化している。これも、RFC 4714の要件が過去または現在どのように実施されたかを示す直接証拠ではない。

残る教訓は小さいが重要だ。承認後の「ちょっとした修正」も、共同作業で成立した公開文書を変える。差分記録はその変化を検証可能にし、承認者の明示は責任を見える形にする。意味が動くおそれがあれば、決定は技術文書を承認する権限を持つ側へ戻すべきだ。

出典