要約

  • RFC 3167はRFC 1745の経路制御方式を改訂した文書ではない。1994年のRFCをHistoricへ移すよう求め、公開インターネットで未展開だったことと実装の複雑さを理由に挙げた。
  • 現行のRFC Editor情報ページではRFC 1745はHistoricだが、保存された原文の冒頭には発行当時の「standards track」という記載が残る。両者は異なる時点の記録である。

違いは一ページ目に現れている。RFC 1745の原文は、自らを「standards track」のプロトコル仕様と説明する。一方、RFC Editorの現在の情報ページは、保存された本文の上に「Historic」と表示している。前者は発行時の案内、後者は今日のカタログ上の分類だ。必ずしも矛盾ではない。

2001年8月にInformational RFCとして公開されたRFC 3167は、この差をたどる手がかりになる。題名は「RFC 1745をHistoricへ移す要求」だ。David MeyerとJohn Scudderは、BGP関連標準の見直しでRFC 1745のBGP/IDRP–OSPF連携に注目したと記す。その仕組みは公開インターネットでは使われたことがなく、実装には相当な複雑さが必要だというのが、二人の主張だった。そこで再分類を提案した。

ここで動詞を変えてはいけない。RFC 3167が残したのは「要求」であり、このRFC自身のステータスも、インターネット標準を規定しないInformationalだと説明する。二人が理由を公開した証拠にはなるが、IESGの決定通知、全ネットワークを対象にした日付入り調査、あるいは変更手続きを完結させる記録ではない。RFC Editorの現行ページは別の証拠として、RFC 1745を現在Historicと表示する。要求と現在の表示は確認できても、資料にない手続き上のつながりや日付を補うことはできない。

文書には時間の層がある。RFC 1745は1994年12月に発行され、その冒頭には当時の状態を示す文言が載った。あのページは刊行物の歴史的な一部だ。現在のカタログ情報は後から変わり得る。状態を更新するために、原文を密かに書き換える必要はない。むしろ最初の記載を保存すれば、公開時に何が告知されていたかが分かる。アーカイブを現在の状況表示と読み違えると、刊行記録と現行メタデータを混同してしまう。

1996年のRFC 2026は、Historicという語を理解する枠組みを示す。§4.2.4は、新しい仕様に置き換えられたもの、または別の理由でobsoleteと判断された仕様をHistoricに分類する。§6.4は、標準化トラックの仕様を退役させる際、IESGの承認、Last Call、告知を求め、作業部会、Area Director、その他の関係者が要求を起こせるとする。ただしこれは当時の手続き枠組みであって、RFC 1745の状態を変えた正確な出来事や日付を示すものではない。

Historicは、技術文書の削除でも、世界中の装置から実装が消えた証明でもない。RFC Editorは今もRFC 1745を公開している。ラベルが示すのは標準成熟度体系の中での位置で、稼働コードの世界的な一覧ではない。また、未展開という判断はRFC 3167の著者に帰属させるべきだ。短い文書には調査方法がなく、私的または実験的な利用が一切なかったとまで結論づける根拠にはならない。

この記録の価値は、異なる証拠を隣り合わせにしつつ同一視しない点にある。仕様が公開され、利用状況についての主張が示され、再分類要求が出され、今日のカタログにはHistoricと載る。相互に関係する出来事だが、証明する内容は別々だ。2011年のRFC 6410は標準化トラックの成熟度を三段階から二段階へ整理し、年次レビュー要件も廃止した。これはRFC 1745の分類を説明する手続きではない。状態を表す語彙自体にも歴史がある、という補助線だ。本文、要求、もし確認できるなら決定、そして現行レコードを別々に読むのが妥当だ。

出典：RFC 3167、RFC 1745のHistoric化要求；Datatracker版RFC 3167；RFC 1745原文；RFC 1745の現行情報ページ；Datatracker版RFC 1745；RFC 2026、インターネット標準化プロセス；Datatracker版RFC 2026；RFC 6410、成熟度レベル；RFC 6410の現行情報ページ；RFCシリーズ案内。