Request for Comments （リクエスト フォー コメンツ、略称：RFC ）はIETF （インターネット技術特別調査委員会、英 : Internet Engineering Task Force ）による技術仕様 の保存 、公開形式である。内容には特に制限はないが、通信プロトコル やファイルフォーマット が主に扱われる。
RFCとは「コメント募集」を意味する英語の略語であり、もともとは技術仕様を公開し、それについての意見を広く募集してより良いものにしていく観点から始められたようである。今日では、IETF やIAB (インターネットアーキテクチャ委員会、英 : Internet Architecture Board )、およびコンピュータネットワーク研究者の世界的なコミュニティの公式発表の場となっている。
RFCは基本的に英語で書かれており、公式の翻訳版は存在しない。
なお、IETF以外の組織・コミュニティにおいても、同様の目的の文書群をRFCと呼称する事例が存在する。
RFCというコンセプトは、1969年にARPANET プロジェクトにおいて生まれた[ 1]
初期のRFCはタイプライター で執筆され、高等研究計画局 （略称ARPA、後にDARPAへ改名）の研究者にそれをコピーした紙が配布された。現在のRFCとは異なり、初期のRFCの多くは文字通り実際にコメントを求めるものであり、宣言のような響きを避け、議論を促すために"Request for comments"という名前が付けられた[ 2] [ 3]
RFC 1 は、カリフォルニア大学ロサンゼルス校 (UCLA)のスティーブ・クロッカー が執筆し、1969年4月7日に発行された「ホスト・ソフトウェア」である[ 4] ジェフ・ルリフソン による初期のワーキンググループでの議論により生まれたものである。
クロッカーが執筆した RFC 3 で「RFCとは何であるか」を初めて定義し、RFCはARPAのネットワーク・ワーキンググループに帰属するものとされた。ただし、これは正式な委員会ではなく、ARPANETプロジェクトに関心のある研究者のゆるやかな集まりであり、誰でも参加できた。
ARPANETが1969年12月に稼働し始めると、RFCの配布はARPANET上で行われるようになった。最初にネットワークで配布されたRFCはRFC 114 であった[ 5] UCLA にはARPANETの最初のIMP(Interface Message Processor )の一つが置かれていたため、1970年代のRFCの多くもUCLAから発信された。ダグラス・エンゲルバート が所長を務めたスタンフォード研究所 のオーグメンテイション研究センター (ARC)は、ARPANETの最初の4つのノード のうちの1つであり、初期のRFCもここから発信された。ARCには最初のNIC （のちのInterNIC ）が置かれ、エリザベス・J・フェインラー が管理し、他のネットワーク情報とともにRFCを配布した[ 6]
1974年に発行されたRFC 675 でinter-networking の略語としてはじめて「Internet」の語がつかわれた。
1977年頃、ARPANETプロジェクトとは別にInternetプロジェクトが発足した際に、ARPANETプロジェクトのRFCというコンセプトを模倣して、インターネット実験ノート （英 : Internet Experiment Note 、IEN）という類似の文書シリーズを発行することにした。またRFCのコンセプトを模倣した文書シリーズは IEN だけではなく、INWG Note[ 注釈 1] [ 7]
これらのシリーズは完全に独立したものではなく、複数のプロジェクトに関係する文書は複数のシリーズでナンバリングをされているものも存在する。例えば前述のRFC 675 は INWG 72 でもあり、またRFC 761 は IEN 129 でもある。
1983年にARPANETはそれまでのNetwork Control Program （NCP）プロトコルを、Internetプロジェクトの成果物であるTCP/IP に移行した。それを機に、あるいはそれと前後して、これらの類似の文書シリーズはRFCに統合されていった[ 7]
1988年、IAB にインターネットドラフト （英 : Internet Draft ）シリーズの作成が承認された[ 5]
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月）
1969年から1998年までは、ジョン・ポステル がRFC編集者（英 : RFC editor ）を務めた。1998年にポステルが亡くなると、彼の訃報が RFC 2468 として発表された。
アメリカ連邦政府とのARPANETの契約が切れた後、IETFを代表してインターネットソサエティ が南カリフォルニア大学 (USC)情報科学研究所 (ISI)のネットワーク部門と契約し、IAB の指示の下でRFCの編集および発行を行うことになった[ 8]
2007年7月にRFC発行の流れ（英 : RFC stream ）が定義され、編集作業を分担できるようになった[ 9]
2010年1月、RFC編集者の役割は Association Management Solutions に移管され、Glenn Kowack が暫定のシリーズ編集者を務めた[ 10] 英 : RFC Series Editor 、RSE）として採用された。また、その時にRFCシリーズ監視委員会（英 : RFC Series Oversight Committee 、RSOC）が設立された[ 11]
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がその役職に任命された[ 12]
RFCの作成プロセスは、RFC 2026 "The Internet Standards Process, Revision 3" で定義されている（一部が RFC 6410 により更新されている）。
これは、国際標準化機構 （ISO）などの正式な標準化組織の標準化 プロセスとは大きく異なる。インターネット技術の専門家は、外部機関のサポートなしにインターネットドラフト を提出することができる。標準化過程のRFCはIETFの承認を得て公開され、通常はIETFワーキンググループに参加している専門家によって作成され、最初にインターネットドラフトが公開される。このアプローチにより、文書がRFCとなる前に、最初のピアレビューラウンドが容易になる[ 13]
RFCのスタイルガイドは RFC 7322 で定義されている。また、RFC編集者のサイトでスタイルガイド関連資料が紹介されている[ 14] RFC 2119 およびRFC 8174 を参照）、メタ言語としての拡張バッカスナウア記法（ABNF 、RFC 5234 を参照）、および単純なテキストベースのフォーマットを使用している[ 注釈 2]
初期のRFCは固定幅の整形済みテキスト形式で作成されていたが、2019年8月にRFC文書をさまざまな表示サイズのデバイスで最適に表示できるように、リフロー 可能な形式に変更された[ 15]
RFC編集者はRFCを公開する際に一連の番号を割り当てる[ 注釈 3] [ 注釈 4] [ 16] 英 : 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 がインターネット標準 というわけではない[ 17] [ 18] 英 : 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編集者のサイトで確認ができる[ 参考 1] 「情報」
エイプリルフール のジョークRFC 、プロプライエタリ なプロトコル、RFC 1591 （DNS の構造と権限の委任）のように広く不可欠なものと認められた RFC など、ほとんどあらゆるものが含まれる。「実験的」
インターネットに関して有用と考えられる研究成果や実験結果を広く公開するためのものである。実験的といっても、実際には具体的な手続きをとろうとする者がいないために標準化過程へ昇格していないだけの文書も含まれる。
「現状で最良の慣行」
「情報」には留まらないが実際にネットワークで使われるデータには影響しない、インターネット上の公式なルールと見なされている実務上の文書などである。またインターネット標準を実践するための技術的な推奨事項も含まれる。
「歴史的」
標準化過程で破棄された文書や標準化以前に公開されていた廃れた RFC に適用される。
「不明」
ステータスが導入される以前に公開されたRFC（RFC 1128 以前）は、そのほとんどのステータスを「不明 (英 : Unknown )」とみなしている。ただし一部のRFCについて遡及的に「不明」以外のステータスを適用しているものもある[ 16]
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 [ 注釈 5]
RFC発行の流れには、IETF、IRTF、IAB、独立提出（英 : independent submission ）、および声明（英 : Editorial ）の5パターンがある[ 19]
IETF だけが「現状で最良の慣行」と「標準化過程」のRFCを作成できる。IAB は、ポリシーやアーキテクチャに関する「情報」文書を公開する。IRTF は、「情報」または「実験的」として研究結果を公開する。「独立提出」は、独立提出編集者（英 : Independent Submissions Editor ）の裁量で公開される（RFC 4846 、RFC 5742 、RFC 5744 参照）。
「声明」は、RFCシリーズ全体の編集ポリシーの変更に使用される（RFC 9280 参照）。 IETFと声明以外の文書は、IETFの作業と競合するかどうかについてIESG によってレビューされる。IRTFおよび独立提出RFCには通常、IETFの作業と競合しない、インターネット全体に関連する情報または実験的内容が含まれている。
一般的なルールとしては、明示的に権利を譲渡しない限り、RFCの著者（または雇用条件にその旨が定められている場合は雇用主）が著作権を保持する[ 20]
独立機関であるIETFトラストが一部のRFCの著作権を保有しており、その他すべてのRFCについては著者からRFCの複製を許可するライセンスを付与されている[ 21] インターネットソサエティ はRFC 4714 以前の多くのRFCで著作権所有者として言及されているが、その権利をIETFトラストに譲渡した[ 22]
全ての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 ドメインのものはその作業用リポジトリであるとしている[ 23] [ 24] [ 25] インターネットドラフト 等は 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 が公開されることがある[ 注釈 6]
また、インターネットに多大な貢献があった人への追悼のRFCが公開されたこともある。
RFC 2468 "I Remember IANA" （1998年10月）RFC 2441 "Working with Jon" （1998年11月）
最新のRFC一覧はRFC編集者のページに公開されているRFCインデックスで確認ができる[ 参考 2]
^ INWG は International Network Working Group の略
^ 一部のRFCはPostscriptなどの特定のフォーマットでのみ提供されている。
^ ただし必ずしも番号順に公開されるわけではない。RFCインデックスで確認できる。
^ RFCが誤った形式で公開されたような場合が唯一の例外。
^ STD 1 はインターネット標準の一覧。STD 1 廃止後はオンラインで最新状態を確認できる。本項の「ステータス」節を参照。
^ ジョークRFCはエイプリルフールに必ず発行されるわけではない。例えば2006年や2016年には発行されていない。
^ “Stephen D. Crocker, How the Internet Got Its Rules , The New York Times, 6 April 2009” . Nytimes.com . (April 7, 2009). https://www.nytimes.com/2009/04/07/opinion/07crocker.html?_r=1&em April 3, 2012 閲覧。 ^ Hafner, Katie; Lyon, Matthew (1996). Where Wizards Stay Up Late: The Origins of the Internet.
^ Metz, Cade (May 18, 2012). “Meet the man who invented the instructions for the Internet” . Wired . https://www.wired.com/2012/05/steve-crocker/ December 18, 2018 閲覧。 ^ Host Software doi :10.17487/RFC0001 RFC 1 。^ a b Fifty Years of RFCs doi :10.17487/RFC8700 RFC 8700 。
^ Elizabeth J. Feinler (July–September 2010). “The Network Information Center and its Archives”. Annals of the History of Computing 32 (3): 83–89. doi :10.1109/MAHC.2010.54 . ^ a b 30 Years of RFCs doi :10.17487/RFC2555 RFC 2555 。
^ Leslie Daigle (March 2010). “RFC Editor in Transition: Past, Present, and Future” . The Internet Protocol Journal (Cisco Systems) 13 (1). http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_13-1/131_rfc.html August 17, 2011 閲覧。 ^ The RFC Series and RFC Editor doi :10.17487/RFC4844 RFC 4844 。^ RFC Editor Transition Announcement at the Wayback Machine (archived 2011-06-29)^ The RFC Series Editor and the Series Reorganization at the Wayback Machine (archived 2013-03-13)^ “Alexis Rossi appointed as RFC Series Consulting Editor ” (2022年9月1日). 2024年11月29日 閲覧。 ^ IETF Working Group Guidelines and Procedures doi :10.17487/RFC2418 RFC 2418 。^ “Style Guide ”. RFC Editor. 2024年12月3日 閲覧。 ^ “RFC Format Change FAQ ”. 2024年11月29日 閲覧。 ^ a b “About RFCs ”. IETF. 2024年12月5日 閲覧。
^ “Frequently Asked Questions - Are all RFCs Internet standards documents? ”. 2024年11月29日 閲覧。 ^ Not All RFCs are Standards doi :10.17487/RFC1796 RFC 1796 。^ RFC Editor Model (Version 3) doi :10.17487/RFC9280 RFC 9280 。^ “Frequently Asked Questions - Reproducing RFCs ”. 2024年11月29日 閲覧。 ^ Rights Contributors Provide to the IETF Trust doi :10.17487/RFC5378 RFC 5378 。^ “Frequently Asked Questions - Copyright and IETF Copyright Policies ”. 2024年11月29日 閲覧。 ^ “References in RFCXML ”. 2024年11月29日 閲覧。 ^ “What is the difference between datatracker.ietf.org & www.rfc-editor.org and which is Official URL for RFC ? ”. 2024年11月29日 閲覧。 ^ “Links to HTML versions of RFC's need to move from "tools" to "datatracker" ”. 2024年11月29日 閲覧。
