RFC 2119 規範語クイズ

**解説:** **定義（問題語）:** - `MUST`: 仕様適合のために必須です. 守らない実装は不適合になります. - `SHOULD`: 原則は守るが, 例外はあり得ます. ただし例外には理由が必要です. - `MAY`: 任意です. 実装しても, しなくても適合性は崩れません. **RFCを読むときの見方:** まず, その文が「適合条件」なのか, 「設計上の推奨」なのか, 「任意機能」なのかを切り分けます. 証明書検証のように, 実装が必ず行わないと安全性も相互運用性も崩れる項目は `MUST` で読むのが自然です. **Bが正しい理由:** 問題文は「適合する実装なら必ず証明書検証を行う」と言っています. これは例外なしの必須条件なので, `MUST` が最も筋が良い書き方です. RFC の文をレビューするときも, 「この文はテストで yes/no 判定できるか」を見ると `MUST` の妥当性を判断しやすくなります. **A/Cが違う理由:** - A（`SHOULD`）: 例外の余地が残るため, 証明書検証を省いた実装でも「事情があった」と言えてしまいます. - C（`MAY`）: 任意機能になってしまい, セキュリティ要件として弱すぎます. **関連トピック例:** AI に仕様文を書かせると, 強い気持ちで `SHOULD` を提案してくることがあります. そのときは, その文が「適合条件」なのか「推奨」なのかを人間が明示的に戻してあげるのが大事です.

**解説:** **定義（問題語）:** `SHOULD` は「基本は守る.ただし例外があり得る（理由が必要）」です. **Bが正しい理由:** 「推奨＋例外あり」という意図を,そのまま表現できます. **A/Cが違う理由:** - A（`MUST`）: 例外を許容しない.制約環境が一発で不適合になる. - C（`MAY`）: 弱すぎて,“やらなくてもOK”に見えてしまう. **関連トピック例:** `SHOULD` を採用したら,「どんなケースが例外か」を短く書いておくと揉めません.

**解説:** **定義（用語）:** - **BCP 14**: RFC 2119の規範語の解釈方針.RFC 8174で更新されています. - **ALL CAPS**: RFC 8174が「大文字のときに規範的意味」と明確化. **Cが正しい理由:** BCP 14を明示し,RFC 2119とRFC 8174の両方を含めるので,読み手の解釈がブレません. **A/Bが微妙な理由:** - A: 小文字で書いてしまうと,RFC 8174が解決したはずの曖昧さが戻る. - B: 大文字で一歩前進だが,RFC 8174（BCP 14更新）に触れていない. **関連トピック例:** 仕様lintやレビュー観点として,この参照文があるかはよくチェックされます.

**解説:** **定義（問題語）:** - `SHOULD`: 原則そうする（例外は正当化が必要）. - `MUST`: 必須（ここでは「例外時の理由提示」を必須にしている）. - `MAY`: 任意. **Bが正しい理由:** 推奨＋例外の“型”に合わせつつ,例外を取ったときに説明責任を持たせられます（レビューとAI支援に強い）. **A/Cが弱い理由:** - A: 「できない場合」が曖昧で,テストもレビューも破綻しやすい. - C: `MAY` は任意なので,推奨が“気分”になってしまう. **関連トピック例:** AIに仕様文を直させるときも,この“型”を指示すると品質が上がります.

**解説:** **定義（観点）:** - **規範（normative）**: 適合性に直結する部分. - **テスト可能**: 客観的にOK/NGを決められること. **A〜Eが赤信号な理由:** - A: 実装者が「無理でした」で逃げられ,合意形成が崩れる. - B: 大文字/小文字の曖昧さはRFC 8174がまさに潰したポイント. - C: セキュリティを任意にすると,現場で“未実装”が正当化される. - D: 未定義語があると `MUST` が実質的に測れない. - E: 実装が分岐し,AIレビューでも人間レビューでも収拾がつかない. **Fが赤信号ではない理由:** 非規範と明記した例は理解を助けるだけで,適合性を変えません.

**解説:** **定義（ポイント）:** - **テスト可能**: 相互運用/適合テストで判定できる. - **用語定義**: “verify/validate/certificate” の解釈ブレを潰す. - **例外**: `SHOULD` を使うなら,逸脱できる条件を言語化する. **Bが正しい理由:** AIに「枠（conformance・語彙・例外）」を渡しているので,仕様として通る文章になりやすい. **A/Cが弱い理由:** - A: “強い”は主観で,`MUST` にすべきか単なる言い換えか判断できない. - C: 大文字化だけでは,動作定義もテスト性も上がらない.

**解説:** **定義:** - `MUST`: 全ての適合実装に必須. - `MAY`: 任意（実装の自由）. - `MUST NOT`: 禁止. **Bが正しい理由:** 必須は `MUST`,任意は `MAY` が素直です. **A/Cが違う理由:** - A: 基本が必須でなくなり,拡張が必須になる（意図が逆）. - C: 基本が任意になり,拡張が禁止になる（別の意図）.

**解説:** **定義（問題語）:** `MUST NOT` は「絶対禁止（守らないと不適合）」です. **Aが正しい理由:** 「出してはいけない＝禁止」なので `MUST NOT` が適切です. **B/Cが違う理由:** - B（`SHOULD NOT`）: 原則避けるだが,例外を許してしまう. - C（`MAY`）: むしろ“許可”している. **関連トピック例:** 「秘密情報」の定義（トークン/鍵/パスワード等）まで書くとテストしやすくなります.

**解説:** **定義（問題語）:** - `MUST NOT`: 絶対禁止. - `SHOULD NOT`: 非推奨（例外があり得る）. - `MAY`: 任意/許可. **Bが正しい理由:** 「基本ダメだが例外がある」なら `SHOULD NOT` がぴったりです. **A/Cが違う理由:** - A: 例外ゼロなら `MUST NOT`. - C: 任意は `MAY` の領域.

**解説:** **定義（良い仕様の条件）:** - **誤解されない**: 読み手が同じ解釈になる. - **テストできる**: 適合判定ができる. - **区別できる**: 必須・推奨・任意が混ざらない. **A〜Dが正しい理由:** ケース（大文字と参照）(A),適合テスト性(B),例外の規律(C),任意による穴(D) を押さえられます. **Eがダメな理由:** `MUST` の多用は品質ではありません.不要な制約で実装が硬直し,相互運用性も落ちやすいです.