What Is an RFC? Internet Standards Explained

An RFC (Request for Comments) is a formal, numbered, permanently archived document that describes internet protocols, procedures, and conventions, published through the RFC Editor and largely developed within the IETF. Despite the modest name, RFCs are how the core technologies of the internet, from IP and TCP to HTTP and TLS, are specified. Each RFC has a unique number, an immutable text, and a defined status that tells you whether it is a standard, a recommendation, or merely informational.

Key takeaways

• An RFC is a numbered, immutable technical document; its number is permanent and never reused.
• Most internet infrastructure protocols are defined in RFCs developed by the IETF.
• Not every RFC is a standard; status levels range from Standards Track to Informational, Experimental, and Historic.
• Requirement keywords like MUST, SHOULD, and MAY have precise meanings defined by RFC 2119 and clarified by RFC 8174.
• RFCs evolve by publishing new documents that update or obsolete older ones rather than editing them.
• RFCs are freely readable, which underpins the open development of internet standards.

What is an RFC and who publishes them?

An RFC is a document in a numbered series that began in 1969 as informal notes among early networking researchers. Today they are the authoritative specifications for internet technologies. The series is maintained by the RFC Editor, and the majority of technical RFCs originate in the Internet Engineering Task Force (IETF), the open standards organization responsible for protocols like TCP/IP, DNS, HTTP, and TLS.

The defining traits of an RFC are that it is uniquely numbered, freely available, and immutable. Once a number is assigned and the document published, its text never changes. This permanence lets any implementer cite an exact specification with confidence that it will read the same years later.

How does the RFC process work?

Most Standards-Track RFCs follow a path through the IETF:

1. An author writes an internet-draft, a temporary working document with an expiration date.
2. The draft is discussed and refined, usually within an IETF working group focused on that topic.
3. Rough consensus is sought through open mailing-list discussion rather than formal voting.
4. After review, including cross-area and security review, the document is approved for publication.
5. The RFC Editor assigns a permanent number and publishes it.

The guiding philosophy, often summarized as rough consensus and running code, values working implementations and broad agreement over top-down mandates. This is why many RFCs describe protocols that already have interoperating implementations.

What do the requirement keywords MUST, SHOULD, and MAY mean?

To remove ambiguity, RFCs use a standardized vocabulary of requirement levels defined in RFC 2119 and later clarified by RFC 8174, which specifies that these words carry their special meaning only when written in uppercase.

Reading these keywords precisely is essential. Treating a SHOULD as a MUST, or vice versa, is a frequent source of interoperability bugs.

Are RFCs standards?

Not all of them. An RFC’s category tells you its authority:

• Standards Track documents progress toward being internet standards, moving from Proposed Standard to Internet Standard as they mature and gain implementation experience.
• Best Current Practice (BCP) documents describe recommended operational or procedural practices.
• Informational RFCs provide general information without mandating anything.
• Experimental RFCs describe work still being investigated.
• Historic RFCs have been superseded or are no longer recommended.

So the presence of an RFC number does not mean a technology is a ratified standard. You must check the document’s status.

How do you read and cite an RFC?

RFCs are cited by number, such as RFC 2119 or RFC 8446. When reading one, check the header for its status, its date, and whether it is updated or obsoleted by later documents. A typical citation in code comments or documentation simply references the number and section, for example a note that a behavior follows RFC 7231 Section 6.

Because RFCs are immutable, the header metadata that links them together is critical. Two fields matter most: Obsoletes and Updates. If a newer RFC obsoletes the one you are reading, the newer one is now authoritative. Always verify you are reading the current document for a protocol rather than a superseded predecessor.

What are some influential RFCs developers should know?

A handful of RFCs underpin daily development work, and being aware of them helps you find authoritative answers:

• Core internet protocols like IP, TCP, and UDP are specified in the RFC series.
• HTTP semantics and its versions are defined across a set of RFCs that supersede earlier ones.
• TLS, which secures most web traffic, is specified by RFC documents, with TLS 1.3 defined in RFC 8446.
• Foundational conventions like the requirement keywords come from RFC 2119 and RFC 8174.
• Data formats and identifiers such as URIs, JSON, and email have their own defining RFCs.

When you hit an ambiguous edge case in a protocol, the relevant RFC is almost always the definitive tiebreaker.

How do RFCs get updated or obsoleted?

Because an RFC’s text cannot change, the series evolves by publishing new documents. A new RFC can update an existing one, meaning it modifies or adds to part of it while the original remains largely in force, or it can obsolete an existing one, fully replacing it. The metadata cross-references make this traceable: any RFC page shows what it obsoletes or updates and what later documents affect it.

This model gives the internet a durable, append-only record of its own design decisions. Nothing is quietly rewritten; the history is preserved, and readers can always follow the chain from an old specification to its current replacement.

Frequently asked questions

Are all RFCs internet standards?

No. Only a subset are on the Standards Track. Many RFCs are Informational, Experimental, Best Current Practice, or Historic, and each has a defined status.

Who can write an RFC?

Anyone can submit an internet-draft, but publication as an RFC goes through review, typically via IETF working groups and the RFC Editor. Contribution is open, publication is gated.

Can an RFC be changed after publication?

No. An RFC is immutable once published. Changes are made by publishing a new RFC that updates or obsoletes the old one.

What do MUST and SHOULD mean in an RFC?

They are defined requirement levels from RFC 2119. MUST is an absolute requirement, while SHOULD is a strong recommendation that may be ignored with good reason.

What does it mean when an RFC obsoletes another?

It means the new RFC fully replaces the older one, which should no longer be used as the authoritative reference for that topic.

Are RFC numbers ever reused?

No. Each RFC number is permanent and assigned once. Even if the document becomes Historic, its number is never reassigned.

Where are RFCs published?

They are published and maintained by the RFC Editor and are freely available to read, which is central to the open nature of internet standards.