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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 RFC編集者の役割 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 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シリーズのDOI（デジタルオブジェクト識別子）のディレクトリ識別子は 10.17487 である（参照）。例えばのDOIはであり、DOIディレクトリ経由でアクセスするURIは以下のようになる（はのURLエンコードである）。

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

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

 鳥類キャリアによるIP ( 、および、 )
 洗濯ばさみ-DHCPによるIPアドレス管理 ( )
 Hyper Text Coffee Pot Control Protocol ( )
 Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances ( )
 悪意ビット ( )
 西暦10000年問題 ( )
 手旗信号システムによるIP伝送 ( )
 死亡フラグ ( )
 音響伝送メディアによるIP伝送 ( )
 大気リンク層を用いた地域的ブロードキャスト ( )

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

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

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

+ RFCの一覧 RFC タイトル 望ましいコメントについての文書。RFCが文字通りの「コメント募集」だった頃の様子が分かる。 Telnet ランダム喪失オプション（エイプリルフールに発行されたはじめてのジョークRFC。1978年） UDP TFTP IP ICMP TCP ARP Telnet IP over Ethernet RARP FTP DNS 鳥類キャリアによるIPデータグラムの標準規格（1990年のジョークRFC） SNMP LPR Line PRinter daemon protocol CMIP ネットワーク相互接続機器のためのベンチマーク用語 NTP IRC インターネットメッセージのための日本語文字符号化（ISO-2022-JP） 相対URL（により破棄） ネチケットガイドライン HTML 2.0（により破棄） HTMLにおけるフォームからのファイルアップロード（により破棄） SOCKS v5 POP Version 3 HTMLにおけるテーブル（により破棄） Deflate圧縮フォーマット仕様 Version 1.3 HTMLにおけるクライアントサイドイメージマップ（により破棄） Remote Authentication Dial In User Service (RADIUS) HTMLの国際化（ISO-8859-1以外の文字セットをHTMLで使えるようにしたもの。「HTML2.x」もしくは「HTML i18n」ともいわれる。により破棄） RIPng for IPv6 PNG Key words for use in RFCs to Indicate Requirement Levels DHCP RSVP LDAP/X.500 識別名におけるドメイン名の使用 LDAP v3 LDAP v3: 属性文法の定義 LDAP v3: UTF-8 識別名のストリングリプレゼンテーション LDAP v3: LDAP 検索フィルタの定義 LDAP URL形式 LDAP v3 で利用される X.500 ユーザスキーマの要約 Remote Authentication Dial In User Service (RADIUS) Management of IP numbers by peg-dhcp（洗濯ばさみ-DHCPによるIPアドレス管理）（1998年のジョークRFC。実装例は#外部リンク参照） Hyper Text Coffee Pot Control Protocol（1998年のジョークRFC） OSPF Version 2 URIの一般的書式（により破棄） IPSec : Security Architecture for the Internet Protocol RIP Version 2 Internet X.509 Public Key Infrastructure Certificate and CRL Profile IPv6 「IANAを偲ぶ」（IANAの発起者であるジョン・ポステルを悼んで。ヴィントン・サーフ作） Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework（により破棄） 鳥類キャリアによるIPのサービス品質（1999年のジョークRFC） Y10K and Beyond（1999年のジョークRFC。2000年問題(Y2K)ではなく10000年問題について） RFCの30年 HTTP/1.1 URLへのIPv6アドレスによるリテラルを含む書式（により破棄） OSPF for IPv6 The Infinite Monkey Protocol Suite (IMPS)（1999年のジョークRFC。無限の猿定理の実証で用いることのできるプロトコル） Secret Key Transaction Authentication for DNS (TSIG) text/htmlメディアタイプ（IETFにより標準化されたHTMLを破棄し、メディアタイプがtext/htmlである文書の仕様についてはW3Cの仕様書を参照するように定めた） RADIUS認証プロトコル Remote Authentication Dial In User Service (RADIUS) RADIUS Accounting Secret Key Establishment for DNS (TKEY RR) SIP Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile（により破棄） Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations（URI、URL、URNという概念についての考え方） LDAP v3: 技術仕様 SNMP Internationalizing Domain Names in Applications (IDNA) IMAP Version 4rev1 The Security Flag in the IPv4 Header（2003年のジョークRFC。悪意ビット。このRFCは発行されたその日にFreeBSD上で実装され、翌日にキャンセルされた） RTP Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework Omniscience Protocol Requirements（2004年のジョークRFC） XMPP（Jabberを参照） NNTP URIの一般的書式 Internationalized Resource Identifiers（Unicodeの文字を使えるようにしたリソース識別子であるIRIの仕様定義） Requirements for Morality Sections in Routing Area Drafts（2005年のジョークRFC） UTF-9 and UTF-18 Efficient Transformation Formats of Unicode（2005年のジョークRFC） Internet X.509 Public Key Infrastructure:Certification Path Building SSH BGP Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension（により破棄） TLS The application/json Media Type for JavaScript Object Notation (JSON)（により破棄） Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile（を更新） HMAC SHA TSIG Algorithm Identifiers 手旗信号システムによるIP伝送（2007年のジョークRFC） The RFC Series and RFC Editor SCTP Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile SMTP Internet Message Format 暗号メッセージ構文 (CMS) RFC Streams, Headers, and Boilerplates Trust Anchor Format Using Trust Anchor Constraints during Certification Path Processing Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile（を更新） DNS Certification Authority Authorization (CAA) Resource Record Domain Name System (DNS) IANA Considerations The JavaScript Object Notation (JSON) Data Interchange Format（により破棄） The JavaScript Object Notation (JSON) Data Interchange Format Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA) Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests Hypertext Transfer Protocol (HTTP/1.1): Range Requests Hypertext Transfer Protocol (HTTP/1.1): Caching Hypertext Transfer Protocol (HTTP/1.1): Authentication Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI) JSON Web Token (JWT) Hypertext Transfer Protocol Version 2 (HTTP/2) HPACK: Header Compression for HTTP/2 Signaling One-Click Functionality for List Email Headers - メールマガジンやメーリングリスト等において、受信者（購読者）がワンクリックのみで登録を解除（配信を停止）できるデータを、メールヘッダーに記載する方法