RFC 2119 Key Words Quiz

**Explanation:** **Definition (key word):** - `MUST`: mandatory for conformance. - `SHOULD`: strong recommendation; exceptions may exist with justification. - `MAY`: optional; implementers can choose. **Why B is correct:** If a behavior is required to be compliant, write it as `MUST`. That makes it unambiguous and testable for conformance. **Why A/C are not:** - A (`SHOULD`): allows exceptions; readers may assume skipping is still compliant. - C (`MAY`): makes validation optional, weakening security and conformance clarity. **Related topic example:** Security requirements are a common place where accidental `SHOULD`/`MAY` turns into real-world vulnerabilities.

**Explanation:** **Definition (key word):** `SHOULD` means “do this in general,” but exceptions can exist and must be justified. **Why B is correct:** Your intent includes both “recommended” and “exceptions exist,” which is exactly the `SHOULD` pattern. **Why A/C are not:** - A (`MUST`): removes the exception path; constrained environments become non-conformant. - C (`MAY`): too weak; readers may treat HTTP/2 as a nice-to-have, not a recommendation. **Related topic example:** If you choose `SHOULD`, add a short note on what qualifies as an exception so implementers can self-assess.

**Explanation:** **Definition (key terms):** - **BCP 14**: the policy for interpreting RFC 2119 key words, updated by RFC 8174. - **ALL CAPS**: RFC 8174 clarifies that the normative meanings apply when written in uppercase. **Why C is correct:** It names BCP 14 and includes RFC 2119 + RFC 8174, making the intent explicit and aligning with modern RFC practice. **Why A/B are not:** - A: uses lowercase “must/should/may,” which reintroduces the very ambiguity RFC 8174 addresses. - B: better (ALL CAPS), but omits RFC 8174/BCP 14 context. **Related topic example:** Spec linters and conformance tooling often look for this exact BCP 14 reference line.

**Explanation:** **Definition (key words):** - `SHOULD`: do this unless there is a justified exception. - `MUST`: mandatory requirement (here: mandatory documentation if you deviate). - `MAY`: optional. **Why B is correct:** It matches the “recommended with exceptions” intent (`SHOULD`) and makes the exception accountable via a testable requirement (`MUST` document). **Why A/C are not:** - A: “MUST … except when they cannot” is vague—what counts as “cannot,” and how does a reviewer test it? - C: `MAY` undermines the recommendation; “recommended” becomes informal and easy to ignore. **Related topic example:** This pattern makes AI-assisted spec reviews easier: the tool can flag missing “reason” documentation when exceptions are taken.

**Explanation:** **Definition (key ideas):** - **Normative**: affects conformance (what must be implemented). - **Testable**: a reviewer can objectively decide pass/fail. **Why A–E are red flags:** - A: “if possible” breaks testability; implementers can always claim it wasn’t possible. - B: RFC 8174 exists because case matters; lowercase wording often becomes disputable. - C: turning security into “optional” is a common failure mode. - D: undefined adjectives make `MUST` unenforceable. - E: contradictions create incompatible implementations and endless debates. **Why F is not:** An explicitly non-normative example helps understanding without changing conformance.

**Explanation:** **Definition (key terms):** - **Testable requirement**: can be validated by an interop/conformance test. - **Define terms**: avoid “certificate”/“validate” meaning different things to different readers. - **Exceptions**: if you use `SHOULD`, specify what justifies deviation. **Why B is correct:** It gives the AI a framework: conformance, vocabulary, and exception handling. That’s what turns AI output into spec-grade text. **Why A/C are not:** - A: “stronger” is subjective; the AI can’t infer whether you mean `MUST` or just rephrasing. - C: uppercasing alone does not define behavior nor make it testable.

**Explanation:** **Definition:** - `MUST`: required for all conforming implementations. - `MAY`: optional; implementers can choose. - `MUST NOT`: prohibited. **Why B is correct:** “Mandatory base” maps to `MUST`, and “optional extension” maps to `MAY`. **Why A/C are not:** - A: makes the base non-mandatory and the extension mandatory (reversed intent). - C: makes the base optional and forbids the extension (different intent).

**Explanation:** **Definition (key word):** `MUST NOT` expresses an absolute prohibition required for conformance. **Why A is correct:** “Forbid” means “never allowed,” so use `MUST NOT`. **Why B/C are not:** - B (`SHOULD NOT`): discourages, but still allows exceptions. - C (`MAY`): explicitly permits logging secrets. **Related topic example:** When writing this, define “secrets” (tokens, passwords, keys) so the prohibition is testable.

**Explanation:** **Definition (key words):** - `MUST NOT`: absolute prohibition. - `SHOULD NOT`: discouraged; exceptions may exist with justification. - `MAY`: optional/permission. **Why B is correct:** That’s the exact scope of `SHOULD NOT`: generally avoid, but allow exceptional cases with reasoning. **Why A/C are not:** - A: if it’s never acceptable, write `MUST NOT`. - C: “optional” maps to `MAY`, not `SHOULD NOT`.

**Explanation:** **Definition (what “good” looks like):** - **Clear**: readers agree on meaning. - **Testable**: conformance can be evaluated. - **Scoped**: optional vs mandatory is explicit. **Why A–D are correct:** They cover casing + reference policy (A), conformance testability (B), exception discipline (C), and the common “optional security” pitfall (D). **Why E is not:** “More MUST” is not quality. Overusing `MUST` often creates unnecessary constraints and breaks interoperability.