The basics
What is an RFC?
An RFC, short for Request for Comments, is a numbered document published by the Internet Engineering Task Force (IETF) that specifies how one part of the internet works, from IP addresses to email to HTTP. Despite the tentative name, a published RFC is not a draft up for debate: it is the standard itself, and it keeps its number forever.
A definition you can quote
RFCs are the written form of the internet. When engineers need to agree on how machines talk to each other, whether that is addressing a packet, formatting a timestamp, or negotiating a TLS session, the agreement is written down as an RFC and given a number. Everything from the shape of an IP address to the rules of email lives in one.
There are more than 9,500 of them, published since 1969 and maintained by the RFC Editor. Each is a fixed document: once it goes out, its text never changes and its number is never reused. That permanence is the point. A citation to RFC 2119 means the same thing today as it will in twenty years.
Why "Request for Comments"?
The name is a historical accident that turned into a tradition. In 1969 a graduate student named Steve Crocker wrote the very first one, RFC 1, to document early ARPANET host software. The people doing the work were mostly students, nervous about telling senior researchers how the network should behave, so Crocker deliberately chose a humble, non-authoritative title: a request for comments, an invitation to reply rather than a decree.
The politeness stuck even as the documents did not stay tentative. The request for comments quietly became the record of how the internet is built, the closest thing the network has to law. The name is a reminder that these standards came from conversation and rough consensus, not from a central authority handing down rules.
Who writes them
RFCs come out of the IETF, an open standards organization that anyone can join. There is no membership fee and no seat you need to be elected to; participation happens on public mailing lists and in working groups. Its guiding motto is "rough consensus and running code", meaning ideas earn their place by broad agreement and by actually working, not by authority.
The path is roughly this: an author writes an Internet-Draft, a working group refines it over months or years, the Internet Engineering Steering Group (IESG) reviews it, and finally the RFC Editor publishes it with a permanent number. Not everything on this path is a standard: some RFCs come from the research task force (IRTF) or from independent submissions, and are published for the record rather than as things you must implement.
The status is the whole game
An RFC keeps its number forever, but its standing can change. That is why the status matters as much as the text: it tells you whether a document is a live standard, a recommendation, background reading, or a tombstone.
| Status | What it means |
|---|---|
| Proposed Standard | A stable, reviewed specification on the standards track. Most of the "standards" you rely on every day never formally move past this level, and that is completely normal. |
| Internet Standard (STD) | The highest maturity level, reserved for specifications with wide deployment and proven interoperability. Rarer than you would expect, and given a permanent STD number alongside the RFC number. |
| Best Current Practice (BCP) | Not a protocol but a recommendation on how to operate, such as address allocation or working-group procedure. A BCP keeps its own permanent number even when the underlying RFC is replaced. |
| Informational | Published for the record: background, surveys, or a description of a protocol someone uses. Useful, but not a standards-track document. |
| Experimental | A specification worth trying and studying, not yet intended for production interoperability. |
| Historic | Superseded or abandoned. Kept in the archive for reference, not for use. |
| Obsoleted / Updated by | The living part of the system. A newer RFC can obsolete an older one (replace it wholesale) or update it (amend a piece). The old number stays valid as a citation but points you to its successor. Getting this relationship wrong is the single most common mistake in RFC write-ups. |
How to read an RFC number
The number is an address, not a version. RFCs are numbered in the order they are published, not by topic, so a higher number is newer but not better or more important. Two RFCs about the same subject can sit thousands of numbers apart, and two adjacent numbers can be about completely unrelated things.
There is no version scheme hiding inside the number either. HTTP/1.1 was defined in RFC 2616 and is now defined in RFC 9110, two numbers with nothing in common. When someone writes "see RFC 2119", the number is simply the permanent, unambiguous address of one specific document, and it will always point to that same document.
How to read an RFC without despairing
RFCs are written for implementers, not newcomers, which is why they feel impenetrable at first. A few habits make almost any of them approachable:
- Start with the Abstract and Introduction. They tell you what the document is for, in something close to plain language, before the detailed machinery begins.
- Learn the keywords. Words like MUST, SHOULD, and MAY are not casual English here. They have precise, defined meanings set out in RFC 2119, and reading a spec without knowing them is like reading a contract without its definitions.
- Use the section conventions. RFCs follow a familiar shape: terminology near the front, "Security Considerations" and "IANA Considerations" near the back. You can usually jump straight to the section you need.
- Do not read it linearly, and do not read all of it. You almost never need the whole document. Find the part that answers your question and stop there.
What people get wrong
-
"RFCs are laws."
They have no legal force. An RFC is a technical agreement that works because implementers choose to follow it, not because a government enforces it. The internet runs on rough consensus, not statute.
-
"A higher RFC number means a better or newer standard."
Numbers are chronological, not qualitative. RFC 9999 is not an upgrade of RFC 9998. Only an explicit "obsoletes" or "updates" relationship actually connects two documents.
-
"An RFC is a finished, frozen standard."
Many widely used RFCs are only Proposed Standard, and any RFC can be updated or obsoleted later. The text is fixed once published, but its status keeps moving.
-
"Request for Comments means it is still a draft."
The opposite. A document only becomes an RFC once it is published, and from that moment its number is permanent. Work in progress lives in Internet-Drafts, which expire. RFCs do not.
Good places to start
The clearest way to understand how an RFC reads is to read one that matters. These are common entry points, each explained here in plain English:
Questions people actually ask
What does RFC stand for? +
RFC stands for Request for Comments. It is a numbered technical document from the IETF that defines how a part of the internet works. The name dates back to 1969 and stuck even after RFCs became the formal record of internet standards.
Who writes RFCs? +
RFCs come out of the IETF, an open standards body anyone can join. An author writes an Internet-Draft, a working group refines it by rough consensus, the IESG reviews it, and the RFC Editor publishes it with a permanent number.
Are RFCs legally binding? +
No. RFCs carry no legal force. They are followed because implementers agree they are the right way to interoperate, not because any law requires it.
What is the difference between an RFC and an Internet-Draft? +
An Internet-Draft is work in progress and expires after six months. An RFC is the published, permanent result: once assigned, its number and text never change.
Can an RFC be changed after it is published? +
The text of a published RFC is never edited. Instead a newer RFC updates or obsoletes it, and the old document points forward to its replacement while keeping its number as a citation.