--- title: "How to read IETF RFCs and W3C protocol specs without missing a MUST NOT." description: "Highlight IETF RFC sections (HTTP, OAuth, TLS, DNS), ABNF grammars, or ASCII packet diagrams and extract MUST/SHOULD requirements and state-machine rules." canonical_url: "https://vezz.me/use-cases/explain-rfc-and-ietf-specifications/" type: "pseo-use-cases" category: "use-cases" topic: "Protocol & Spec Engineering" intent: "Best for systems, security, and web engineers reading RFCs on datatracker.ietf.org, rfc-editor.org, W3C, and WHATWG." --- # How to read IETF RFCs and W3C protocol specs without missing a MUST NOT. Highlight IETF RFC sections (HTTP, OAuth, TLS, DNS), ABNF grammars, or ASCII packet diagrams and extract MUST/SHOULD requirements and state-machine rules. > **Best fit:** Best for systems, security, and web engineers reading RFCs on datatracker.ietf.org, rfc-editor.org, W3C, and WHATWG. ## Live Webpage Walkthrough - **Source:** RFC 9110 (HTTP Semantics) — Section 15.4.4: 303 See Other (`datatracker.ietf.org/doc/html/rfc9110#section-15.4.4`) - **Recommended Context Mode:** Detailed **Highlighted Passage:** > A 303 response to a GET request indicates that the origin server does not have a representation of the target resource that can be transferred by the server over HTTP. However, the Location field value refers to a resource that is descriptive of the target resource... Except for responses to a HEAD request, the representation of a 303 response ought to contain a short hypertext note with a hyperlink to the same URI reference provided in the Location header field. A user agent MAY automatically redirect a 303 response to the URI reference in Location using a GET request, regardless of the original request method. **User Question (Shortcut):** "What happens to a POST request when the server returns 303 vs 307, and what must the client/server do?" **Vezz me On-Screen Answer:** 1. **Method Rewrite (POST -> GET)**: On `303 See Other`, a user agent **MAY** automatically follow the `Location` URI using a **`GET` request** regardless of the original method (dropping the POST body). By contrast, `307 Temporary Redirect` forbids changing the request method. 2. **Server Obligations**: Provide the target URI in `Location` and (except for `HEAD`) include a short hypertext body linking to that URI. 3. **Primary Use Case**: Post/Redirect/Get (PRG) after form submissions or async job creation. **Suggested Follow-Ups:** - "Generate 3 conformance test cases for an HTTP client handling 303 on POST, HEAD, and GET." - "How does RFC 9110 define 303 caching behavior?" ## Step-by-step workflow 1. **Highlight the RFC section or ABNF grammar block**: On datatracker.ietf.org or rfc-editor.org, highlight the protocol subsection, state machine description, or ABNF syntax rule you are implementing. 2. **Ask for RFC 2119 obligations by role (Client vs Server vs Proxy)**: Press Ctrl+Shift+X and ask Vezz me to tabulate every MUST, MUST NOT, and SHOULD requirement separated by actor. 3. **Generate valid and malformed wire test cases**: Ask Vezz me for 3 valid wire inputs and 3 malformed edge-case inputs that a compliant parser MUST reject. ## Why secondary blog posts get OAuth, HTTP, and CORS specs wrong Most subtle security and interoperability bugs in OAuth 2.0, OIDC, HTTP caching, and WebAuthn happen because developers rely on simplified tutorials instead of the authoritative specification. - Separates strict normative mandates (`MUST`, `MUST NOT`, `REQUIRED`) from implementation guidance (`SHOULD`, `MAY`) - Splits obligations cleanly by role: User-Agent / Client vs Origin Server vs Intermediary / Proxy - Translates formal ABNF syntax rules and ASCII bit-field diagrams into concrete byte/header examples ## Turn specification prose into unit test vectors Use Vezz me directly on `datatracker.ietf.org`, `w3.org`, and `whatwg.org` while writing your parser or middleware. - Generate table-driven test cases in Go, Rust, TypeScript, or Python directly from the highlighted RFC section - Check whether an older RFC requirement was obsoleted or modified in a newer revision (e.g., RFC 2616 -> RFC 7230 -> RFC 9110) - Pair with our downloadable RFC & System Design Critic prompt preset ## Reading IETF RFCs & W3C Standards Comparing in-page RFC analysis against raw ASCII reading and secondary blogs. | Method | Strengths | Tradeoffs | | --- | --- | --- | | Vezz me on datatracker.ietf.org | Extracting role-based MUST/MUST NOT checklists and ABNF test vectors from the primary spec | Works section-by-section as you highlight | | Secondary tutorial blog posts | Quick high-level conceptual introduction | Frequently conflates SHOULD with MUST and omits edge-case security rules | | Reading 150-page ASCII RFC unaided | Complete end-to-end specification review | Easy to miss a single conditional 'MUST NOT' buried in a long paragraph | ## Frequently asked questions ### Can Vezz me translate ABNF (Augmented Backus-Naur Form) into a regular expression or parser rule? Yes! Highlight the ABNF grammar in any RFC, press Ctrl+Shift+X, and ask Vezz me to explain the allowed characters and generate matching/non-matching test strings. ### Does it work on ASCII packet diagrams in RFCs? Yes. Because ASCII diagrams are plain text, highlighting the diagram and field descriptions lets Vezz me calculate exact bit offsets and byte masks. ### Is there a prompt preset for RFC and design doc reviews? Yes—download the RFC & System Design Critic preset from our Prompt Library. ## Related guides - [RFC & System Design Critic Preset](https://vezz.me/prompts/rfc-and-system-design-critic/): 1-click preset for evaluating protocol specs and engineering RFCs. - [Explain API Documentation](https://vezz.me/use-cases/explain-api-documentation/): Decode REST, GraphQL, and webhook documentation faster. - [Vezz me on MDN & Developer Docs](https://vezz.me/for/mdn-and-developer-docs/): How to pair MDN Web Docs and WHATWG/W3C specs with Vezz me. - [Decode Regex, SQL & Config Files](https://vezz.me/use-cases/decode-regex-sql-and-config-files/): Turn complex syntax patterns into readable breakdowns.