ToppyMicroServices

RFC 2119 規範語クイズ

MUST/SHOULD/MAY（BCP 14）をブレなく使い分ける

🇺🇸 🇯🇵
0 / 0

参照（URL）

Q1: 仕様を書いています.「適合する実装なら必ず証明書検証を行う」なら,どの文がいちばん筋が良い?

Multiple Choice
RFC 2119 を読むときは, まずその文が「適合に必須」なのか, 「原則推奨」なのか, 「任意」なのかを見分けます. その強さの段差が MUST, SHOULD, MAY の違いです.
MUST 適合に必須 守らないと不適合 例外が増える SHOULD 原則そうする 例外には理由が必要 裁量が増える MAY 実装者の任意 適合条件ではない
**解説:** RFC 2119 Section 1はMUSTを仕様の絶対要件に使います.SHOULDはSection 3で正当化可能な例外を許し,MAYはSection 5で任意の動作を示します. - `MUST`: 仕様適合のために必須です. 守らない実装は不適合になります. - `SHOULD`: 原則は守るが, 例外はあり得ます. ただし例外には理由が必要です. - `MAY`: 任意です. 実装しても, しなくても適合性は崩れません. まず, その文が「適合条件」なのか, 「設計上の推奨」なのか, 「任意機能」なのかを切り分けます. 証明書検証のように, 実装が必ず行わないと安全性も相互運用性も崩れる項目は `MUST` で読むのが自然です. A: `MUST` は全ての適合実装に検証を義務付けるため, 問題文の前提に合います. B: `SHOULD` は慎重に検討した例外を認めるため, 無条件の必須要件にはなりません. C: `MAY` は検証を任意にするため, 適合条件を定められません.

Q2: HTTP/2対応を強く推したいが,制約のある環境は例外として許容したい.いちばん合う規範語は?

Multiple Choice
**解説:** RFC 2119 Section 3は,例外があり得る一方,逸脱前に影響を理解して慎重に判断すべき要件へSHOULDを使います. `SHOULD` は「基本は守る.ただし例外があり得る（理由が必要）」です. 仕様には, 何が例外を正当化するかも記述すると一貫して判断できます. A: `MUST` は例外を認めず, 制約環境を不適合にします. B: `MAY` は許可を表すだけで, 強い推奨にはなりません. C: `SHOULD` は原則としての期待を示しながら, 慎重に判断した例外を認めます.

Q3: BCP 14の曖昧さを避ける参照文として,いちばん良いのはどれ?

Multiple Choice
**解説:** RFC 8174 Section 2は標準BCP 14 boilerplateを更新し,定義済みの意味をALL CAPSの規範語に限定します. - **BCP 14**: RFC 2119の規範語の解釈方針.RFC 8174で更新されています. - **ALL CAPS**: RFC 8174が「大文字のときに規範的意味」と明確化. A: RFC 8174では, 小文字の語が自動的にBCP 14の意味を持つとは扱いません. B: 大文字は適切ですが, RFC 8174による更新とBCP 14への参照が抜けています. C: BCP 14と両RFCを挙げ, 解釈と大文字表記の規則を明示しています.

Q4: 「原則必須に近いが,例外もあり得る」を書くとき,いちばん誤解が少ない書き方は?

Multiple Choice
**解説:** RFC 2119 Section 3のSHOULDが例外を許し,Section 1のMUSTが例外理由の文書化を別の必須要件にできます. - `SHOULD`: 原則そうする（例外は正当化が必要）. - `MUST`: 必須（ここでは「例外時の理由提示」を必須にしている）. - `MAY`: 任意. A: 「できない場合」の条件が未定義で, 適合性を客観的に判定できません. B: `SHOULD` で通常時の期待を示し, 逸脱理由の文書化を別の `MUST` で検証可能にしています. C: `MAY` はXを任意にするため, 「推奨」という非規範的な語を添えても期待の強さは戻りません.

Q5: 宣言した適合境界を定義できていないdraft文はどれか?

Multi-Select

Agent Card profileは, 受理する全Cardを認証し, 独立実装同士が相互運用できると宣言しています. draftには次の文があります.

**解説:** keywordだけでは, 未定義の条件やprofileの保証との衝突は直りません. RFC 2119 Section 6は相互運用性の確保や危害の抑止に必要な動作へ規範語を慎重に使うよう述べ, Section 7はsecurity上の影響を説明するよう求めます. A: 選択. 「実行可能なら」の判定を実装ごとに委ねるため, 適合性を一貫して評価できません. B: 選択. profileが保証を狭めるか, 正確な例外とsecurity上の影響を定義しない限り, この許可は全Cardを認証するという宣言と衝突します. C: 選択. 「速やかに」と回数上限の欠如は観測可能な動作を定義せず, loadを増幅する可能性もあります. D: 非選択. RFC 2119 Section 5に沿い, optional機能がなくても, その機能を除いて相互運用できる契約です. E: 非選択. 非規範と明示した例は適合要件を変更しません.

Q6: 独立実装へ明確なsecurity境界と適合境界を与える改訂はどれか?

Multiple Choice

draftには「clientはserver certificateを検証すべき」とあります. ある実装はWebPKIのpathとnameを検証し, 別の実装は有効期限だけを確認し, 3つ目は事前配布したcertificate pinを使います. 意図した設計はWebPKI検証または明示的に設定したpinning modeを許可し, どの検証failureでも接続を中止するものです.

**解説:** RFC 2119 Sections 1–5が与えるのは要求levelであり, 欠けているcertificate検証algorithmやmode選択ではありません. RFC 8174 Section 2も大文字表記を明確にしますが, 未定義の動詞をtest可能な要件には変えません. A: 「安全に」は曖昧さを残し, `SHOULD`は意図した設計にない例外経路を作ります. B: `MUST`は強さを示しても, 「検証」の非互換または不安全な解釈を防ぎません. C: 正解. 許可する選択肢, 選んだ各mode内の必須動作, 共通のfailure結果を定義しています. D: 文書化だけでは, 全接続が2つの検証modeの一方を使うという要件を満たしません.

Q7: このoptional extensionの相互運用契約を完成させる追加はどれか?

Multiple Choice

A2A profileには「payload compressionはOPTIONAL」とあります. compressionを実装するsenderは常に圧縮し, extensionを持たない適合receiverはrequestをdecodeできません.

**解説:** RFC 2119 Section 5は, optional itemを持つ実装と持たない実装が, optionの機能自体を除いて相互運用できるよう準備することを求めます. A: 実質的にcompressionを必須にするため, 宣言したextensionの位置付けと衝突します. B: 正解. 交渉または曖昧でないsupport通知により, 両peerが共通のbase表現へfallbackできます. C: request全体を処理できない状態はcompressionの利点を失うだけではなく, base operationの相互運用を壊します. D: 小文字化はBCP 14上の解釈を変えても, wire上の非互換を直しません.

Q8: 宣言したpolicyを弱めず, logging境界をtest可能にする要件はどれか?

Multiple Choice

threat analysisは, logからraw access tokenまたはclient secretを取得されることをattackとして扱います. request IDは記録できますが, secret値はapplication, proxy, diagnosticのどのlog sinkにも到達させません. 現在のdraftは「実装はsensitive dataのloggingを避けるSHOULD」としています.

**解説:** RFC 2119 Section 2は絶対禁止を表現でき, Sections 6と7は危害につながる動作へ正確な規範語を使い, security上の影響を説明する考え方を示します. logging禁止policy自体はRFC 2119ではなく, このthreat modelから来ます. A: `SHOULD`の例外は前提と衝突し, threat analysisが保護する値そのものを露出します. B: 正解. data, 対象sink, enforcement point, 許可する非secret出力を特定しています. C: 未定義のsinkからも同じcredentialを取得できるため, 宣言した境界を満たしません. D: 復号能力を得た者にはcredentialを露出し, 「sinkへ到達させない」という要件にも反します.

Q9: 定義済みのstale metadata例外を最も正確に表す文はどれか?

Multiple Choice

clientは通常, staleなAgent Cardを拒否します. 定義済みのdisaster-recovery modeでは, operatorがmodeを有効にし, Cardの署名が引き続き有効な場合に限り, 10分以内のstale Cardを受理できます. それ以外のstale利用は許可しません.

**解説:** RFC 2119 Section 4は慎重に検討した例外があり得る場合の`SHOULD NOT`を定義します. しかし前提は完全な例外条件をすでに定義しているため, 条件付きの規範要件の方が境界を正確に伝えます. A: 定義済みのrecovery mode以外にも未指定の例外を作ります. B: 正解. その他のstale利用を禁止し, 許可をmode, age, operator操作, 有効な署名という条件へ限定します. C: 必須のrecovery動作と衝突します. D: stale受理を一般的な任意動作にし, 署名検証も弱めるため, 前提より広い許可です.

Q10: このaudience alias extensionについて, BCP 14から導けるreview結論はどれか?

Multi-Select

base profileは, verifierがtokenのaudienceをrequested resourceと照合MUSTとしています. extensionはaudience aliasを受理MAYとしますが, aliasのsyntaxも信頼できるsourceも定義せず, aliasを実装しないpeerの動作にも触れていません. それでもprofileは全適合実装間の相互運用性を宣言しています.

**解説:** RFC 2119 Section 5はitemをoptionalにしながらも, その機能自体を除いて, optionを持つ実装と持たない実装の相互運用を求めます. Sections 6と7は選択が相互運用性やsecurityへ影響する場合の注意を求めます. RFC 8174が特別な意味を与えるのはBCP 14の規約下にある大文字表記です. A: 選択. 要求levelは, 欠けているalias data modelとtrust ruleの代わりにはなりません. B: 選択. 一方のpeerがoptional機能を持たない場合の動作をprofileが定義する必要があります. C: 選択. 無条件に宣言した相互運用性に必要な動作を, 同時に実装者の選択へ委ねることはできません. D: 非選択. RFC 2119は不要な必須要件を戒めます. 適切なlevelは実際の範囲と影響で決まります. E: 非選択. RFC 8174では小文字の語は通常の英語として解釈されます.