RFC & internet standards reference
Every RFC, explained in plain English
You hit a reference to an RFC number in a spec, a codebase or a bug thread. Look it up here instead of reading eighty pages of formal prose: what it defines, whether it is still current, and which document replaced it.
- documents indexed:
- 9,828
- formally superseded:
- 1,384
- source:
- rfc-editor.org index
What is an RFC?
An RFC (Request for Comments) is a numbered technical document published by the IETF that specifies how a piece of the internet works. Despite the tentative-sounding name — chosen in 1969 when the first documents genuinely were requests for comment — an RFC is how internet standards are actually published. TCP, IP, HTTP, DNS, TLS, email and JSON are all defined in RFCs.
Three things are worth knowing before you read one. First, RFCs are never edited after publication: when a specification changes, a new RFC is issued that obsoletes or updates the old one, and the old number stays frozen forever. Second, not every RFC is a standard — the series also carries informational documents, experiments, best-practice guides and the occasional April Fools' joke. Third, the number tells you nothing about importance; it is simply the order of publication.
Read the full guide to RFCs, their status levels and how to read one →
What is the IETF?
The Internet Engineering Task Force is the organisation that develops and publishes the internet's core technical standards. It has no membership, no fees and no board seats to buy: anyone can join a working group mailing list and participate as an individual. Decisions are made by "rough consensus and running code" — a rule of thumb meaning a proposal needs broad agreement and a working implementation, not a formal vote.
Work happens in working groups, each chartered around a narrow area (HTTP, TLS, DNS operations, routing). A document starts as an Internet-Draft, is revised in public, passes IETF-wide Last Call and IESG review, and is finally published as an RFC by the RFC Editor.
Read the full guide to the IETF and how standards get made →
The RFCs developers actually reference
A dozen documents account for most of the RFC numbers you will meet in code reviews, READMEs and error messages.
- RFC 2119UpdatedKey words for use in RFCs to Indicate Requirement LevelsRFC 2119 defines what the capitalised keywords in a specification actually mean, so "SHOULD" and "MUST" are not read as English opinion but as precise requirement levels. If a spec says it uses RFC 2119 keywords, every capitalised MUST, SHOULD and MAY in it carries the meaning below.
- RFC 1918UpdatedAddress Allocation for Private InternetsRFC 1918 reserves three blocks of IPv4 addresses for use inside private networks. Anyone can use these addresses on their own network, and no router on the public internet will forward them, so they can be reused endlessly without collisions. This is why your home or office network almost certainly hands out a 192.168.x.x or 10.x.x.x address.
- RFC 793ObsoletedTransmission Control ProtocolRFC 793 defines TCP, the protocol that turns IP's unreliable packet delivery into a reliable, ordered byte stream between two programs. It specifies the three-way handshake (SYN, SYN-ACK, ACK) that opens a connection, sequence numbers and acknowledgements for retransmitting lost data, the sliding window used for flow control, and the connection teardown states you see in netstat output (TIME_WAIT, CLOSE_WAIT and the rest).
- RFC 791UpdatedInternet ProtocolRFC 791 defines the Internet Protocol (IPv4) — the addressing and packet format that everything else on the internet rides on. It specifies the 32-bit address, the IP header (version, TTL, protocol, checksum, source and destination), and how packets are fragmented and reassembled when a link cannot carry them whole. IP itself promises nothing about delivery: it is best-effort, connectionless and unreliable by design, leaving reliability to TCP above it.
- RFC 3986UpdatedUniform Resource Identifier (URI): Generic SyntaxRFC 3986 defines URI syntax — the grammar behind every URL you have ever written. It splits a URI into scheme, authority, path, query and fragment, defines which characters are reserved and how percent-encoding works, and specifies how a relative reference is resolved against a base. When two libraries disagree about escaping or normalising a URL, this is the document that settles it.
- RFC 8259CurrentThe JavaScript Object Notation (JSON) Data Interchange FormatRFC 8259 is the definition of JSON: six structural characters, four literals, strings, numbers, objects and arrays, and nothing else. It fixes the interoperability details that bite in practice — text must be encoded as UTF-8, object member names should be unique, and numbers have no defined precision limit, so large integers are not guaranteed to survive a round trip through every parser.
- RFC 8446ObsoletedThe Transport Layer Security (TLS) Protocol Version 1.3RFC 8446 specifies TLS 1.3, the version of TLS in use across most of the modern web. It cut the handshake to a single round trip (with an optional 0-RTT resumption mode), removed the legacy cipher suites and key exchanges that caused a decade of downgrade attacks, and made forward secrecy mandatory. Practically: faster connections and a much smaller set of ways to configure it insecurely.
- RFC 6749UpdatedThe OAuth 2.0 Authorization FrameworkRFC 6749 defines the OAuth 2.0 authorization framework: how an application obtains limited access to a user's account on another service without ever seeing their password. It defines the roles (resource owner, client, authorization server, resource server), the token exchange, and the original grant types. Note that it is a framework, not a single protocol — current best practice narrows it considerably, and the implicit and password grants it describes are no longer recommended.
- RFC 5321UpdatedSimple Mail Transfer ProtocolRFC 5321 defines SMTP, the protocol mail servers use to hand messages to each other. It covers the command dialogue (EHLO, MAIL FROM, RCPT TO, DATA), the envelope addresses that actually determine delivery, reply codes, and relaying rules. The envelope sender it defines is separate from the From: header a user sees — a distinction that matters constantly in deliverability, SPF and bounce handling.
- RFC 5322UpdatedInternet Message FormatRFC 5322 defines the format of an email message itself: the header block (From, To, Subject, Date, Message-ID), how header fields fold across lines, and the address syntax that email validators endlessly try and fail to reproduce with a regular expression. It describes the message; RFC 5321 describes how the message is transported.
- RFC 7231ObsoletedHypertext Transfer Protocol (HTTP/1.1): Semantics and ContentRFC 7231 is the semantics half of the 2014 HTTP/1.1 rewrite: what the methods mean (GET, POST, PUT, DELETE and friends), what each status code signals, and how content negotiation and representation headers work. It is the document to reach for when you need to know whether a method is safe or idempotent, or exactly what a 409 versus a 422 means. It has itself since been superseded by RFC 9110.
- RFC 2616ObsoletedHypertext Transfer Protocol -- HTTP/1.1RFC 2616 was the long-standing definition of HTTP/1.1 — methods, status codes, headers, caching and persistent connections — and it is the RFC most often cited in older code and documentation. It has been obsoleted: HTTP/1.1 was re-specified in 2014 as RFCs 7230–7235, and again in 2022 as RFCs 9110–9112. Cite the current documents for new work; RFC 2616 remains useful only as a historical reference.