RFC as Testing Oracle

An oracle is the source of truth for expected behavior — the authority you appeal to when you need to know whether a test result is correct or incorrect. For protocol-defined inputs, the RFC is the oracle.

The Two-Step Process

Step 1: Extract expected behavior from the RFC

Read the relevant sections and produce a catalog of:

Valid forms (from examples and "MUST accept" clauses)
Invalid forms (from examples and "MUST reject" clauses)
Edge cases (from "obsolete syntax", "SHOULD", and examples labeled "unusual")
Length limits (from numerical constraints in the spec)

Step 2: Compare actual system behavior against expectations

Submit each item in your catalog and record what actually happens. Any divergence is a finding. A finding may be:

A bug: the system rejects valid input (RFC says accept)
A bug: the system accepts invalid input (RFC says reject)
A known deviation: the system intentionally deviates from the RFC for documented reasons
An RFC ambiguity: the RFC is unclear and the implementation chose one interpretation

Building the RFC-Derived Test Suite

Using RFC 5322 email local part as an example:

Valid forms (from atext definition):

user → simple local part
user123 → local part with digits
user+tag → + is valid atext
user_name → _ is valid atext
user.name → dot-separated atext
user.name.here → multiple dots
!#$%&'*+/=?^_\{|}~` → all valid atext symbols in one string

Invalid forms (from dot rules and atext definition):

.user → leading dot
user. → trailing dot
user..name → consecutive dots
user name → space without quotes
user@extra → unquoted @ (would be interpreted as domain separator)

Edge cases (from quoted-string and obs- sections):

"user name" → quoted string with space (valid, but often rejected)
"user@extra" → quoted string with @ (valid, but almost always rejected)
"user\"name" → quoted string with escaped quote (valid)

Length limits (from RFC 5321, which constrains the wire format):

Local part: max 64 characters
Full address: max 320 characters

Documenting Divergence

When the system's behavior diverges from the RFC, document it precisely:

Finding: Plus sign in local part is rejected
RFC says: "+" is listed as valid atext in section 3.2.3 of RFC 5322
System behavior: POST /api/user/register with email "user+tag@example.com" 
  returns HTTP 400 with body {"error":"Invalid email format"}
Classification: Implementation bug — over-restrictive validation
Impact: Real users with Gmail-style tagged addresses cannot register
Severity: Medium — affects valid addresses in common use

This format is precise enough to be actionable. The developer knows exactly what the RFC says, what the system does, and what the business impact is.

When Practical Behavior Wins

Some RFC divergences are not bugs but pragmatic choices:

Example 1: Quoted string local parts

RFC 5322 allows "user name"@example.com. No major mail provider generates these addresses. If an application never accepts user input with quoted local parts, this is a safe deviation — the RFC allows it but no real user would submit it. Document it as a known deviation, not a bug.

Example 2: Extremely long TLDs

RFC allows TLDs of any length. ICANN currently has TLDs up to about 24 characters. An application that rejects TLDs longer than 24 characters is technically over-restrictive per RFC but practically correct given current ICANN registry constraints. Document as a known practical limitation.

Example 3: Internationalized email

RFC 6532 extends RFC 5322 to allow UTF-8 in email addresses. An application that doesn't implement RFC 6532 is conformant with RFC 5322 (which does not require internationalized support) but non-conformant with RFC 6532. Determine which standard the application claims to implement.

The key question for each divergence: "Does this affect real users with valid inputs?" If yes, it's a bug. If no reasonable user would submit the diverging form, it's a documented limitation.

The Limits of RFC as Oracle

RFC conformance is a minimum bar, not a complete specification. An application can be fully RFC-conformant and still:

Reject inputs that are technically valid but never used in practice
Accept inputs that are technically valid but carry security risks
Have UX behavior that differs from user expectations even if technically correct