Q1: RFC 8174のclarificationに含まれる記述はどれ？ 3つ選べ。
複数選択RFC 8174 Section 2はA、C、Dを明記します。Bは誤りです。keywordは明確さと一貫性のために利用できますが、使用は必須ではありません。この区別により、case-insensitiveなkeyword解析と、keywordのない文は参考文だという誤解の両方を避けられます。
一次資料
大文字小文字を区別するBCP 14規則を扱います。規範文がすべてkeyword文であるという誤解は避けます。RFC 2119と明記した箇所以外、Section番号はRFC 8174を指します。
Q2: reviewerはこのlowercase shouldをどう分類すべきか？
単一選択仕様はRFC 8174の推奨boilerplateを含む。後の文に"Clients should retry after a timeout."とある。
A: RFC 8174 Section 2ではcaseが意味を持ちます。B: このboilerplateの下で特別な意味を持つのはALL CAPSのSHOULDだけで、lowercase shouldは通常英語です。C: case変更で別keywordへ変わりません。D: lowercase proseはvalidで、文脈と表現により規範的意図を伝えることもあります。
Q3: reviewerのreject理由はRFC 8174上妥当か？
単一選択protocolのnormative sectionに"Implementations are required to reject frames with an invalid length."とある。reviewerはALL CAPS keywordがないことだけを理由にnon-normativeと判定した。
AとBは、keywordを使わないnormative textも多いとするRFC 8174 Section 2に反します。Cも誤りで、lowercase requiredは特別なBCP 14意味ではなく通常英語です。Dはkeyword markerと文のnormative forceを分離します。文脈と表現自体が要件を成立させます。
Q4: 文頭のMustはBCP 14の特別な意味を持つか？
単一選択文書はRFC 8174 boilerplateを採用している。checklist itemは"Must the client retain the nonce?"で始まる。
A: Section 2は特別な意味をALL CAPSの場合だけに与え、title caseは通常英語です。BとCはRFC 8174にないactivation ruleを作っています。Dは過剰です。ここでの判定理由は正確なcapitalizationであり、文法形式一般の禁止ではありません。
Q5: publication formatterはこのcase変更をしてよいか？
単一選択source specificationはRFC 8174 boilerplateを採用し、"The verifier MUST reject an invalid proof."とする。style formatterが公開HTMLでMUSTをMustへ変える。
AとBはRFC 8174 Section 2のALL CAPS条件を無視します。Cが正解です。このboilerplateでは公開されたMustは通常英語にしかならず、明示的keyword signalが変わります。Dは広すぎます。語とcaseを保つ変換までRFC 8174が禁止しているわけではありません。
Q6: editorは公開前に何を変えるべきか？
単一選択draftはRFC 8174を引用しつつ、"must, should, and may have the BCP 14 meanings regardless of capitalization."と宣言する。toolingもcase-insensitiveにkeywordをparseする。
AはRFC 8174 Section 2を誤って説明しています。特別な意味はALL CAPS表記に限られます。Bは標準規則と意図的に異なるlocal ruleを分離します。Cは不要で、lowercase wordは通常英語として使えます。Dはauthorityを逆転させています。toolingがdocumentの宣言を実装すべきです。
Q7: linterはすべての該当語を自動uppercaseすべきか？
単一選択linterがexplanatory paragraph内のlowercase must、should、mayを検出し、すべてuppercase keywordへ変換しようとする。
AとBはRFC 8174 Section 2に反します。lowercase表記は通常英語であり、keyword使用はoptionalです。Cは位置による禁止を作っています。Dが正解です。uppercase化はsemantic signalを変えるため、linterは候補を示せてもauthor reviewなしにrequirementを作るべきではありません。
Q8: reviewerはこのboilerplate更新をどう説明すべきか？
単一選択新draftはALL CAPSのNOT RECOMMENDEDを使うが、RFC 2119だけを引用し、そのphraseを列挙しない古い宣言を残している。editorはRFC 2119と8174を引用するRFC 8174 boilerplateを提案した。
A: RFC 8174 Section 2は、guidelineに従うauthorへ、NOT RECOMMENDEDと両RFCを含む更新済み文言を取り込むよう勧めます。これはdocument authoring guidanceで、wire protocol要件ではありません。Bはeditorial clarityとpeer behaviorを混同します。Cはrequirement levelを変えます。DはALL CAPS限定条件に反します。
Q9: normative signalを保つpublication policyはどれ？
単一選択英語仕様はRFC 8174を採用する。日本語訳はMUSTを通常の日本語proseへ置換し、conformance extractorには同じkeyword markupが残る前提で翻訳版を処理させる。
AとBはRFC 8174 Section 2が定義しないcross-language ruleを作ります。Cはnormative sourceとmachine markerを明示します。翻訳がproseの意味を伝えても、削除されたALL CAPS英語keywordをextractorは推測できません。Dはcase-sensitive規則を無視します。
Q10: gatewayのcase-insensitive requirement mergerを信頼できるか？
単一選択A2A profileは、RFC 8174を採用してMUSTを使うSpec Aと、BCP 14宣言なしでlowercase mustを使うSpec Bをimportする。gatewayは両textを統合し、case-insensitiveに一致する語をすべてBCP 14 MUSTとmarkする。
A: RFC 8174 Section 2は、import側が別文書のcapitalization conventionを遡って変えることを認めません。B: Spec Aの明示的keyword semanticsを保ち、Spec Bの通常英語の要件は、その文書自身のwording、status、contextから評価します。Cはtoolingにsemanticsを作らせています。Dは逆方向の誤りで、BCP 14 keywordなしでもnormative textは存在できます。