RFC 8174 Quiz

**Explanation:** **Terms:** must (lowercase), normative requirement, BCP 14, ambiguity. A requirement needs an agreed interpretation rule so implementers can test conformance consistently. **Correct (B):** Without explicit BCP 14 interpretation, readers may disagree whether lowercase must is a strict conformance requirement or just strong prose. That disagreement leads to inconsistent implementations. **Options:** - A (incorrect): Nothing forces all readers to interpret lowercase must as normative unless the spec explicitly defines that convention. - B (correct): This is the real risk: ambiguity in normative intent and therefore inconsistent behavior. - C (incorrect): The sentence is still meaningful English. The issue is clarity, not validity. **Related:** If the requirement is security relevant, write it so conformance can be checked and cite BCP 14 interpretation rules.

**Explanation:** **Terms:** MUST, normative keyword, BCP 14 boilerplate, case sensitivity. The key is making the interpretation rule explicit, not assuming readers will infer it from capitalization. **Correct (A):** BCP 14 provides a clear pattern: include boilerplate that defines how to interpret the keywords, then write requirements so implementers can test conformance. Case alone should not be the signal. **Options:** - A (correct): This makes "must" unambiguous as a normative MUST, as long as the document states the interpretation rules. It also helps reviewers and toolchains. - B (incorrect): Lowercase by itself increases ambiguity, which RFC 8174 is trying to reduce. - C (incorrect): Examples are helpful, but replacing normative requirements with examples makes conformance and interoperability fragile. **Related:** A good spec makes requirements machine-checkable where possible and human-checkable otherwise, with explicit normative language.

**Explanation:** **Terms:** implementer ambiguity, BCP 14 keywords, MUST, SHOULD. The goal is to make keyword interpretation unambiguous, so requirements become testable rules. **Correct (A,C,D):** These practices directly improve interpretability and testability, which is the point of using normative keywords. **Options:** - A (correct): Explicitly defining how BCP 14 keywords are interpreted removes ambiguity about MUST/SHOULD/MAY usage. - B (incorrect): Unlabeled mixing makes it unclear what is required vs informative, which harms interoperability. - C (correct): A MUST that can be tested reduces disputes and implementation divergence. - D (correct): SHOULD implies valid exceptions. Stating the rationale and when an exception applies keeps behavior predictable. **Related:** In reviews, ask "How would we write a conformance test for this MUST" and "What exact exception makes this a SHOULD".

**Explanation:** **Terms:** must (lowercase), normative vs descriptive, BCP 14 boilerplate. The key risk is interpretive ambiguity, which RFC 8174 targets. **Correct (C):** Without the boilerplate, different readers may treat "must" as a strong suggestion rather than a normative MUST. That leads to inconsistent implementations and interoperability issues. **Options:** - A (incorrect): Lowercase "must" is not automatically the RFC 2119 keyword unless the document states that rule. - B (incorrect): The sentence can stay, but the document should clarify whether it is normative. - C (correct): Ambiguity is exactly the problem, and it is resolved by explicit rules and consistent keyword usage. **Related:** For security statements (like certificate validation), ambiguity is especially costly, because implementers might ship non-conformant behavior.

**Explanation:** **Terms:** BCP 14 style, normative section, MUST. RFC 8174 and RFC 2119 are about writing clear normative requirements using keywords like MUST. **Correct (B):** MUST is a clear, testable requirement. "Reject malformed input" can be turned into conformance tests and improves interoperability and safety. **Options:** - A (incorrect): "might be nice" is subjective and not testable. It does not express a requirement. - B (correct): MUST signals a mandatory requirement with no exceptions (unless explicitly stated). - C (incorrect): "could maybe" is ambiguous and does not communicate conformance criteria. **Related:** If you want flexibility, use SHOULD with explicit exceptions rather than informal hedging.

**Explanation:** **Terms:** required for interoperability, normative keyword, MUST. In BCP 14, MUST indicates an absolute requirement needed for interoperability or safety. **Correct:** MUST is used when the rule is mandatory and implementations cannot skip it without breaking interoperability or correctness. **Why others are wrong:** SHOULD allows valid exceptions, and MAY indicates optional behavior. If the statement says "required for interoperability", it should be MUST, not SHOULD or MAY. **Related:** When you write a MUST, also define what "interoperability" means in that context, such as message parsing, security checks, or protocol state machines.