ToppyMicroServices

RFC 9651 Quiz (JA)

Structured Field Values for HTTP

ENJA
0 / 0

参照（URL）

Q1: implementationだけでlegacy fieldをStructured Fieldとして再解釈できるか

単一選択

X-Agent-Roleは独自comma-separated syntaxで以前に定義され,RFC 9651もRFC 8941も参照しません.新implementationはfield仕様を変えずDictionaryとしてparseしたいとします.

**解説:** A: RFC 9651 Section 1は,明示的にopt inしたfieldだけへmechanismを適用し,既存fieldの再定義を目的にしないとします. B: 観測valueの偶然の互換性はnormative field definitionを変えず,全producerが新解釈を共有する保証にもなりません. C: Section 1は自動再定義を明確に否定します.RFC 9651はfield仕様が選択した場合に共通syntaxを提供します. D: Structured Headerは主要use caseです.不足する条件はheader placementではなく,明示的な仕様です. 判断軸: parser選択はfieldを定義した仕様に従います.implementationだけで新しいprotocol contractを暗黙に作れません.

Q2: この新field definitionに不足するものは何か

単一選択

draftにはAgent-Limits is a Structured Field using RFC 9651 and may appear in requestsとしかありません.Item,List,Dictionaryのどれか,invalid limitをどう扱うかでimplementationが不一致です.

**解説:** A: exampleは理解を助けますが,全validまたはinvalid valueのapplication semanticsとfailure consequenceを選べません. B: registry entryはfieldを識別しますが,RFC 9651 Section 2が求めるfield-specific contractを提供しません. C: operational size limitも重要ですが,Section 2はtype,meaning,constraint,violation handlingも要求します. D: RFC 9651 Section 2がこれらのdefinition dutyを列挙します.独立parserが同じabstract valueとapplication outcomeを得るために必要です. 判断軸: Structured Fieldsは共通syntaxを標準化しますが,field仕様がcomplete application contractを所有します.

Q3: gatewayはこのmalformed fieldをどう扱うべきか

単一選択

Agent-PolicyはDictionary Structured Headerとして定義されています.unterminated Stringがあり,一方のgatewayはclosing quoteを追加してadmin=trueを受理し,他方はparse failureでfieldを無視します.

**解説:** A: signatureは不足syntaxを定義せず,signed inputの変更はsignatureをinvalidにもできます.parser behaviorはfield definitionに従います. B: RFC 9651 Sections 1.1と2.2はstrict failureを意図的に定め,parsing failureならfield全体を無視します. C: parserは安全なmemberを選べるDictionaryを生成していません.partial recoveryは定義されたerror behaviorではありません. D: Section 1.2はalgorithm実行と区別できないparsing behaviorを要求します.local toleranceは許された別outcomeではありません. 判断軸: canonical interoperabilityは,malformed senderの意図を各componentが推測することではなく,1個のstrict parse resultから得ます.

Q4: receiverはunknown Dictionary memberを理由にrejectできるか

単一選択

Agent-CapabilitiesはDictionary Structured Headerです.仕様はrunとstream keyを定義しますが,unknown keyには触れません.receiverはaudit=?1を見るとrequest全体をrejectします.

**解説:** A: security sensitivityはよりstrictなfield definitionを正当化し得ますが,既存仕様のprocessing ruleを暗黙に変更しません. B: syntactically validなunknown memberはparseできます.unknown application meaningとStructured Fields syntax errorは別です. C: RFC 9651 Sections 2.3と3.2は,field specificationが明示的にdisallowしない限りunknown Dictionary memberをignoreするとします. D: ignoreはmemberに基づいて動作しないことです.forward compatibilityは理解しないsemanticsの実行を認可しません. 判断軸: extensibility policyはfield definitionの一部です.default-ignoreはevolutionを保ち,reject-on-unknownは明示的protocol choiceにします.

Q5: このextensionは既存fieldへDate typeを追加できるか

単一選択

Agent-StateはRFC 8941をnormative referenceとするStructured Headerです.extensionは現行gatewayがparser upgrade済みとして,RFC 9651 Date typeのexpires parameterを追加します.

**解説:** A: RFC 9651 Section 2.4はextensionもfieldが参照する特定Structured Fields RFCのtypeへ制限します.RFC 8941 recipientはDate syntaxをinvalidとして扱います. B: parser upgradeは以前invalidだったsyntaxをparse可能にし得ますが,Section 2.4はそれをriskとして指摘します.field contractの書換えではありません. C: RFC 8941 parserはDate syntaxを認識せず,application logicがoptional parameterを見る前にfield全体を失敗させ得ます. D: RFC 9651はDateをbare itemとして許し,RFC 9651に基づくfield definitionが許せばparameter valueにもできます. 判断軸: syntax evolutionにはold recipientを考慮した明示的field-definition transitionが必要で,deployment-specific parser capabilityだけでは足りません.

Q6: このsigned A2A fieldをinteroperableにするprofile ruleはどれか

単一選択

agentはcombining proxyを通して複数Agent-Context header lineを送ります.backendはparse後にpreferred serializationを再構築し,message signatureを検証し,roleとscope memberからauthorizeします.

**解説:** A: RFC 9651 parsingが立証するのはabstract valueであり,signer identityやpermissionではありません.syntactic successからauthorizationを推論できません. B: Section 1.2は正しくparseできる範囲でserializerの違いを許します.HTTPは適切なfield lineのcombineも許し,exact whitespaceは一般contractではありません. C: field semanticsでunknown memberをignoreすることは,cryptographic inputから除けるという意味ではありません.signature processingは固有のcovered-component ruleに従います. D: RFC 9651 Sections 2,2.4,4がsyntax contractとversion boundaryを定めます.signatureとauthorization layerはその結果の利用方法を指定する必要があります. 判断軸: robust compositionは各layerが消費するbyteまたはabstract valueを特定し,successful parsingをcryptographic evidenceやauthorization evidenceとして扱いません.