StacklogA junior engineer on my team asked recently whether she should "just read RFC 9110" to understand HTTP semantics properly. The honest answer was: not cover to cover, not on a first pass, and not without a reason to be there. RFCs are reference documents written by committee for implementers checking specific edge cases, not tutorials, and reading them like a tutorial is the single most common reason people bounce off them and conclude the whole genre is impenetrable.
I read RFCs regularly, not because I enjoy standards prose for its own sake, but because when a library's documentation disagrees with another library's behavior, or when I'm debugging something at the protocol level, the RFC is the actual source of truth and everything else is someone's interpretation of it. Over the years I've developed a method that makes this tractable, and it's different enough from "reading a document front to back" that it seemed worth writing down.
The core idea: treat an RFC as a reference you query, not a book you read, and know in advance which of three categories the document falls into before you start, because each category deserves a completely different reading strategy.
Three kinds of RFCs, three ways to read them
- Protocol specifications (HTTP, TLS, DNS) — these define wire formats and required behavior. You read the section relevant to your question, following cross-references as needed, and you treat MUST/SHOULD/MAY language as load-bearing, because it is: RFC 2119's keyword definitions are the actual contract.
- Best practices / informational RFCs — softer documents describing recommended approaches rather than hard requirements. Worth skimming for context but not worth parsing word by word, since nothing in them is normative.
- Historical / obsoleted RFCs — superseded documents still floating around search results. Always check the RFC's status header first; an "Obsoleted by" notice means you're about to spend an hour understanding a rule nobody is required to follow anymore.
Start with the table of contents and the terminology section, every time
Before reading any body text, I read the table of contents fully and then jump straight to the terminology or definitions section, which is almost always early in the document. RFCs define their own vocabulary precisely, and words that sound like plain English (like "idempotent," or "safe" in the HTTP methods sense) often carry a specific technical meaning in the spec that differs subtly from how you'd use the word casually. Skipping this section is the single biggest cause of misreading a requirement later.
Follow the keyword language like a legal contract
RFC 2119 (and its clarifying successor, RFC 8174) define MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY as having specific binding weight. Once you internalize that a SHOULD is a recommendation with room for exceptions a competent implementer would understand, while a MUST has none, entire paragraphs become easier to parse quickly, because you're pattern-matching against five known categories of obligation rather than parsing each sentence's intent from scratch.
# A rough mental model while reading:
MUST / MUST NOT -> non-negotiable, breaking this breaks interop
SHOULD / SHOULD NOT -> strong default, deviate only with a documented reason
MAY -> genuinely optional, implementers can differ safelyUse the errata and the diff against the RFC it obsoletes
Every published RFC has a public errata page, and checking it before trusting an ambiguous passage has saved me more than once — a surprising number of widely-implemented behaviors exist because of a documented erratum correcting the original text, and the main document never gets reprinted to reflect it. When an RFC explicitly updates or obsoletes an earlier one, reading a diff-style comparison (several third-party sites generate these) is usually faster than reading both documents independently and reconciling them in your head.
Don't confuse an Internet-Draft with an actual RFC
Search results frequently surface Internet-Drafts — the working documents the IETF process produces before something is formally published as an RFC — right alongside finished RFCs, and they look similar enough at a glance that it's easy to cite one as settled when it's still actively changing. Drafts expire after six months without an update and get silently pulled or superseded, which means a draft you bookmarked and trusted a year ago may no longer exist in the form you remember, or may never have been finalized at all. Checking whether a document you're reading is a draft or a published RFC takes about ten seconds and avoids building an argument, or an implementation, on a moving target.
Know when to stop reading the RFC and go read the implementation
RFCs describe required behavior, not how anything is actually implemented, and for some questions — performance characteristics, how a specific library handles a malformed input in practice — the spec genuinely won't have your answer. The skill isn't reading RFCs harder, it's recognizing quickly when you've crossed from "this is a protocol semantics question the spec will answer" into "this is an implementation detail question only the source code or the actual wire traffic will answer," and switching tools accordingly instead of re-reading the same section a fourth time hoping it'll suddenly make sense.
Why this is worth doing at all
Most engineers never read a primary specification and build an entire career on secondhand summaries, blog posts, and whatever Stack Overflow answer ranked highest. That's usually fine. But the handful of times a year when it isn't fine — a genuinely ambiguous bug, a disagreement between two library authors about correct behavior, a security-relevant edge case — being able to go to the actual document and read it with some confidence is a disproportionately useful skill relative to how little time it takes to build once you have a method instead of just gritting your teeth and reading top to bottom.