RFC 9651 Quiz (EN)

Q1: Can an implementation reinterpret this legacy field as a Structured Field?

Multiple Choice

X-Agent-Role was defined years ago with bespoke comma-separated syntax and does not reference RFC 9651 or RFC 8941. A new implementation wants to parse it as a Dictionary without changing the field specification.

A. No; the field must explicitly opt in through its definition, so changing the parser alone would redefine existing wire syntax. B. Yes, if all values seen in production happen to parse as a Dictionary under RFC 9651. C. Yes, because RFC 9651 automatically replaces the syntax of every HTTP field published before it. D. No, unless the field is first converted to a trailer, because Structured Fields cannot appear in headers.

**Explanation:** A: RFC 9651 Section 1 says the mechanism applies only to fields that explicitly opt in and is not intended to redefine existing fields. B: Accidental compatibility of observed values does not change the normative field definition or guarantee that all producers share the new interpretation. C: Section 1 expressly rejects automatic redefinition. RFC 9651 supplies reusable syntax only when a field specification selects it. D: Structured Headers are a primary use case. Header placement is not the missing condition; explicit specification is. Decision rule: Parser selection follows the field's defining specification; it cannot silently create a new protocol contract.

Q2: What is missing from this new field definition?

Multiple Choice

A draft says only: Agent-Limits is a Structured Field using RFC 9651 and may appear in requests. Implementers disagree about whether its value is an Item, List, or Dictionary and how invalid limits are handled.

A. Only an example serialization; the parser can infer all normative semantics from a representative field value. B. Only an IANA registration; registration automatically selects the top-level type and error behavior. C. Only a maximum byte size; RFC 9651 otherwise defines every application meaning for new fields. D. The definition must identify header or trailer use, top-level type, value semantics, constraints, and consequences when constraints fail.

**Explanation:** A: Examples help readers but cannot choose application semantics or failure consequences for every valid and invalid value. B: A registry entry identifies a field but does not supply the field-specific contract required by RFC 9651 Section 2. C: Operational size limits matter, but Section 2 also requires the type, meaning, constraints, and handling of violations. D: RFC 9651 Section 2 lists these definition duties. They are what let independent parsers produce the same abstract value and application outcome. Decision rule: Structured Fields standardizes common syntax; the field specification still owns its complete application contract.

Q3: How should the gateway handle this malformed field?

Multiple Choice

Agent-Policy is defined as a Dictionary Structured Header. It contains an unterminated String. One gateway inserts a closing quote and accepts admin=true, while another fails parsing and ignores the field.

A. Use the repaired value if the HTTP message signature is valid, because signatures authorize tolerant parsing. B. Fail parsing and ignore the entire field; accepting a guessed repair creates divergent and potentially unsafe interpretations. C. Drop only the malformed member and process admin=true, because Dictionary members are independent after a syntax error. D. Select either behavior through local policy, because RFC 9651 intentionally leaves parser error recovery unspecified.

**Explanation:** A: A signature does not define missing syntax, and changing signed input can invalidate the signature. Parser behavior still must follow the field definition. B: RFC 9651 Sections 1.1 and 2.2 make strict failure intentional: a parsing failure causes the entire field to be ignored. C: The parser has not produced a Dictionary from which a safe member can be selected. Partial recovery is not the defined error behavior. D: Section 1.2 requires parsing behavior indistinguishable from the algorithms. Local tolerance is not an allowed alternative outcome. Decision rule: Canonical interoperability comes from one strict parse result, not from different components guessing how a malformed sender intended to write the field.

Q4: May this receiver reject an unknown Dictionary member?

Multiple Choice

Agent-Capabilities is defined as a Dictionary Structured Header. Its specification defines keys run and stream but says nothing about unknown keys. A receiver rejects the entire request when it sees audit=?1.

A. Yes, because a security-sensitive field must reject every extension even when its specification is silent. B. Yes, because an unknown Dictionary key always makes Structured Field parsing fail. C. Not under the stated definition; recipients ignore unknown members by default, and a reject-on-unknown rule must be specified explicitly. D. No, and the receiver must execute the unknown capability because ignoring a member would lose forward compatibility.

**Explanation:** A: Security sensitivity can justify a stricter field definition, but it does not silently change the processing rule of an already specified field. B: A syntactically valid unknown member can parse successfully. Unknown application meaning is distinct from a Structured Fields syntax error. C: RFC 9651 Sections 2.3 and 3.2 say unknown Dictionary members are ignored unless the field specification specifically disallows them. D: Ignoring means not acting on the member. Forward compatibility does not authorize behavior whose semantics the receiver does not understand. Decision rule: Extensibility policy is part of the field definition: default-ignore preserves evolution, while reject-on-unknown must be an explicit protocol choice.

Q5: Can this extension add the Date type to the existing field?

Multiple Choice

Agent-State is defined as a Structured Header by normatively referencing RFC 8941. An extension adds an expires parameter using the RFC 9651 Date type because current gateways have upgraded parsers.

A. No; an extension remains limited to types in the RFC referenced by the field, so the field definition must be revised or versioned before using Date. B. Yes; upgrading a parser to RFC 9651 automatically upgrades every field definition it processes, even when the field cites RFC 8941. C. Yes; if expires is optional, RFC 8941 implementations will preserve the unknown Date value until upgraded application logic uses it. D. No; Date is prohibited in parameters for every Structured Field and can only be a top-level Item under RFC 9651.

**Explanation:** A: RFC 9651 Section 2.4 says extensions are limited to the types in the specific Structured Fields RFC referenced by the field. RFC 8941 recipients would treat Date syntax as invalid. B: A parser upgrade can make previously invalid syntax parse, which Section 2.4 identifies as a risk; it does not rewrite the field's contract. C: An RFC 8941 parser does not recognize the Date syntax and can fail the entire field before application logic sees an optional parameter. D: RFC 9651 permits Date as a bare item, including a parameter value when a field definition based on RFC 9651 allows it. Decision rule: Syntax evolution requires an explicit field-definition transition that accounts for old recipients, not deployment-specific parser capability.

Q6: Which profile rule makes this signed A2A field interoperable?

Multiple Choice

An agent sends repeated Agent-Context header lines through a combining proxy. The backend parses the result, reconstructs a preferred serialization, verifies a message signature, and authorizes from role and scope members.

A. Accept any value that the backend can serialize, because a valid Structured Fields abstract value also proves the sender's signature and authorization intent. B. Require the proxy to preserve original whitespace exactly, because RFC 9651 defines only one permitted serialization for every abstract value. C. Verify the signature after dropping unknown members, because extensibility rules make omitted members irrelevant to every signature scheme. D. Define the field's referenced RFC, placement, top-level type, constraints, and error handling; separately define signature coverage and the authorization meaning of parsed members.

**Explanation:** A: RFC 9651 parsing establishes an abstract value, not signer identity or permission. Authorization cannot be inferred from syntactic success. B: Section 1.2 allows serializers to vary when the result parses correctly. HTTP also permits combining appropriate field lines, so exact whitespace is not the general contract. C: Ignoring an unknown member for field semantics does not mean it can be removed from a cryptographic input. Signature processing follows its own covered-component rules. D: RFC 9651 Sections 2, 2.4, and 4 define the syntax contract and version boundary. Signature and authorization layers must specify how they consume that result. Decision rule: A robust composition names the bytes or abstract value each layer consumes and never treats successful parsing as cryptographic or authorization evidence.

Structured Field Values for HTTP

References (URLs)

Q1: Can an implementation reinterpret this legacy field as a Structured Field?

Q2: What is missing from this new field definition?

Q3: How should the gateway handle this malformed field?

Q4: May this receiver reject an unknown Dictionary member?

Q5: Can this extension add the Date type to the existing field?

Q6: Which profile rule makes this signed A2A field interoperable?