要約

  • RFC 2223はASCIIをRFCの主版と定め、PostScriptを編集部の照合を要する追加の見せ方として扱った。
  • 検索できる本文を先に公開し、図表や印刷向けの版には後から参加資格を与える仕組みだった。

同じRFC番号のファイルが二つあるとき、引用する側はどちらを基準にすればよいのか。1997年のRFC 2223は、この問いに順位をつけた。ASCIIテキストが主版であり、PostScriptは補助的な表現だ。図がきれいに見えることは、主版の地位を得る理由にはならなかった。

Jon PostelとJoyce Reynoldsが書いたのは、RFCシリーズへ文書を提出する著者向けの案内である。公開ファイルは複製され、さまざまな機器で表示され、印刷されていた。読者の環境は一つではない。画面上で語句を探す人もいれば、紙の図表を必要とする人もいる。同じ文書が、そのどちらでも使える必要があった。

RFC 2223は、二つの形式が担う作業を具体的に挙げている。読者はemacsやgrepで本文を検索し、短い抜粋をメールに貼り付けていた。PostScriptではこうした扱いが容易ではない。生成環境にもばらつきがあり、PostScriptを出力すると称するシステムの中には、標準に沿わないファイルを作るものがあった。一方、図やイラストは紙面上で見やすくできる。単に古い形式と新しい形式を比べたのではなく、検索可能性と視覚表現の両方をどう保つかが問題だった。

答えは、二つを対等に並べることではなく、公開の順序を決めることだった。RFC EditorはまずASCII原稿を処理し、RFCとして公開する。著者がPostScript版を送れるのはその後だ。内容がASCII版と同じだとRFC Editorが判断して初めて、そのファイルはRFCの保管場所に置かれ、コミュニティへ告知された。追加版は任意だが、審査は任意ではない。

役割分担も明確だった。著者は編集可能な原稿を提出する。RFC Editorは組版を変え、確定したRFC番号を入れ、修正を求めたり、原稿を差し戻したりできる。PostScript版が後から出てくる場合、主版と同じ文書かどうかを決めるのも編集部だ。ファイル形式が自分で同一性を保証することはできない。

この手順は見た目の問題にも踏み込んだ。RFC 2223は用紙寸法、余白、文字サイズを定め、使える書体を一般的なものに絞った。図表には標準的なプリンターで扱いやすいPostScriptを使うよう求めた。高度な命令を多用して特定の機器でしか出力できないなら、公開シリーズのファイルとしては不便になる。

組版を変えると、ページ数も節の位置も変わる。そこでRFC 2223は、ページ番号より節番号による参照を勧めている。ページはレイアウトに属するが、節番号は論旨の位置を示す。ASCII版とPostScript版で紙面が違っても、読者が同じ節にたどり着ける。

この形式上の土台は1989年のRFC 1111にもあった。ASCIIとPostScriptの提出ルールが並び、ASCIIは1ページ58行、1行72文字までに制限されていた。RFC 2223はこの仕組みを引き継ぎ、検索用の本文を維持しながら印刷版を追加する条件を詳しくした。

2014年、RFC 7322がRFC 2223を置き換えた。後継のスタイルガイドは、基本的な書式慣行を1970年代と初代RFC EditorのJon Postelにさかのぼって説明する。表示技術が変わっても、引用のよりどころとなるファイルは明示しなければならない。文書が示すのは照合手順までで、異議のあったPostScript版の件数や利用率までは記録していない。

公式資料