ToppyMicroServices

RFC 8174 Quiz

Resolve MUST/SHOULD/MAY ambiguity

πŸ‡ΊπŸ‡Έ πŸ‡―πŸ‡΅
0 / 0

Primary references

These questions test the case-sensitive BCP 14 convention without treating every normative sentence as a keyword sentence. Section references are to RFC 8174 unless RFC 2119 is named.

Q1: Which statements are part of RFC 8174's clarification? Select three.

Multi-Select
RFC 8174 Section 2 makes A, C, and D explicit. B is false: the keywords are available for clarity and consistency, but their use is not required. This distinction prevents both case-insensitive keyword parsing and the mistaken belief that prose without a keyword must be informative.

Q2: How should the reviewer classify lowercase should here?

Multiple Choice

A specification includes the RFC 8174 recommended boilerplate. A later sentence says, "Clients should retry after a timeout."

A: RFC 8174 Section 2 makes case material. B: Under the stated boilerplate, only all-capitals SHOULD has the special meaning; lowercase should remains ordinary English. C: Changing case does not map one keyword to another. D: Lowercase prose remains valid and may still communicate normative intent through its wording and context.

Q3: Is the reviewer's rejection justified by RFC 8174?

Multiple Choice

A normative protocol section says, "Implementations are required to reject frames with an invalid length." A reviewer calls the sentence non-normative solely because it contains no all-capitals keyword.

A and B contradict RFC 8174 Section 2, which says much normative text does not use the keywords. C is also wrong: lowercase required has its normal English meaning, not the special BCP 14 meaning. D correctly separates the sentence's normative force from keyword tagging; its context and wording still establish a requirement.

Q4: Does sentence-initial Must carry the special BCP 14 meaning?

Multiple Choice

A document adopts the RFC 8174 boilerplate. A checklist item begins, "Must the client retain the nonce?"

A: Section 2 says the special meanings apply only when the words are in all capitals; title case is ordinary English. B and C invent activation rules that RFC 8174 does not define. D overreaches: the issue here is exact capitalization, not a universal rule about grammatical form.

Q5: May the publication formatter apply this case change?

Multiple Choice

A source specification adopts the RFC 8174 boilerplate and says, "The verifier MUST reject an invalid proof." A style formatter rewrites MUST as Must in the published HTML.

A and B ignore the exact all-capitals condition in RFC 8174 Section 2. C is correct: under this boilerplate the published Must has only its normal English meaning, so the transformation changes the explicit keyword signal. D is too broad; transformations that preserve the words and case are not prohibited by RFC 8174.

Q6: What should the editor change before publication?

Multiple Choice

A draft cites RFC 8174 but declares, "must, should, and may have the BCP 14 meanings regardless of capitalization." Its tooling then parses keywords case-insensitively.

A misstates RFC 8174 Section 2, which limits the special meanings to all-capitals forms. B separates the standard convention from a deliberately different local rule. C is unnecessary because lowercase words retain normal English meanings. D reverses authority: tooling should implement the declared document convention, not silently redefine it.

Q7: Should the linter automatically uppercase every occurrence?

Multiple Choice

A linter finds lowercase must, should, and may in explanatory paragraphs and proposes converting all of them to uppercase keywords.

A and B contradict RFC 8174 Section 2: lowercase forms have normal English meanings, and keyword use is optional. C invents a location-based ban. D is correct because uppercasing changes the semantic signal; a linter can flag candidates but should not manufacture requirements without author review.

Q8: How should a reviewer describe this boilerplate update?

Multiple Choice

A new draft uses all-capitals NOT RECOMMENDED but retains an older declaration that cites only RFC 2119 and does not list that phrase. An editor proposes the RFC 8174 boilerplate citing RFCs 2119 and 8174.

A: RFC 8174 Section 2 says authors following the guidelines should incorporate the updated phrase, including NOT RECOMMENDED and both references. This is document-authoring guidance, not a wire-protocol requirement. B confuses editorial clarity with peer behavior. C changes the requirement level. D contradicts the all-capitals-only condition.

Q9: Which publication policy preserves the normative signal?

Multiple Choice

An English specification adopts RFC 8174. A Japanese translation replaces MUST with ordinary Japanese prose, and a conformance extractor is expected to process the translation as if it retained the same keyword markup.

A and B invent cross-language rules that RFC 8174 Section 2 does not define. C makes the normative source and machine marker explicit; a translation may convey the prose meaning, but an extractor cannot infer the all-capitals English keyword after it has been removed. D ignores the case-sensitive convention.

Q10: Can the gateway's case-insensitive requirement merger be trusted?

Multiple Choice

An A2A profile imports rules from Spec A, which adopts RFC 8174 and uses MUST, and Spec B, which uses lowercase must without a BCP 14 declaration. A gateway merges both texts and marks every case-insensitive match as a BCP 14 MUST.

A: RFC 8174 Section 2 does not let an importing document retroactively change another text's capitalization convention. B: Preserve Spec A's explicit keyword semantics and evaluate Spec B's ordinary-language requirement from its own wording, status, and context. C gives tooling authority to invent semantics. D repeats the opposite error: normative text can exist without BCP 14 keywords.