What Is an RFC and Why Does It Matter?

The Problem with "I Think It Works Like This"

A developer implements email validation. They write a regex based on their mental model of what an email address looks like. It rejects user+tag@example.com because they didn't know + is valid. It accepts user@.example.com because their regex doesn't check for leading dots in domains. It rejects "user name"@example.com because spaces look wrong. All of these decisions are wrong — and all could have been avoided by reading the specification.

RFC documents are the specifications. They define exactly what is valid, what is invalid, and what is left to implementors. When you derive test cases from an RFC, you are not guessing — you are reading the authoritative source.

What RFC Stands For

"Request for Comments" is a historical name. In the early days of the ARPANET, "RFC" documents were genuinely proposals inviting comment. Modern RFCs (those produced by the IETF's standards process) are not requests for comments — they are finalized technical standards. The name stuck.

RFCs are produced by:

• IETF Working Groups: groups of engineers and researchers working on specific protocol areas
• Independent Submission: individuals or groups outside the formal IETF process
• IANA (Internet Assigned Numbers Authority): RFCs that define registry values

The most important RFCs for web application testing are produced by IETF working groups and have the status "Standards Track" or "Internet Standard."

How to Find the Relevant RFC

For most web application topics, the RFC is discoverable via:

1. Search by protocol name: "email RFC", "HTTP RFC", "cookie RFC", "URL RFC"
2. Check Wikipedia: the Wikipedia article for a protocol usually cites the defining RFC
3. Check the standard directly: the IETF maintains datatracker.ietf.org which lists all RFCs

Key RFCs for application testing:

• HTTP/1.1: RFC 7230-7235 (superseded by RFC 9110-9112)
• URLs/URIs: RFC 3986
• Email format: RFC 5322
• Email transport: RFC 5321
• Cookies: RFC 6265
• JSON: RFC 8259
• JWT: RFC 7519
• TLS: RFC 8446
• Domain names: RFC 1034, RFC 1035, RFC 1123

When to Use RFC vs. Practical Behavior

RFCs define what implementations MUST and SHOULD do. They do not define what implementations actually do. There is often a gap.

Use the RFC when:

• Writing test cases for a validator that claims RFC conformance
• Testing an API that processes RFC-defined values (emails, URLs, cookies)
• Building a test suite for a parser or serializer
• Finding edge cases that are valid per spec but commonly rejected by implementations

Use practical behavior (what popular implementations do) when:

• Testing interoperability between systems
• Testing user-facing validation where the UI must match what real services accept
• The RFC has ambiguities that are resolved differently by major implementations

In most cases, start with the RFC to identify what should be valid, then test against the actual implementation to find the divergence. The divergence is your bug report.

Why This Matters for Test Design

A tester who derives test cases from requirements and intuition will find the 80% of bugs that common inputs expose. A tester who derives test cases from the RFC will find the remaining 20% — the edge cases that slip through because the developer never read the spec.

The + in email addresses is a classic example. It appears in hundreds of real-world email addresses (Gmail's address tagging feature, mailing list addresses, disposable email services). Any validator that rejects it fails for real users. The RFC clearly defines it as valid. No amount of intuitive testing will find this bug — you need the RFC.