Guide

What is an RFC?

Written by The metasystema editorial team · published 22 August 2026 · last reviewed 23 August 2026 · how we write these

An RFC — Request for Comments — is a numbered technical document published by the IETF that specifies, describes or comments on some part of how the internet works. The core protocols you use every day are defined in RFCs: IP in RFC 791, TCP in RFC 793, URLs in RFC 3986, JSON in RFC 8259.

Why the name sounds so tentative

The series began in April 1969, before the internet existed, when Steve Crocker wrote the first note describing host software for the ARPANET. He deliberately chose an unassuming title — a genuine request for comments — to avoid sounding like a graduate student issuing orders to his colleagues. The name stuck. Sixty years of infrastructure later, an RFC is anything but a draft: it is the permanent published record of an internet specification.

An RFC is never revised

This is the single most useful thing to understand. Once published, an RFC's text is frozen forever — no errata are folded in, no numbering is reused. When a specification changes, the IETF publishes a new RFC with a new number, and the index records the relationship:

• Obsoletes / Obsoleted by — the new document replaces the old one entirely. RFC 2616 (HTTP/1.1) was obsoleted by RFCs 7230–7235, which were in turn obsoleted by RFCs 9110–9112.
• Updates / Updated by — the new document changes or extends part of the old one, which otherwise still stands. You need to read both.

Every RFC page on this site shows those relationships at the top, so you can tell at a glance whether the document you landed on is still the one to implement.

Not every RFC is a standard

The series carries several categories of document, and the header of each RFC states which one it is:

• Internet Standard — a mature, widely implemented specification. There are only a few dozen.
• Proposed Standard — the entry point to the standards track and, in practice, the level at which most deployed protocols sit. TLS 1.3 and HTTP/2 are Proposed Standards.
• Best Current Practice (BCP) — operational or procedural guidance rather than a wire protocol.
• Informational — background, surveys, or descriptions of protocols developed elsewhere.
• Experimental — work that may or may not become a standard.
• Historic — superseded or abandoned.

The number carries no information about importance or status; it is simply the order of publication. RFC 1 and RFC 9000 (QUIC) sit in the same series.

How to read one without reading all of it

1. Check the status block first — category, date, and whether anything obsoletes it. If it is obsoleted, jump to the replacement.
2. Read the abstract and the introduction. Together they usually tell you whether this is even the document you want.
3. Note whether it uses RFC 2119 keywords. If it does, every capitalised MUST, SHOULD and MAY is a precise conformance requirement, not English emphasis.
4. Skip to the section you need. RFCs are written to be referenced by section number, and almost nobody reads them front to back.
5. Check the errata before implementing. Published RFCs cannot be edited, so real errors live in a separate errata database — linked from each page here when one exists.

RFC in other contexts

Outside the IETF, engineering teams often call their own internal design documents "RFCs" — borrowing the name and the culture of proposing a change in writing and inviting comment before building it. Those are unrelated to the numbered IETF series, though the naming is a deliberate homage.

Next: What is the IETF? · Who publishes RFCs? · Browse RFCs by topic