ToppyMicroServices

RFC 8174 Quiz

MUST/SHOULD/MAYの曖昧性を解消する

🇺🇸 🇯🇵
0 / 0

References (URLs)

狙い: 実装者が迷わず、要件をテスト可能に読めるようにする。

Q1: 仕様に "Clients must validate certificates" とあり, BCP 14の解釈が明示されていない. 起きやすい問題はどれ

Multiple Choice
RFC 8174 は, 同じ must という単語でも, ALL CAPS と BCP 14 宣言の有無で読み方が変わる点を整理しています. 初見では「英語の must」と「規範語の MUST」を分けて読むのが大事です.
"Clients must validate" BCP 14 宣言なし 要件か強い英語かが割れる 曖昧性が残る "Clients MUST validate" BCP 14 宣言あり 適合要件として読める
**Explanation:** **Terms:** must (小文字), 規範要件, BCP 14, 曖昧性. 要件は, 実装者が同じ解釈で適合判定できることが重要. **RFCを読むときの見方:** RFC 8174 を読むときは, まず規範語が **ALL CAPS** で書かれているか, そして文書が BCP 14 の解釈を宣言しているかを見ます. ここが曖昧だと, 読み手によって must の重さが変わってしまいます. **Correct (B):** BCP 14の解釈が宣言されていないと, mustを厳密な要件として読む人と, 強い言い回しとして読む人が混ざり, 実装が割れやすい. RFC 8174 は, まさにこの曖昧性を減らすための文書です. **Options:** - A (incorrect): 小文字mustを必ず規範語として読む根拠は, 文書が明示しない限り成立しない. - B (correct): これが最も起きやすい問題. 同じ仕様を読んでも結論が分岐する. - C (incorrect): 文は意味を持つ. 問題は有効性ではなく, 規範性の明確さ. **Related:** セキュリティ要件は, テスト可能な条件として書き, 規範語の解釈を明示する. だから RFC 2119 と RFC 8174 は, 仕様を書く人だけでなく読む人にも効く RFC です.

Q2: 仕様でMUSTを "must" と書いても規範的に読ませたい. 最も良い手はどれ

Multiple Choice
**Explanation:** **Terms:** MUST, 規範語, BCP 14ボイラープレート, 大文字小文字. MUSTとmustを同じ意味で扱うなら, そのルールを文書で宣言する必要がある. **Correct (A):** BCP 14は, ボイラープレートと明示的な解釈で曖昧性を無くす方針. 大文字か小文字かだけで信号にしないのが安全. **Options:** - A (correct): 読者と実装者に, mustをMUSTとして読む根拠を与える. 仕様レビューもやりやすい. - B (incorrect): 小文字だけだと, 規範語なのか普通の英語なのかが読者依存になりやすい. - C (incorrect): 例は補助になるが, 適合要件が消えると相互運用性が壊れやすい. **Related:** 要件は "テストできる条件" まで落とすのが実装者に優しい.

Q3: 実装者の曖昧性を減らす実践はどれ (複数選択)

Multi-Select
**Explanation:** **Terms:** 曖昧性, BCP 14キーワード, MUST, SHOULD. RFC 8174の狙いは, キーワードの読み方を明示して, 要件を一意に読むこと. **Correct (A,C,D):** どれも読みのブレを減らし, 適合判定を可能にする. **Options:** - A (correct): MUST/SHOULD/MAYの意味の前提を固定できる. - B (incorrect): 何が要件で何が説明かが不明になり, 実装差が増える. - C (correct): MUSTがテスト可能なら, 実装とレビューが収束しやすい. - D (correct): SHOULDは例外を許す. 例外が曖昧だと, SHOULDが実質MAYになる. **Related:** レビューでは, "このMUSTはどう試験する" と "このSHOULDの例外は何" を確認する.

Q4: "Clients must validate certificates" とだけ書かれ, BCP 14の宣言が無い. 何が起きやすい

Multiple Choice
**Explanation:** **Terms:** must (小文字), 規範か記述か, BCP 14宣言. RFC 8174が問題にするのは, キーワードの扱いが読者依存になる点. **Correct (C):** mustをMUSTとして読む人と, 強い表現の英語として読む人が混ざると, 実装結果が分裂する. **Options:** - A (incorrect): 自動ではない. 文書が解釈ルールを宣言して初めて, mustをMUSTとして扱える. - B (incorrect): 文は残せる. ただし規範なのかを明確化すべき. - C (correct): 曖昧性が発生しやすく, 相互運用性や安全性に直撃する. **Related:** 証明書検証のような安全要件は, MUSTで明確にし, 例外を許すなら条件付きで書く.

Q5: 規範セクションでBCP 14らしい表現はどれ

Multiple Choice
**Explanation:** **Terms:** BCP 14, 規範セクション, MUST. RFC 8174とRFC 2119の文脈では, MUSTのようなキーワードで適合要件を表現する. **Correct (B):** "拒否" は観測可能でテスト可能. "しなければならない" はMUST相当の必須要件として読める. **Options:** - A (incorrect): 主観的でテスト不能. 要件にならない. - B (correct): 必須要件として読みやすく, 適合判定に落とせる. - C (incorrect): ぼかし表現が多く, 実装者が何を守れば良いか分からない. **Related:** 柔軟性が欲しいなら, SHOULDにして例外条件を明示する.

Q6: 規範語を1つ選ぶ. 相互運用性のために必須なら, 実装は___実装する必要がある

Short Text
**Explanation:** **Terms:** 相互運用性, 規範語, MUST. BCP 14でMUSTは, 例外を許さない必須要件を意味する. **Correct:** MUSTが適切. "必須" を宣言しているなら, SHOULDやMAYでは弱すぎる. **Why others are wrong:** SHOULDは正当な例外を許す. MAYは任意. "相互運用性のために必須" ならMUSTが筋. **Related:** MUSTを書くときは, 何が "相互運用性" を壊すのか, 具体例で示すと実装が揃う.