要約

  • RFC 825は、同じ番号系列がSpecification、Discussion、Information、Status、Reportという異なる行為を運んでいると整理した。番号は文書を指すが、その権限までは決めない。
  • 公開ファイルと配布通知、ASCII・58行・72文字などの制約は、多様な機器で記録を読めるようにした。可読性は合意、採用、適合性の証明ではない。
  • 後のRFC 1796とRFC 2026は、RFC番号、STD番号、標準化上の状態、実装経験を別の証拠として扱った。引用は番号だけでなく、この文脈を保持しなければならない。

同じ表紙は同じ決定を意味しなかった

RFC 825が想定したRFCには複数の用途があった。情報を広く知らせる。興味深い問題の討議を始める、あるいは続ける。プロトコルを定める。系列を分けずに公開できることは、検索と保存には強い。しかし、読者が表紙だけを見ると、公開されたという事実が採択されたという事実に見えやすい。

そこで、タイトルページか第一または第二段落に意図を示すことが求められた。例文を逐語的に使う必要はない。一般的な目的が明らかであればよい。この設計は最小限だった。中央の規則は書き方を統一せず、解釈に欠かせない項目だけを共通化した。

Specification の例は、ARPA Internet共同体の標準を定め、ホストに採用と実装を期待した。Discussion は問題と解決案を示すが、その時点では標準を提案していないと明記した。合意は出版物の中に既成事実として置かれず、将来の過程に残された。

Information は、中心的な研究課題でなくても研究者や実装者に有用な提案への反応を求めた。Status は、出版時点では正確でも変更され得る進捗情報だった。Report は会議結果を記録し、実装に影響する決定、オプションの制限、政策課題、技術論点、残された仕事を含み得た。

同じ「RFC」でも、仕様は実装への期待を述べ、討議は未決を保存し、状況報告は時間の境界を保存する。番号だけを読むことは、これらの動詞を全部消してしまうことだった。

古い書式は表示装置の差を吸収した

RFCは公開アクセス可能なファイルとして置かれ、短いメッセージが配布リストに到着を告げた。読者はファイルを自分のサイトへ取り寄せ、手元の装置で印刷または表示した。作者と読者が同じソフトウェアを使う前提は置けなかった。

RFC 825の書式規則は、その異質性に対する互換層だった。文字コードはASCII。一ページは58行までで、その後にフォームフィード。一行は72文字までで、その後にCRLF。重ね打ちや下線は禁止され、見出しやページ番号、字下げも幅と高さに含まれた。

制約は表現を貧しくした一方、ファイルを特定の編集環境から解放した。公開という約束を、実際に取得して読める可能性へ近づけたのである。

ただし、どの端末でも読めることは、どのホストにも実装されたことを意味しない。配布リストへの通知は投票ではない。コピー数は合意数ではない。書式が保証したのは記録の移動であり、記録の主張が正しいことではなかった。

引用から状態が落ちると権限が増えた

RFC 1796は1995年に Not All RFCs are Standards と明記した。RFC系列はインターネット標準の公式出版路であると同時に、IESG、IAB、共同体の別の出版物も受け入れていた。RFCとして出たこと自体には、標準としての承認は含まれない。

問題は本文より後で起きた。状態は第一ページに書かれていても、引用では省略されることがあった。番号とリンクが残るため、参照は精密に見える。ところが、InformationalやExperimentalという制限が消えれば、読者は標準のように受け取る。

RFC 1796はRFC番号とSTD番号も区別した。RFC番号は文書を識別し、STD番号は標準プロトコルを識別する。一対一とは限らない。一つの標準を複数の文書が構成する場合があり、STDの識別子が加わっても文書のRFC番号は残る。

識別子を分けることで、それぞれの責任が細く保たれた。RFC番号は文書の一意性と検索可能性を守る。状態、標準化上の位置、置換、実装経験は、別の記録が時点と根拠を伴って示す。

失敗も残る棚の方が強かった

標準とそれ以外を別系列にすれば混乱は消える、という考えにRFC 1796は賛成しなかった。単一の系列は探しやすく、ファイルサーバーも整理しやすい。狭い副系列はネットワークから消えやすいという経験もあった。

標準にならなかった文書を残すことにも意味がある。外部で作られた仕様や実験的な方式が製品で使われれば、公開された仕様は私的な保管庫より検証しやすい。合意に至らなかった案も、後の設計が何を避けたかを説明する。

記録することと推奨することは両立しないのではなく、別の機能である。アーカイブが勝者だけを保存すれば、技術史は結果だけの物語になる。反対に、保存した全てを承認したものとして扱えば、公開すること自体が危険になる。

単一系列を健全に保つ条件は、状態を隠さないことだった。検索結果や調達文書が番号だけを取り出すなら、欠陥はアーカイブの広さではなく、参照側の省略にある。

標準には出版後の証拠が必要だった

RFC 2026は標準化の証拠をより詳しく並べた。技術的な能力、公開レビュー、改訂、複数の独立した相互運用実装、運用経験、支持、有用性、正式な採択。RFCとして出版されることは経路の一部であって、これらを代行しない。

Experimental、Informational、Historicは非標準トラックとして区別された。とりわけInformationalは共同体の合意や推奨を表さない。この区分は技術的価値を否定せず、その文書から引き出せる制度的結論を限定した。

RFC 8729の後の枠組みでも、一つのRFC Seriesの中に異なるストリームが存在した。各ストリームは固有の承認過程を持ち、その枠組みではIETFストリームだけがStandards TrackやBest Current Practiceを承認できた。共通の出版者は各決定を保存するが、決定主体にはならない。

したがって、文書の存在、状態、承認、実装、相互運用、実運用は別々に記録すべきである。番号が埋めるのは最初の欄だけだ。

正しい引用は不確実性も保存する

重要な判断でRFCを使うなら、番号、題名、日付、主張に関係する状態、節、更新や廃止の関係を残す。標準性を根拠にするならSTDやBCPの識別と承認過程を確認する。動作を根拠にするなら実装試験や運用観測が要る。

ラベルを逆向きに乱用してもいけない。Informationalは誤りを意味せず、Experimentalは未使用を意味せず、Historicは無価値を意味しない。Standards Trackも個々の製品を認証しない。状態は問いを終わらせるためではなく、証拠が答えていない範囲を守るためにある。

RFC 825が残した原則は、番号を軽く扱うことではない。番号の役割を正確に扱うことだ。番号は文書を失わないためにある。意図は文書の行為を取り違えないためにある。それ以上の権限は、それ以上の証拠によってのみ得られる。

出典