要約

  • RFC 5385 の Word テンプレートは、印刷プレビューを RFC 準拠 ASCII に近づけた一方、実際の出力には限定されたスタイル、テキスト印刷ファイル、Perl の後処理が必要だった。
  • 視覚的一致はレンダリングの受入れ証拠であり、正式なソースや意味の完全性を示す証拠ではない。現在の RFC 方針は RFCXML の definitive version と HTML・テキスト・PDF の publication versions を明確に分けている。

隠れた規則は、ページを直す前に意味を変える

著者が見出しを一段下げる。Word のアウトライン機能が番号を振り直す。目次が更新され、本文は正しい位置へ移動する。この動作は自然に見えるが、文字の大きさだけで実現しているわけではない。

RFC 5385 が説明した第2版テンプレートは、Normal、Heading1 から Heading9、Header、Footer、Caption といった Word の既存スタイルを再定義した。図、箇条書き、参考文献、付録のためのスタイルも加えた。そして、用意されたもの以外を使わないことが重要だと明記した。

見出しらしく見える太字の行と、構造上の Heading は別物である。前者は人間の目を納得させる。後者は番号、アウトライン、変換、ナビゲーションに参加する。静止したページでは差が消え、編集や変換の瞬間に差が現れる。

この性質は現代の公開システムにも残る。空白で組んだ表、色だけで示したリンク、画像として貼られた文字は、ある画面では正しく見える。しかし読み上げ、検索、別形式への変換、長期保存では意味が失われる。WYSIWYG は視覚面の約束であって、構造全体の保証ではない。

画面から ASCII までには別の成果物があった

RFC 5385 は 2010 年の Informational な Independent Submission であり、プロトコル標準ではない。目的は Word を使う著者が Internet-Draft と RFC の形式を扱いやすくすることだった。直接印刷や印刷プレビューは、少数の引用符やハイフンの差を除き、準拠 ASCII と行・ページ単位で一致し得た。

しかしテキスト生成は別工程だった。Generic/Text Only プリンタで .prn を作り、Perl プログラムに渡す。プログラムは CR を除き、スマートクォートやハイフンを ASCII に変え、ページ間の余白を整理し、form-feed を入れ、不正な文字を検査する。

ここで重要なのは、変換が存在するという事実である。Word の表示、印刷中間ファイル、処理済みテキストは、それぞれ異なる証拠を持つ。見た目が一致しても、入力の同一性や使用されたプログラムの版までは分からない。

監査可能な記録には、承認済みソース、テンプレート、変換プログラム、環境、設定、診断、出力を結び付ける必要がある。スクリーンショットはピクセルを示す。ハッシュはバイトを示す。再現可能な生成記録は入力と出力の関係を示す。どれか一つで全部を説明しようとしてはならない。

正規化は削除と置換の権限を持つ

曲がった引用符を直線の記号へ変える処理は、英語の文章では小さな差に見える。だが、文字集合の外にある人名、数式、識別子では、置換は意味を変え得る。ページのヘッダと本文を誤認すれば、削除も起こる。

後処理プログラムは文章の主張を作らなくても、何を残し、何を変え、何を拒否するかを決める。技術的な編集者である。RFC 5385 が付録にスクリプトを載せたことは、判断規則を見えるようにした点で有益だった。それでも、ある公開時に実行された実体、入力、終了状態は別に記録しなければならない。

現代の文書生成では、ソース、ツール一式、出力のハッシュを保存する。動的な日付や ID があるなら、再現時に異なり得る項目を定義する。見た目の差分と並行して、見出し、参照先、規範語、代替テキスト、Unicode 正規化を比較する。

「公式ツールを使った」という説明は、個別実行の証拠にならない。公式ツールにも更新と設定があり、警告もある。信頼はラベルではなく、検証可能な受領記録から生まれる。

変わるテンプレートを固定名で呼ぶ危険

RFC 5385 の Security Considerations には、テンプレートに開発・配布時点でマクロがなかったこと、.dot と .pl の MD5 を掲載する案があったことが書かれている。テンプレートは boilerplate の変更を追うため更新され、RFC 内に固定ハッシュを置けなかった。そこで当時の検証値は外部の配布場所に置かれた。

MD5 を現在推奨する話ではない。注目すべきは、説明文書と実行資産の更新周期が違ったことだ。同じ「RFC 5385 テンプレート」という名称の下に複数のバイト列が存在し得た。

契約雛形や規制報告でも、同じ名称が上書きされると来歴が失われる。作成時点で版を固定しなければ、後から「標準版を使用」と言っても、どの条項や初期値が入っていたか証明できない。

変更可能なテンプレートには、固有版、ハッシュ、発効日、変更理由、管理者が必要である。生成文書にもその参照を残す。自動挿入された本文は展開後に確認し、テンプレートの権威を出力の正しさに短絡させない。

参考文献は動かしたときに壊れた

RFC 5385 は旧テンプレートの endnote による参考文献処理も改めた。最初の引用を削除すると、後の相互参照が残っていても参考文献自体が消えることがあった。新版は本文段落として番号付き参考文献を持ち、著者名と年の形式には bookmark を使えた。

印刷した瞬間だけなら、旧方式と新方式は同じに見える場合がある。引用を削除した後の挙動が違う。これは文書テンプレートを完成見本だけで評価できない理由である。

見出しの昇降、最初の引用の削除、付録追加、図表の入替え、目次再生成、各形式への書出しを試すべきだ。品質とは一枚の完成度ではなく、通常変更の中で重要な性質が保たれることである。

現在の RFC は意味の基準と表示を分ける

ASCII だけではアクセシビリティ、メタデータ、図、国際文字、多様な端末に十分でないという課題を RFC 6949 が整理した。RFC 7990 は新しい形式枠組みを示し、2025 年の RFC 9720 がそれを置き換えた。

RFC 9720 では RFCXML が definitive format であり、それで公開された RFC が definitive version である。HTML、plain text、PDF は publication formats、それぞれの公開ファイルは publication versions と呼ばれる。公開意図に関する問いは、全ての意味情報を保持する definitive version から答える。

この制度を 2010 年の Word ファイルへ遡及してはならない。比較できるのは境界である。RFC 5385 は著者の画面と生成物の間に変換があることを実務で示した。RFC 9720 は後に、意味の基準と利用者向け表示の権限関係を明文化した。

企業も同じ答えを必要とする。CMS のデータ、編集ファイル、PDF、公開 HTML のうち、どれが意味を確定するのか。差が出たとき誰が解決するのか。すべてを曖昧に「最終版」と呼ぶことは、決定を先送りしているだけである。

再発行は履歴を消す許可ではない

RFC 9720 は、スキーマの修正や生成ツールの変更など限定された理由で再発行を認める。意味を可能な限り保存し、理由を公開し、以前の definitive version と publication versions を同じ方法で取得できるようにする。

長期保存では、全く変えないことと、追跡せず更新することの両方が危険である。古い形式は読めなくなる。新しいレンダラは意図しない差を入れる。必要なのは、変更可能性を認めた上で、履歴と意味を守る統制である。

新旧ソース、全出力、ハッシュ、ツール版、差分、理由、承認者を一つの再発行記録にする。最新版しか残っていなければ、再発行ではなく置換である。

現行 RFC Editor Model の RFC 9920 は、方針の形成・承認と RFC Production Center による実装を分け、公開用ツールの設計・保守責任も明示する。ツールを操作する責任と、意味を変更する権限は別である。

受入れ試験はページの外まで続く

非 ASCII の名前、複数階層の見出し、番号参照、コード、リンク、代替テキスト付き図、表、ページ境界を含むテスト文書を作る。ソースとテンプレート版を固定する。全形式を生成し、画面だけでなく構造抽出結果を比較する。

別環境で再生成し、バイト差を説明する。意味の一項目だけ変え、すべての出力が該当箇所だけ変化することを確認する。次に表示規則だけ変え、意味抽出が安定していることを確かめる。

最後に再発行を模擬し、旧版を保持して第三者が取得できるか試す。「同じに見える」から先へ進み、どの入力がどの出力を生み、誰が何を承認したか答えられて初めて、記録は完成する。

出典