Request for Comments

Request for Comments（リクエストフォーコメンツ、略称：RFC）はIETF（インターネット技術特別調査委員会、英: Internet Engineering Task Force）による技術仕様の保存、公開形式である。内容には特に制限はないが、通信プロトコルやファイルフォーマットが主に扱われる。

RFCとは「コメント募集」を意味する英語の略語であり、もともとは技術仕様を公開し、それについての意見を広く募集してより良いものにしていく観点から始められたようである。今日では、IETFやIAB (インターネットアーキテクチャ委員会、英: Internet Architecture Board)、およびコンピュータネットワーク研究者の世界的なコミュニティの公式発表の場となっている。

RFCは基本的に英語で書かれており、公式の翻訳版は存在しない。

なお、IETF以外の組織・コミュニティにおいても、同様の目的の文書群をRFCと呼称する事例が存在する。

歴史

RFCというコンセプトは、1969年にARPANETプロジェクトにおいて生まれた。

初期のRFCはタイプライターで執筆され、高等研究計画局（略称ARPA、後にDARPAへ改名）の研究者にそれをコピーした紙が配布された。現在のRFCとは異なり、初期のRFCの多くは文字通り実際にコメントを求めるものであり、宣言のような響きを避け、議論を促すために"Request for comments"という名前が付けられた。初期のRFCは、あまり形式ばらないスタイルで書かれていた。

RFC 1 は、カリフォルニア大学ロサンゼルス校(UCLA)のスティーブ・クロッカーが執筆し、1969年4月7日に発行された「ホスト・ソフトウェア」である。このRFCは、執筆したのはクロッカーであるが、クロッカーとスティーブ・カー、ジェフ・ルリフソンによる初期のワーキンググループでの議論により生まれたものである。

クロッカーが執筆したRFC 3 で「RFCとは何であるか」を初めて定義し、RFCはARPAのネットワーク・ワーキンググループに帰属するものとされた。ただし、これは正式な委員会ではなく、ARPANETプロジェクトに関心のある研究者のゆるやかな集まりであり、誰でも参加できた。

ARPANETが1969年12月に稼働し始めると、RFCの配布はARPANET上で行われるようになった。最初にネットワークで配布されたRFCはRFC 114であった。UCLAにはARPANETの最初のIMP(Interface Message Processor)の一つが置かれていたため、1970年代のRFCの多くもUCLAから発信された。ダグラス・エンゲルバートが所長を務めたスタンフォード研究所のオーグメンテイション研究センター(ARC)は、ARPANETの最初の4つのノードのうちの1つであり、初期のRFCもここから発信された。ARCには最初のNIC（のちのInterNIC）が置かれ、エリザベス・J・フェインラーが管理し、他のネットワーク情報とともにRFCを配布した。

1974年に発行されたRFC 675 でinter-networkingの略語としてはじめて「Internet」の語がつかわれた。

1977年頃、ARPANETプロジェクトとは別にInternetプロジェクトが発足した際に、ARPANETプロジェクトのRFCというコンセプトを模倣して、インターネット実験ノート（英: Internet Experiment Note、IEN）という類似の文書シリーズを発行することにした。またRFCのコンセプトを模倣した文書シリーズは IEN だけではなく、INWG Noteや、PRNET Notes、ARPA Satellite System Notes など多くプロジェクトでRFCを模倣した類似の文書シリーズが存在した。

これらのシリーズは完全に独立したものではなく、複数のプロジェクトに関係する文書は複数のシリーズでナンバリングをされているものも存在する。例えば前述のRFC 675は INWG 72 でもあり、またRFC 761は IEN 129 でもある。

1983年にARPANETはそれまでのNetwork Control Program（NCP）プロトコルを、Internetプロジェクトの成果物であるTCP/IPに移行した。それを機に、あるいはそれと前後して、これらの類似の文書シリーズはRFCに統合されていった。

1988年、IABにインターネットドラフト（英: Internet Draft）シリーズの作成が承認された。これにより最初期の「コメント募集」という位置づけと形式ばらないスタイルが、RFCとして承認される前段階であるインターネットドラフトに引き継がれた。

RFCの歴史については以下のRFCにまとめられている。

RFC 1000 "The Request for Comments Reference Guide"（1987年8月）
RFC 2555 "30 Years of RFCs"（1999年4月）
RFC 5540 "40 Years of RFCs"（2009年4月）
RFC 8700 "Fifty Years of RFCs"（2019年12月）

RFC編集者の役割

1969年から1998年までは、ジョン・ポステルがRFC編集者（英: RFC editor）を務めた。1998年にポステルが亡くなると、彼の訃報がRFC 2468 として発表された。

アメリカ連邦政府とのARPANETの契約が切れた後、IETFを代表してインターネットソサエティが南カリフォルニア大学(USC)情報科学研究所(ISI)のネットワーク部門と契約し、IABの指示の下でRFCの編集および発行を行うことになった。

2007年7月にRFC発行の流れ（英: RFC stream）が定義され、編集作業を分担できるようになった。

2010年1月、RFC編集者の役割は Association Management Solutions に移管され、Glenn Kowack が暫定のシリーズ編集者を務めた。2011年後半、Heather Flanagan が常任のRFCシリーズ編集者（英: RFC Series Editor、RSE）として採用された。また、その時にRFCシリーズ監視委員会（英: RFC Series Oversight Committee、RSOC）が設立された。

2020年、IABは RFC Editor Future Development プログラム開催し、RFC編集者のモデル変更の可能性について議論した。プログラムの結果は、2022年6月に公開されたRFC 9280で定義されているRFC編集者モデル（バージョン3）に含まれている。一般的に、新しいモデルは、RFCシリーズとRFC編集者の役割に関連するポリシーの定義と実装の責任とプロセスを明確にすることを目的としている。新しいモデルの変更には、RFCコンサルティング編集者（英: RFC Consulting Editor）、RFCシリーズワーキンググループ（英: RFC Series Working Group、RSWG）、およびRFCシリーズ承認委員会（英: RFC Series Approval Board、RSAB）の役職の確立が含まれる。また、RFCシリーズの新しい編集の流れを確立し、RSOCを終了した。RSEの役割はRFCシリーズコンサルティング編集者（英: RFC Series Consulting Editor、RSCE）に変更され、2022年9月 Alexis Rossiがその役職に任命された。

作成

RFCの作成プロセスは、RFC 2026 "The Internet Standards Process, Revision 3" で定義されている（一部がRFC 6410により更新されている）。

これは、国際標準化機構（ISO）などの正式な標準化組織の標準化プロセスとは大きく異なる。インターネット技術の専門家は、外部機関のサポートなしにインターネットドラフトを提出することができる。標準化過程のRFCはIETFの承認を得て公開され、通常はIETFワーキンググループに参加している専門家によって作成され、最初にインターネットドラフトが公開される。このアプローチにより、文書がRFCとなる前に、最初のピアレビューラウンドが容易になる。

RFCのスタイルガイドはRFC 7322 で定義されている。また、RFC編集者のサイトでスタイルガイド関連資料が紹介されている。ほとんどのRFCでは一貫性を保ち理解しやすいように「MUST」や「NOT RECOMMENDED」などの共通の用語セット（RFC 2119およびRFC 8174を参照）、メタ言語としての拡張バッカスナウア記法（ABNF、RFC 5234を参照）、および単純なテキストベースのフォーマットを使用している。

初期のRFCは固定幅の整形済みテキスト形式で作成されていたが、2019年8月にRFC文書をさまざまな表示サイズのデバイスで最適に表示できるように、リフロー可能な形式に変更された。

バージョン管理

RFC編集者はRFCを公開する際に一連の番号を割り当てる。一度番号が割り当てられ公開されたRFCは、取り消されたり変更されたりすることはない。誤字などの誤りがあった場合には、別途正誤表（英: errata）が公開されることがある。

公開済のRFCに大きな修正が必要な場合は、新しいRFCとして改訂版を発行する。そのため、一部のRFCは他のRFCを置き換えることがある。他のRFCを置き換えたRFCは「置き換え先のRFCを廃止した（英: obsolete）」と言い、置き換えられたRFCは「置き換え元のRFCによって廃止された（英: obsoleted by）」と言う。例えばRFC 5000はRFC 7100によって破棄されたため、RFCインデックスなどにはRFC 5000には Obsoleted-By RFC7100 と記載があり、RFC 7100には、Obsoletes RFC5000 という記載がある。

またRFC文書の全体を廃止するのではなく、一部を上書きするケースもある。この場合には他のRFCを上書きしたRFCは「上書き先のRFCを更新した（英: update）」と言い、上書きされたRFCは「上書き元のRFCによって更新された（英: updated by）」と言う。

ステータス

すべての RFC がインターネット標準というわけではない。各RFCには標準化プロセスにおけるステータス（英: status）が定められている。ステータスは「標準化過程 (英: Standards Track)」、「情報 (英: Informational)」、「実験的 (英: Experimental)」、「現状で最良の慣行 (英: Best Current Practice)」、「歴史的 (英: Historic)」のいずれかである。

「標準化過程」: 「標準化過程」は成熟度によってさらに「標準への提唱 (英: Proposed Standard, PS)」、「インターネット標準 (英: Internet Standard, STD)」に分けられる。以前のRFC 2026では「標準への提唱」、「標準への草稿 (英: Draft Standard, DS)」、「インターネット標準」の3段階だったが、RFC 6410によって2段階に変更された。ただし、それ以前に「標準への草稿」となったものが引き続き存在するため、標準化過程のRFCのすべてが2段階のどちらかになっているわけではない。最新の状態はRFC編集者のサイトで確認ができる。

→詳細は「インターネット標準」を参照

「情報」: エイプリルフールのジョークRFC、プロプライエタリなプロトコル、RFC 1591（DNSの構造と権限の委任）のように広く不可欠なものと認められた RFC など、ほとんどあらゆるものが含まれる。
「実験的」: インターネットに関して有用と考えられる研究成果や実験結果を広く公開するためのものである。実験的といっても、実際には具体的な手続きをとろうとする者がいないために標準化過程へ昇格していないだけの文書も含まれる。
「現状で最良の慣行」: 「情報」には留まらないが実際にネットワークで使われるデータには影響しない、インターネット上の公式なルールと見なされている実務上の文書などである。またインターネット標準を実践するための技術的な推奨事項も含まれる。
「歴史的」: 標準化過程で破棄された文書や標準化以前に公開されていた廃れた RFC に適用される。
「不明」: ステータスが導入される以前に公開されたRFC（RFC 1128以前）は、そのほとんどのステータスを「不明 (英: Unknown)」とみなしている。ただし一部のRFCについて遡及的に「不明」以外のステータスを適用しているものもある。

サブシリーズ

RFCシリーズには、2つのサブシリーズ（BCP、STD）が含まれており、また廃止された1つのサブシリーズ（FYI）がある。

BCPサブシリーズ（英: Best Current Practice）は標準化過程ではないが、実務上のルールなどの必須情報をまとめたサブシリーズである。ステータスが「現状で最良の慣行」のRFCがこのサブシリーズを構成する。RFC 1818参照。
STDサブシリーズ（英: Standard）は、標準化過程の最終段階である「インターネット標準」のRFCが構成する。RFC 1311参照。
FYIサブシリーズ（英: For Your Information）は、RFC 1150 (FYI 1) で規定されているようにIETFによって推進されている情報RFCのサブシリーズであった。ステータスが「情報」の一部がこのサブシリーズを構成していた。2011年、RFC 6360によって FYI 1 が廃止され、このサブシリーズは終了した。

RFCが各サブシリーズに割り当てられると、サブシリーズの番号が割り当てられる（例えば、STD 1 など）。サブシリーズの番号が割り当てられてもRFC番号は保持される。

サブシリーズを構成するRFCが置き換えられた場合でも、サブシリーズの番号は変わらずに新しいRFCを参照するようになる（参照先のRFCは1つの場合もあれば、複数のこともある）。例えば、2007年時点ではRFC 3700がインターネット標準 STD 1 であったが、その後RFC 5000に置き換えられたため、2008年5月時点の STD 1 はRFC 5000となった。さら2013年12月にRFC 7100で置き換えられ、STD 1 は使用されなくなった。

発行の流れ

RFC発行の流れには、IETF、IRTF、IAB、独立提出（英: independent submission）、および声明（英: Editorial）の5パターンがある。

IETFだけが「現状で最良の慣行」と「標準化過程」のRFCを作成できる。
IABは、ポリシーやアーキテクチャに関する「情報」文書を公開する。
IRTFは、「情報」または「実験的」として研究結果を公開する。
「独立提出」は、独立提出編集者（英: Independent Submissions Editor）の裁量で公開される（RFC 4846、RFC 5742、RFC 5744参照）。
「声明」は、RFCシリーズ全体の編集ポリシーの変更に使用される（RFC 9280参照）。

IETFと声明以外の文書は、IETFの作業と競合するかどうかについてIESGによってレビューされる。IRTFおよび独立提出RFCには通常、IETFの作業と競合しない、インターネット全体に関連する情報または実験的内容が含まれている。

著作権

一般的なルールとしては、明示的に権利を譲渡しない限り、RFCの著者（または雇用条件にその旨が定められている場合は雇用主）が著作権を保持する。

独立機関であるIETFトラストが一部のRFCの著作権を保有しており、その他すべてのRFCについては著者からRFCの複製を許可するライセンスを付与されている。インターネットソサエティはRFC 4714以前の多くのRFCで著作権所有者として言及されているが、その権利をIETFトラストに譲渡した。

取得方法

全てのRFCはインターネット上で公開されており、誰でも閲覧、取得することができる。

インターネット上では以下の2つのURIからRFCを取得できる（以下はRFC 1149の例）。

https://www.rfc-editor.org/info/rfc1149
https://datatracker.ietf.org/doc/html/rfc1149

IETFは、RFCの公式提供URIは www.rfc-editor.org ドメインのもので、datatracker.ietf.org ドメインのものはその作業用リポジトリであるとしている。ただし、関連するインターネットドラフト等は datatracker.ietf.org にしかないため注意が必要である（Wikipediaでは、datatracker.ietf.orgドメインのURIを使用している）。

RFCシリーズのISSN（国際標準逐次刊行物番号）は 2070-1721 である（RFC 5741参照）。

RFCシリーズのDOI（デジタルオブジェクト識別子）のディレクトリ識別子は 10.17487 である（RFC 7669参照）。例えばRFC 1149のDOIは10.17487/RFC1149であり、DOIディレクトリ経由でアクセスするURIは以下のようになる（%2Fは/のURLエンコードである）。

https://doi.org/10.17487%2FRFC1149

一風変わったRFC

毎年、エイプリルフールにはユーモラスな内容のRFC、通称ジョークRFCが公開されることがある。

→詳細は「ジョークRFC」を参照

また、インターネットに多大な貢献があった人への追悼のRFCが公開されたこともある。

RFC 2468 "I Remember IANA"（1998年10月）
RFC 2441 "Working with Jon"（1998年11月）

RFCの一覧

最新のRFC一覧はRFC編集者のページに公開されているRFCインデックスで確認ができる。以下の一覧は一部の抜粋である。

脚注

[脚注の使い方]

注釈

出典

参考リンク

外部リンク

Request for Comments (RFC) (英語、IETF)
RFC Editor (英語)
IETFとRFC (2001.8、江崎浩、社団法人ネットワークインフォメーションセンター(JPNIC))
セキュリティ関連 RFC - IPA（2019年7月17日アーカイブ） - 国立国会図書館Web Archiving Project
槻ノ木隆のBBっとWORDS その65「RFCのプロセス」 (2006.2、槻ノ木隆、BB Watch、Impress Watch)
ＲＦＣ日本語版リスト - Ishida Soによるリンク集。
ジョーク RFC(よっち＠ほ～む) at the Wayback Machine (archived 2016年03月31日)