RFC Basics for Developers

This note explains how to read RFCs without drowning in them, which RFCs are most relevant for web developers, and the conventions that make these documents less intimidating than they first appear. If you have ever tried to look up how HTTP caching actually works and bounced off a wall of formal specification text, this is the orientation you need.

What RFCs Are (and Are Not)

RFC stands for “Request for Comments,” which is misleadingly casual. In practice, RFCs are the published standards that define how the internet works. HTTP, DNS, TLS, email, TCP, IP — every protocol you use daily is specified in one or more RFCs.

They are not tutorials. They are not blog posts. They are specifications — precise, formal documents written for implementers. Reading them feels more like reading a legal contract than a dev blog. That density is a feature, not a bug: ambiguity in a protocol specification causes interoperability failures.

The RFC series is maintained by the RFC Editor. You can browse and search the complete collection at rfc-editor.org.

How RFCs Are Structured

Most RFCs follow a common structure:

1. Abstract: 1–2 paragraphs summarizing what the document specifies. Read this first.
2. Introduction: context, motivation, scope. Often includes a “Terminology” subsection.
3. Conventions: defines how keywords like MUST, SHOULD, and MAY are used (per RFC 2119).
4. Core specification: the meat. Protocol details, message formats, state machines, algorithms.
5. Security Considerations: required section covering threat model and mitigations.
6. IANA Considerations: any registries or assigned numbers.
7. References: normative (required reading) and informative (additional context).

Not every RFC follows this exactly, but the pattern is consistent enough that you can navigate an unfamiliar RFC quickly.

The Keyword Convention

RFC 2119 defines the meaning of requirement keywords:

• MUST / MUST NOT: absolute requirement. Implementations that violate a MUST are non-conformant.
• SHOULD / SHOULD NOT: recommended, but there may be valid reasons to deviate. You need to understand the implications.
• MAY: genuinely optional. Implementations can include or omit this.

When you are reading a spec to understand what your code needs to do, focus on the MUST statements first. Those are the non-negotiable behaviors. SHOULD statements are important for correctness but allow flexibility. MAY statements describe features you might implement later.

RFCs Every Web Developer Should Know

You do not need to memorize these, but knowing they exist (and where to look things up) is valuable:

The HTTP RFCs were recently reorganized (the old 7230–7235 series was replaced by 9110–9114 in 2022). If you find yourself reading RFC 2616, stop — it is obsoleted.

How to Read an RFC Efficiently

Don’t read front-to-back like a novel. Instead:

1. Read the Abstract to confirm it covers what you need
2. Skim the Table of Contents to find the relevant section
3. Read that section, paying attention to MUST/SHOULD/MAY keywords
4. Check the examples if provided (not all RFCs have them, but many do)
5. Follow normative references only if you need deeper understanding of a referenced mechanism

Most of the time, you need one or two sections out of a 100-page RFC. The rest is context you can ignore unless you are building a protocol implementation from scratch.

Drafts vs. Published RFCs

Before an RFC is published, it goes through an Internet-Draft phase. Drafts are working documents — they expire, they change, they might never become RFCs. If you find an draft-ietf-* document, check whether a final RFC was published before relying on it.

The lifecycle: Individual Draft → Working Group Draft → Last Call → IESG Review → RFC Publication. This process takes months to years.

Practical Tip

When debugging a protocol issue (unexpected HTTP behavior, a TLS handshake failure, a malformed JWT), the relevant RFC is the authoritative source. Stack Overflow answers and blog posts interpret the spec — sometimes correctly, sometimes not. The RFC itself tells you what MUST happen. Start there when the stakes are high.