Navigating RFC Documents

RFC documents range from 5 pages to hundreds. The skill is knowing where to look and what to extract, not reading every word in order.

The Anatomy of an RFC

Every RFC follows a consistent structure. The top-level sections, in order:

Header block: RFC number, title, authors, date, status (Standards Track, Informational, Best Current Practice, etc.), and whether it obsoletes or updates other RFCs. Check this first — an outdated RFC may have been superseded.

Abstract: 2-5 sentences summarizing the purpose. Use this to confirm the RFC covers what you need.

Status of This Memo and Copyright Notice: administrative text — skip.

Table of Contents: the navigation map. Look for sections named "Syntax", "Format", "Message Format", "Grammar", "ABNF", "Definitions", "Formal Syntax" — these are where the rules live.

Introduction: motivation and scope. Often contains the most readable explanation of the problem domain. Worth reading for context.

Terminology or Definitions: look here for how the RFC defines terms. "Address", "domain", "local part" may have specific meanings that differ from casual usage.

Core specification sections: the rules. Dense but precise.

Examples: concrete valid and invalid examples. Copy these directly into test cases.

Security Considerations: attack vectors and known vulnerabilities. Read this always.

IANA Considerations: registry management. Usually skip unless you need to verify a specific value.

References and Appendices: normative references (things the RFC relies on) and informative references (things cited for context).

Finding Test Cases Without Reading Everything

The most efficient approach is to search for specific keywords:

Search for "MUST": Every sentence containing "MUST" is a requirement. Write down the subject and the constraint. Example from RFC 5322: "A field name MUST be composed of printable US-ASCII characters." → test case: field name with non-printable characters must be rejected.

Search for "MUST NOT": Every sentence is a prohibition. Example: "The local-part portion is a domain-dependent string [...] a single dot, '.' MUST NOT appear in the beginning or end of a dot-atom." → test case: local part starting with dot must be rejected.

Search for "example": Most RFCs have explicit examples. These are ready-made test cases.

Search for "invalid": Sections describing what is invalid are the best source of negative test cases.

Search for "obs-": Obsolete syntax sections describe forms that are no longer generated but must still be accepted. These are your edge cases that most validators fail.

Understanding ABNF

ABNF (Augmented Backus-Naur Form) is the formal grammar notation used in most RFCs. You don't need to implement a parser — you need to read it as a description of valid forms.

Core operators:

• / = alternation: a / b means "a or b"
• * = repetition: *a means "zero or more a"; 1*a means "one or more a"; 2*4a means "2 to 4 a"
• [] = optional: [a] means "a is optional"
• () = grouping: (a b) means "a followed by b"
• "..." = literal characters: "." means a literal dot
• %x = hex character value: %x41-5A means characters from U+0041 (A) to U+005A (Z)

Reading example:

dot-atom-text = 1*atext *("." 1*atext)

Read as: "one or more atext characters, optionally followed by one or more groups of (a literal dot followed by one or more atext characters)."

This tells you: valid forms include abc, abc.def, abc.def.ghi. Invalid forms include .abc (starts with dot), abc. (ends with dot), abc..def (consecutive dots).

From one line of ABNF, you have six test cases.

The RFC Supersession Trap

Always check whether the RFC you found is the current version. RFCs are never edited — they are replaced by new RFCs that "obsolete" or "update" the old ones. The header block says "Obsoletes: RFC XXXX" or "Updates: RFC XXXX".

Important supersessions relevant to web testing:

• RFC 2616 (HTTP/1.1) → obsoleted by RFC 7230-7235 → further updated by RFC 9110-9112
• RFC 2822 (email) → obsoleted by RFC 5322
• RFC 2396 (URI) → obsoleted by RFC 3986
• RFC 2965 (cookies) → obsoleted by RFC 6265

Testing against an obsoleted RFC may produce outdated test cases that no longer represent the standard.