ToppyMicroServices

RFC 2119 Key Words Quiz

Use MUST/SHOULD/MAY (BCP 14) precisely

🇺🇸 🇯🇵
0 / 0

References (URLs)

Q1: You are writing a spec. Which sentence is the best fit if certificate validation is required for conformance?

Multiple Choice
**Explanation:** RFC 2119 Section 1 reserves MUST for an absolute requirement of the specification; SHOULD (Section 3) permits justified exceptions, and MAY (Section 5) makes the behavior optional. - `MUST`: mandatory for conformance. - `SHOULD`: strong recommendation; exceptions may exist with justification. - `MAY`: optional; implementers can choose. A: `MUST` makes validation mandatory for every conforming implementation, matching the premise. B: `SHOULD` permits a carefully justified exception, so validation would not be unconditional. C: `MAY` makes validation optional and therefore does not establish a conformance requirement.

Q2: You want to strongly recommend HTTP/2 support, but allow constrained environments. Which key word fits best?

Multiple Choice
**Explanation:** RFC 2119 Section 3 uses SHOULD when there may be valid reasons to ignore an item, but only after the full implications are understood and carefully weighed. `SHOULD` means “do this in general,” but exceptions can exist and must be justified. A specification should also describe what can justify an exception so implementers can assess it consistently. A: `MUST` removes the exception path and would make a constrained implementation non-conformant. B: `MAY` expresses permission, but not the strong general expectation in the premise. C: `SHOULD` states the general expectation while allowing a carefully considered exception.

Q3: Which reference sentence best avoids ambiguity about key words (BCP 14)?

Multiple Choice
**Explanation:** RFC 8174 Section 2 updates the convention: under the standard BCP 14 boilerplate, the defined meanings apply only to the all-capitals forms. - **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. A: Lowercase words do not automatically carry the BCP 14 meanings under RFC 8174. B: Uppercase is appropriate, but this wording omits the RFC 8174 update and the BCP 14 reference. C: It names BCP 14 and both RFCs, making the intended interpretation and casing rule explicit.

Q4: You need a strong recommendation with an explicit exception path. Which wording is clearest?

Multiple Choice
**Explanation:** RFC 2119 Section 3 supplies the exception-aware SHOULD, while Section 1 supplies the separate mandatory requirement to document an exception. - `SHOULD`: do this unless there is a justified exception. - `MUST`: mandatory requirement (here: mandatory documentation if you deviate). - `MAY`: optional. A: “Except when they cannot” leaves the exception undefined and makes conformance difficult to test. B: `SHOULD` expresses the default, while the separate `MUST` makes documentation of a deviation testable. C: `MAY` makes X optional; the informal word “recommended” does not restore a normative expectation.

Q5: Which draft clauses fail to define the stated conformance boundary?

Multi-Select

An Agent Card profile states that every accepted Card is authenticated and that independent implementations must interoperate. Its draft contains the following clauses.

**Explanation:** The key word alone cannot repair an undefined condition or a conflict with the profile's stated guarantee. RFC 2119 Section 6 says imperatives are for behavior required for interoperability or to limit harm, and Section 7 asks authors to explain security consequences. A: Selected. “If practical” leaves the mandatory condition to each implementation, so conformance cannot be evaluated consistently. B: Selected. The permission contradicts the unconditional authentication claim unless the profile defines a narrower claim or a precise exception and its security consequences. C: Selected. “Quickly” and the missing retry limit do not define observable behavior and can also amplify load. D: Not selected. This applies RFC 2119 Section 5: an optional feature can be absent while peers remain interoperable, possibly with reduced functionality. E: Not selected. A clearly identified informative example does not change conformance requirements.

Q6: Which revision gives independent implementations the clearest security and conformance boundary?

Multiple Choice

A draft says, “Clients should verify the server certificate.” One implementation performs WebPKI path and name validation, another checks only expiry, and a third uses a pre-provisioned certificate pin. The intended design permits either WebPKI validation or the explicitly configured pinning mode, and every validation failure must abort the connection.

**Explanation:** RFC 2119 Sections 1–5 supply requirement levels, not the missing certificate-validation algorithm or mode selection. RFC 8174 Section 2 likewise clarifies capitalization; it does not turn an undefined verb into a testable requirement. A: “Securely” preserves the ambiguity, and `SHOULD` creates an exception path not present in the intended design. B: `MUST` states strength but still allows incompatible and insecure interpretations of “verify.” C: Correct. It defines the permitted alternatives, the mandatory behavior within each alternative, and the common failure result. D: Documentation does not satisfy the stated requirement that every connection use one of the two validation modes.

Q7: Which addition correctly completes the interoperability contract for this optional extension?

Multiple Choice

An A2A profile says, “Payload compression is OPTIONAL.” A sender that implements compression always uses it. A conforming receiver without the extension then cannot decode the request.

**Explanation:** RFC 2119 Section 5 says implementations with and without an optional item must be prepared to interoperate, except for the feature the option itself provides. A: This makes compression mandatory in substance and contradicts the advertised extension status. B: Correct. Negotiated or otherwise unambiguous support lets both peers fall back to the common base representation. C: Failure to process the entire request is not merely loss of the compression benefit; the base operation no longer interoperates. D: Lowercase changes the BCP 14 interpretation but does not repair the wire-level incompatibility.

Q8: Which requirement makes the logging boundary testable without weakening the stated policy?

Multiple Choice

A threat analysis treats possession of raw access tokens or client secrets from logs as an attack. Request IDs may be logged, but secret values must never reach application, proxy, or diagnostic log sinks. The draft currently says, “Implementations SHOULD avoid logging sensitive data.”

**Explanation:** RFC 2119 Section 2 can express the absolute prohibition, while Sections 6 and 7 support using precise imperatives where behavior can cause harm and explaining the security consequence. The threat model, not RFC 2119 alone, supplies the no-logging policy. A: A `SHOULD` exception would contradict the premise and expose exactly the values the threat analysis protects. B: Correct. The requirement identifies the data, the covered sinks, the enforcement point, and the allowed non-secret output. C: An attacker can obtain the same credentials from the unspecified sinks, so the stated boundary is incomplete. D: Reversible log content still exposes credentials to anyone who obtains the decryption capability and violates the “must never reach a sink” requirement.

Q9: Which wording most precisely expresses the defined stale-metadata exception?

Multiple Choice

Clients normally reject stale Agent Cards. A defined disaster-recovery mode may accept a Card up to 10 minutes stale only when an operator has enabled the mode and the Card's signature still validates. No other stale use is allowed.

**Explanation:** RFC 2119 Section 4 allows carefully weighed exceptions to `SHOULD NOT`, but the premise already defines the complete exception. Conditional normative requirements communicate that boundary more precisely. A: This creates unspecified exceptions beyond the defined recovery mode. B: Correct. It prohibits all other stale use and confines the permission to the stated mode, age, operator action, and valid signature. C: This contradicts the required recovery behavior. D: This makes stale acceptance generally optional and weakens signature validation, which is broader than the premise.

Q10: Which review conclusions follow from BCP 14 for this audience-alias extension?

Multi-Select

A base profile says a verifier MUST match a token's audience to the requested resource. An extension says a verifier MAY accept audience aliases, but defines neither alias syntax nor their trusted source, and says nothing about peers that do not implement aliases. The profile still claims interoperability among all conforming implementations.

**Explanation:** RFC 2119 Section 5 makes an item optional while requiring implementations with and without it to remain interoperable, except for the optional function itself. Sections 6 and 7 require care when the choice affects interoperability or security. RFC 8174 gives special meanings only to the uppercase forms under the BCP 14 convention. A: Selected. Requirement strength cannot substitute for the missing alias data model and trust rule. B: Selected. The profile must define what happens when one peer lacks the optional feature. C: Selected. A behavior necessary to the profile's unconditional interoperability claim cannot simultaneously be left to implementation choice. D: Not selected. RFC 2119 warns against unnecessary mandates; the correct level depends on the actual scope and consequences. E: Not selected. Lowercase words retain their ordinary English meanings under RFC 8174.