Jump straight to the right RFC
When you need the authoritative definition of how the internet works — how HTTP caching behaves, how TLS negotiates, how OAuth issues tokens — the answer is an RFC. But the numbers are hard to remember and many have been superseded. This curated index maps the protocols you actually use to their current RFC numbers, with titles, years, status and a direct link to the canonical document, so you can cite the right one in seconds.
How it works
The index is a hand-picked set of widely-referenced RFCs across the core stack: transport and IP, DNS, email, HTTP, TLS, authentication, JSON and identifiers. Filtering matches your query against the RFC number, the title, and a short summary, so searching cookie, 6265, or http state all find the same entry. Where a newer RFC has replaced an older one, the summary notes the relationship so you cite the current normative document rather than an obsoleted draft.
Understanding RFC status types
Not all RFCs carry the same weight. The status line tells you how normative the document is:
| Status | Meaning |
|---|---|
| Internet Standard | Highest maturity level; widely deployed and well-tested |
| Proposed Standard | On the standards track; normative but may have fewer implementations |
| Best Current Practice (BCP) | Operational and process recommendations; often as influential as standards |
| Informational | Documents ideas, practices or protocols outside the standards track; non-normative |
| Experimental | Describes experimental work; not intended for deployment without further development |
| Historic | Superseded or abandoned; do not implement |
When implementing a protocol, prefer Internet Standard or Proposed Standard documents. BCP documents like RFC 7525 (TLS Recommendations) are also highly authoritative for operational guidance. Be careful with Informational RFCs: some are well-established reference documents (the original HTTP spec was informational), while others describe proposals that never saw wide adoption.
Key protocol areas covered
HTTP
The HTTP specification was substantially reorganized in 2022. The current series is:
- RFC 9110 — HTTP Semantics (replaces RFC 7231 and parts of 7230)
- RFC 9111 — HTTP Caching (replaces RFC 7234)
- RFC 9112 — HTTP/1.1 Message Syntax (replaces RFC 7230)
- RFC 9113 — HTTP/2 (replaces RFC 7540)
- RFC 9114 — HTTP/3 (QUIC-based)
If you are citing HTTP behavior, cite the 9110 series. Citations to RFC 2616 or the 7230 series are outdated and may point to superseded text.
TLS
- RFC 8446 — TLS 1.3 (current; substantially different from 1.2)
- RFC 5246 — TLS 1.2 (still in wide use; officially succeeded by 8446)
- RFC 7525 — Recommendations for Secure Use of TLS (BCP; defines acceptable cipher suites and version policy)
OAuth and authentication
- RFC 6749 — OAuth 2.0 Authorization Framework
- RFC 6750 — Bearer Token Usage
- RFC 7519 — JSON Web Token (JWT)
- RFC 7636 — PKCE (Proof Key for Code Exchange) — important for public clients
DNS
- RFC 1034 / 1035 — DNS original specification (historic but still the foundation)
- RFC 4034 — DNSSEC
- RFC 7858 — DNS over TLS
The obsoletes / updates graph
One of the most common citation mistakes is referencing an RFC that has been obsoleted. Every RFC Editor page shows an “Obsoleted by” or “Updated by” field when applicable. The chain can be long: RFC 2616 (HTTP/1.1, 1999) was obsoleted by the RFC 7230 series (2014), which was in turn obsoleted by the RFC 9110–9112 series (2022).
Before citing an RFC in a specification or code comment, check whether it appears in the index here with a “superseded by” note, and if so, cite the current document instead. Links to the RFC Editor always resolve to the correct version, so they will not become stale as new editions are issued.