# Request for Comments

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

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

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

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

* PHP: PHP: rfc
* Rust: Rust RFCs
* Vue.js: Vue RFCs - GitHub

## 歴史

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の例）。

*
*

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

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

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

*

## 一風変わったRFC

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

→詳細は「ジョークRFC」を参照
* 鳥類キャリアによるIP ( RFC 1149、およびRFC 2549、RFC 6214 )
* 洗濯ばさみ-DHCPによるIPアドレス管理 ( RFC 2322 )
* Hyper Text Coffee Pot Control Protocol ( RFC 2324 )
* Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances ( RFC 7168 )
* 悪意ビット ( RFC 3514 )
* 西暦10000年問題 ( RFC 2550 )
* 手旗信号システムによるIP伝送 ( RFC 4824 )
* 死亡フラグ ( RFC 9401 )
* 音響伝送メディアによるIP伝送 ( RFC 1926 )
* 大気リンク層を用いた地域的ブロードキャスト ( RFC 6217 )

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

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

## RFCの一覧

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

RFCの一覧| RFC | タイトル |
| --- | --- |
| RFC 3 | 望ましいコメントについての文書。RFCが文字通りの「コメント募集」だった頃の様子が分かる。 |
| RFC 748 | Telnet ランダム喪失オプション（エイプリルフールに発行されたはじめてのジョークRFC。1978年） |
| RFC 768 | UDP |
| RFC 783 | TFTP |
| RFC 791 | IP |
| RFC 792 | ICMP |
| RFC 793 | TCP |
| RFC 826 | ARP |
| RFC 854 | Telnet |
| RFC 894 | IP over Ethernet |
| RFC 903 | RARP |
| RFC 959 | FTP |
| * RFC 1034
* RFC 1035
 | DNS |
| RFC 1149 | 鳥類キャリアによるIPデータグラムの標準規格（1990年のジョークRFC） |
| RFC 1157 | SNMP |
| RFC 1179 | LPR Line PRinter daemon protocol |
| RFC 1189 | CMIP |
| RFC 1242 | ネットワーク相互接続機器のためのベンチマーク用語 |
| RFC 1305 | NTP |
| RFC 1459 | IRC |
| RFC 1468 | インターネットメッセージのための日本語文字符号化（ISO-2022-JP） |
| RFC 1808 | 相対URL（RFC 3986により破棄） |
| RFC 1855 | ネチケットガイドライン |
| RFC 1866 | HTML 2.0（RFC 2854により破棄） |
| RFC 1867 | HTMLにおけるフォームからのファイルアップロード（RFC 2854により破棄） |
| RFC 1928 | SOCKS v5 |
| RFC 1939 | POP Version 3 |
| RFC 1942 | HTMLにおけるテーブル（RFC 2854により破棄） |
| RFC 1951 | Deflate圧縮フォーマット仕様 Version 1.3 |
| RFC 1980 | HTMLにおけるクライアントサイドイメージマップ（RFC 2854により破棄） |
| RFC 2058 | Remote Authentication Dial In User Service (RADIUS) |
| RFC 2070 | HTMLの国際化（ISO-8859-1以外の文字セットをHTMLで使えるようにしたもの。「HTML2.x」もしくは「HTML i18n」ともいわれる。RFC 2854により破棄） |
| RFC 2080 | RIPng for IPv6 |
| RFC 2083 | PNG |
| RFC 2119 | Key words for use in RFCs to Indicate Requirement Levels |
| RFC 2131 | DHCP |
| RFC 2205 | RSVP |
| RFC 2247 | LDAP/X.500 識別名におけるドメイン名の使用 |
| RFC 2251 | LDAP v3 |
| RFC 2252 | LDAP v3: 属性文法の定義 |
| RFC 2253 | LDAP v3: UTF-8 識別名のストリングリプレゼンテーション |
| RFC 2254 | LDAP v3: LDAP 検索フィルタの定義 |
| RFC 2255 | LDAP URL形式 |
| RFC 2256 | LDAP v3 で利用される X.500(96) ユーザスキーマの要約 |
| RFC 2318 | Remote Authentication Dial In User Service (RADIUS) |
| RFC 2322 | Management of IP numbers by peg-dhcp（洗濯ばさみ-DHCPによるIPアドレス管理）（1998年のジョークRFC。実装例は#外部リンク参照） |
| RFC 2324 | Hyper Text Coffee Pot Control Protocol（1998年のジョークRFC） |
| RFC 2328 | OSPF Version 2 |
| RFC 2396 | URIの一般的書式（RFC 3986により破棄） |
| RFC 2401 | IPSec : Security Architecture for the Internet Protocol |
| RFC 2453 | RIP Version 2 |
| RFC 2459 | Internet X.509 Public Key Infrastructure Certificate and CRL Profile |
| RFC 2460 | IPv6 |
| RFC 2468 | 「IANAを偲ぶ」（IANAの発起者であるジョン・ポステルを悼んで。ヴィントン・サーフ作） |
| RFC 2527 | Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework（RFC 3647により破棄） |
| RFC 2549 | 鳥類キャリアによるIPのサービス品質（1999年のジョークRFC） |
| RFC 2550 | Y10K and Beyond（1999年のジョークRFC。2000年問題(Y2K)ではなく10000年問題について） |
| RFC 2555 | RFCの30年 |
| RFC 2616 | HTTP/1.1 |
| RFC 2732 | URLへのIPv6アドレスによるリテラルを含む書式（RFC 3986により破棄） |
| RFC 2740 | OSPF for IPv6 |
| RFC 2795 | The Infinite Monkey Protocol Suite (IMPS)（1999年のジョークRFC。無限の猿定理の実証で用いることのできるプロトコル） |
| RFC 2845 | Secret Key Transaction Authentication for DNS (TSIG) |
| RFC 2854 | text/htmlメディアタイプ（IETFにより標準化されたHTMLを破棄し、メディアタイプがtext/htmlである文書の仕様についてはW3Cの仕様書を参照するように定めた） |
| RFC 2865 | RADIUS認証プロトコル Remote Authentication Dial In User Service (RADIUS) |
| RFC 2866 | RADIUS Accounting |
| RFC 2930 | Secret Key Establishment for DNS (TKEY RR) |
| RFC 3261 | SIP |
| RFC 3280 | Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile（RFC 5280により破棄） |
| RFC 3305 | Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations（URI、URL、URNという概念についての考え方） |
| RFC 3377 | LDAP v3: 技術仕様 |
| * RFC 3411
* RFC 3412
* RFC 3413
* RFC 3414
* RFC 3415
* RFC 3416
* RFC 3417
* RFC 3418
 | SNMP |
| RFC 3490 | Internationalizing Domain Names in Applications (IDNA) |
| RFC 3501 | IMAP Version 4rev1 |
| RFC 3514 | The Security Flag in the IPv4 Header（2003年のジョークRFC。悪意ビット。このRFCは発行されたその日にFreeBSD上で実装され、翌日にキャンセルされた） |
| RFC 3550 | RTP |
| RFC 3645 | Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) |
| RFC 3647 | Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework |
| RFC 3751 | Omniscience Protocol Requirements（2004年のジョークRFC） |
| * RFC 3920
* RFC 3921
* RFC 3922
* RFC 3923
 | XMPP（Jabberを参照） |
| RFC 3977 | NNTP |
| RFC 3986 | URIの一般的書式 |
| RFC 3987 | Internationalized Resource Identifiers（Unicodeの文字を使えるようにしたリソース識別子であるIRIの仕様定義） |
| RFC 4041 | Requirements for Morality Sections in Routing Area Drafts（2005年のジョークRFC） |
| RFC 4042 | UTF-9 and UTF-18 Efficient Transformation Formats of Unicode（2005年のジョークRFC） |
| RFC 4158 | Internet X.509 Public Key Infrastructure:Certification Path Building |
| * RFC 4250
* RFC 4251
* RFC 4252
* RFC 4253
* RFC 4254
* RFC 4255
* RFC 4256
 | SSH |
| RFC 4271 | BGP |
| RFC 4325 | Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension（RFC 5280により破棄） |
| RFC 4346 | TLS |
| RFC 4627 | The application/json Media Type for JavaScript Object Notation (JSON)（RFC 7159により破棄） |
| RFC 4630 | Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile（RFC 3280を更新） |
| RFC 4635 | HMAC SHA TSIG Algorithm Identifiers |
| RFC 4824 | 手旗信号システムによるIP伝送（2007年のジョークRFC） |
| RFC 4844 | The RFC Series and RFC Editor |
| RFC 4960 | SCTP |
| RFC 5280 | Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| RFC 5321 | SMTP |
| RFC 5322 | Internet Message Format |
| RFC 5652 | 暗号メッセージ構文 (CMS) |
| RFC 5741 | RFC Streams, Headers, and Boilerplates |
| RFC 5914 | Trust Anchor Format |
| RFC 5937 | Using Trust Anchor Constraints during Certification Path Processing |
| RFC 6716 | Definition of the Opus Audio Codec |
| RFC 6818 | Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile（RFC 5280を更新） |
| RFC 6844 | DNS Certification Authority Authorization (CAA) Resource Record |
| RFC 6895 | Domain Name System (DNS) IANA Considerations |
| RFC 7158 | The JavaScript Object Notation (JSON) Data Interchange Format（RFC 7159により破棄） |
| RFC 7159 | The JavaScript Object Notation (JSON) Data Interchange Format |
| RFC 7168 | Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA) |
| RFC 7230 | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |
| RFC 7231 | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
| RFC 7232 | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |
| RFC 7233 | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |
| RFC 7234 | Hypertext Transfer Protocol (HTTP/1.1): Caching |
| RFC 7235 | Hypertext Transfer Protocol (HTTP/1.1): Authentication |
| RFC 7382 | Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI) |
| RFC 7519 | JSON Web Token (JWT) |
| RFC 7540 | Hypertext Transfer Protocol Version 2 (HTTP/2) |
| RFC 7541 | HPACK: Header Compression for HTTP/2 |
| RFC 7932 | Brotli Compressed Data Format |
| RFC 8058 | Signaling One-Click Functionality for List Email Headers - メールマガジンやメーリングリスト等において、受信者（購読者）がワンクリックのみで登録を解除（配信を停止）できるデータを、メールヘッダーに記載する方法 |
| RFC 8878 | Zstandard Compression and the 'application/zstd' Media Type |
| * RFC 8999
* RFC 9000
* RFC 9001
* RFC 9002
 | QUIC |
| RFC 9114 | HTTP/3 |
| RFC 9559 | Matroska Media Container Format Specification |
| RFC 9639 | Free Lossless Audio Codec (FLAC) |
| RFC 9649 | WebP Image Format |

### 参考リンク

* インターネット
* インターネット標準
* インターネットの歴史
* Internet Experiment Note (IEN) - インターネットの開発の最初期に発行されていた類似の文書

* 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日)