An RFC (Request for Comments) is a numbered document in the official publication series for Internet technical specifications, best current practices and related information. In Internet governance, RFCs are the form in which the IETF and related bodies publish protocol standards such as IP, TCP, DNS, HTTP and TLS. Each RFC receives a unique number and, once published, is never changed; corrections and updates appear as errata or as new RFCs.
The series began in 1969 with RFC 1, written during the ARPANET project as informal working notes, which explains the modest name. Today the series has passed number 9000, and not every RFC is a standard: the label covers specifications, operational guidance, experiments, informational notes and occasional humorous April 1 publications.
How a document becomes an RFC
Most RFCs start as an Internet-Draft, a working document anyone can submit. Drafts expire after six months unless revised, and they carry no standing; citing a draft as a standard is a common error. In the IETF stream, a draft is adopted by a working group, refined on mailing lists and at meetings, and advanced when the group reaches rough consensus.
- Individual or working group draft is published and discussed openly.
- Working group last call tests whether consensus exists.
- Area director review and an IETF-wide last call invite broader comment.
- IESG approval confirms technical quality and consensus.
- RFC Editor processing edits, assigns a number and publishes the final text.
The IETF motto of rough consensus and running code shapes this process. Decisions rest on technical arguments rather than voting, and working implementations carry significant weight, particularly when a specification advances in maturity.
RFC streams and status categories
RFCs are published through several streams, each with its own approval body. The stream tells a reader who stands behind the document, which matters more than the RFC label alone.
| Stream | Approving body | Typical content |
|---|---|---|
| IETF | IESG | Protocol standards and best practices |
| IAB | Internet Architecture Board | Architectural guidance |
| IRTF | Internet Research Steering Group | Research results and experiments |
| Independent | Independent Submissions Editor | Informational and alternative views |
| Editorial | RFC Series Approval Board | Policies for the RFC series itself |
Each RFC also has a status category that defines its weight. Only the standards track creates normative Internet standards; the other categories inform or experiment without creating obligations.
| Status | Meaning | Example use |
|---|---|---|
| Proposed Standard | Stable, reviewed standards-track specification | Most deployed protocols |
| Internet Standard | Mature, widely implemented standard with an STD number | Core protocols such as IP |
| Best Current Practice | Operational or process guidance with a BCP number | Requirement keywords in BCP 14 |
| Informational | Published for general information | Descriptions of vendor protocols |
| Experimental | Specification for limited trial | New congestion control ideas |
| Historic | Obsolete or no longer recommended | Retired protocols |
The standards track once had three levels, but RFC 6410 removed Draft Standard in 2011, leaving two maturity levels. Many crucial protocols remain Proposed Standards for years, which is normal and does not signal weakness.
Reading an RFC correctly
An RFC’s header states its number, stream, category, date and its relationships to other documents. The Obsoletes and Updates fields are essential: an obsoleted RFC has been replaced entirely, while an updated one remains valid but must be read together with its updates. The errata list records verified corrections.
Normative requirements use capitalized keywords defined in BCP 14 (RFC 2119 and RFC 8174). Only the capitalized forms carry this specific meaning, which helps implementers distinguish mandatory behavior from optional behavior.
Two sections deserve particular attention. Every RFC must include Security Considerations, which describe threats and required protections, and most protocol RFCs contain IANA Considerations, which tell IANA which registries to create or update. Skipping these sections is a frequent cause of insecure or non-interoperable implementations.
| Keyword | Strength | Implementation consequence |
|---|---|---|
| MUST or REQUIRED | Absolute requirement | Non-compliance breaks the specification |
| MUST NOT | Absolute prohibition | Doing it breaks the specification |
| SHOULD or RECOMMENDED | Strong expectation | Deviation needs a well-understood reason |
| MAY or OPTIONAL | Truly optional | Peers must interoperate either way |
RFCs among governance bodies
RFCs are documents, not an organization. The IETF produces most standards-track RFCs, the RFC Editor publishes the whole series, and IANA maintains the protocol registries that many RFCs create, such as port numbers and media types. ICANN coordinates names and numbers policy, while the W3C publishes web standards as Recommendations, a separate document series.
Unlike documents from formal standards bodies such as ISO or ITU, RFCs are freely available, developed in open participation without national membership, and published in plain text, HTML and PDF from an XML source format. Their authority comes from voluntary adoption and interoperability rather than from legal mandate.
Common misconceptions
- Not every RFC is a standard; Informational and Experimental RFCs carry no normative weight.
- A newer number does not imply a newer version of the same protocol unless it explicitly obsoletes the older one.
- RFC text is never edited after publication; check errata and updating RFCs before relying on details.
- An Internet-Draft is not an RFC, even when it is widely implemented.
- April 1 RFCs are jokes, published on the Informational track and not meant for implementation.
In everyday language
The Internet works because millions of different devices and programs agree on the same rules. Those rules have to be written down somewhere, in a form everyone can read for free. RFCs are that written rulebook, a numbered library of documents describing how email, the web and other services talk to each other.
Despite the humble name, which dates from the late 1960s, many RFCs are binding technical standards. Others are simply advice or experiments. The key habit is to check what kind of RFC you are reading and whether a newer one has replaced it.
Seen in the real world
A developer builds an email parser and bases it on a widely shared tutorial. Users soon report that some messages with international characters break the parser. The developer checks the RFC index and discovers that the tutorial followed RFC 822 from 1982, which has been obsoleted twice, most recently by RFC 5322, and that internationalized headers are covered by additional RFCs.
Reading the current documents and their errata, the developer adjusts header folding and character handling, treating every MUST requirement as non-negotiable and documenting the SHOULD items deliberately skipped. The parser then handles the reported messages correctly, and the team adds a rule to cite only current, non-obsoleted RFC numbers in its design documents.