RFC 8259 Quiz

Q1: Which handling correctly separates RFC 8259 Sections 2 and 3 from an application schema?

Multiple Choice

An A2A endpoint contract requires a top-level object containing taskId and action. The received body is the JSON number 42, which a general-purpose JSON parser parses successfully.

A. Classify it as a violation of the RFC 8259 JSON grammar because it is not an object B. Accept it as JSON text, then reject it for failing the A2A message schema C. Process 42 as a valid A2A request because the parser accepted it D. Convert it implicitly to {"value":42} for interoperability

B is correct. RFC 8259 Sections 2 and 3 permit any serialized JSON value as a JSON text, not only an object or array, so 42 is syntactically valid JSON. An A2A endpoint can nevertheless require a top-level object and named members in its application contract. The failure should be reported as an invalid application message rather than mislabeled as a JSON parse failure. Parser success does not establish message validity, and RFC 8259 defines no implicit object conversion.

Q2: Can RFC 8259 alone make a missing member equivalent to `null`?

Multiple Choice

In a grant-update API, client A omits delegate, while client B sends "delegate":null. The authorization service treats omission as “keep the current value” and null as “revoke delegation.”

A. Yes. RFC 8259 defines an absent member as an abbreviated null B. Yes. RFC 8259 defines null as an empty string, so both revoke delegation C. No. Both can be represented in JSON, but their distinction belongs in the application contract D. Yes, if the parser automatically inserts null for every missing member

C is correct. RFC 8259 Sections 3 and 4 define the null literal and object-member syntax, but they do not equate an absent member with a member whose value is null. A contract may validly distinguish “no update” from “explicitly revoke,” but its schema, validation, and authorization components must all apply the same meaning. Automatic parser insertion is not an RFC 8259 behavior and can hide the contract while creating inconsistent interpretations across components.

Q3: Which correction follows from RFC 8259 Section 4?

Multiple Choice

A gateway and replay worker treat the “first member name” of an object as its operation. A client sends {"cancel":true,"taskId":"t1"}, but a logger reserializes members alphabetically and another library does not expose member order to its caller.

A. Signing the original bytes makes every JSON library expose the same first member B. Requiring UTF-8 without a BOM makes object-member order part of the contract C. Use an explicit operation member, and use an array if sequence itself is data D. Sort members everywhere and select the first name after sorting as the operation

C is correct. RFC 8259 Sections 1 and 4 describe an object as an unordered collection and note that libraries differ on whether they expose member ordering to calling software. A signature can protect a particular byte sequence, but it does not require every parser API to expose the same order. The operation should be an explicit member, while data whose order is meaningful belongs in an array. A project-wide sorting rule would be an additional contract not supplied by RFC 8259.

Q4: Which handling satisfies both RFC 8259 Section 5 and the task-batch schema?

Multiple Choice

A batch endpoint requires an array of task objects. Its input is [{"id":"t1"},null,"retry"], which the JSON parser successfully parses as an array.

A. Process every element as a task because the array is valid JSON B. Accept the JSON syntax, validate each element against the batch schema, and reject invalid input C. Reject it in the JSON parser because RFC 8259 forbids mixed-type arrays D. Convert null and the string automatically into empty task objects

B is correct. RFC 8259 Section 5 imposes no same-type requirement on array elements, so the body is syntactically valid JSON. An application profile can still define the narrower schema “array of task objects.” Each element must be validated before use, and the API contract can decide whether failure rejects the whole batch or produces per-element errors. Syntactic acceptance does not imply business acceptance, and RFC 8259 defines no such automatic coercion.

Q5: Which correction follows from RFC 8259 Sections 6, 9, and 10?

Multiple Choice

A telemetry client generates {"latency":NaN}. A permissive gateway parser accepts it and forwards it with a signature result, but a strict backend parser rejects it. The need to represent a non-finite value has not been defined.

A. Require the backend to accept bare NaN because the gateway accepted and signed it B. Replace NaN with Infinity and forward it as a JSON number C. Enable permissive parsing everywhere and treat the wire extension as an implicit standard D. Reject bare NaN at generation and define another representation in the schema if needed

D is correct. RFC 8259 Section 6 excludes NaN and Infinity from the number grammar. Section 9 permits a parser to accept non-JSON extensions, but Section 10 requires generator output to conform strictly to the JSON grammar. One permissive parser's acceptance, or a signature over the bytes, therefore does not make bare NaN interoperable JSON. If non-finite values are needed, the application schema must define the representation and meaning—for example, a string, status member, null, or omission.

Q6: Which representation avoids cross-runtime identifier rounding?

Multiple Choice

An Agent Card uses the integer identifier 9007199254740993. A binary64-based gateway and an arbitrary-precision backend must preserve the identifier exactly across parse and reserialization.

A. A JSON number with exponent notation so parsers infer arbitrary-precision integer semantics B. A JSON number followed by a type comment declaring exact integer handling C. A JSON string with application-level identifier rules

A: Exponent notation does not give a parser arbitrary-precision semantics. B: JSON has no comment syntax, and a comment would not change numeric precision. C: RFC 8259 Section 6 identifies the interoperable exact-integer range for binary64; this value is outside it. A string avoids numeric rounding, while the application profile defines its identifier syntax and equality rules.

Q7: Which receiving profile follows from RFC 8259 Sections 8.1 and 11?

Multiple Choice

For an inter-organizational A2A request, the sender generates UTF-16 JSON with a BOM, sends Content-Type: application/json; charset=utf-16, and signs the transmitted bytes. The gateway transcodes the body to UTF-8 and then verifies the sender's signature against the transformed bytes.

A. Require UTF-8 without a generated BOM; define the signature input as received bytes or a specified canonical form B. Treat charset=utf-16 as the RFC 8259 encoding signal and verify only after transcoding C. Treat original and transcoded bytes as the same signature input because every receiver must ignore a BOM D. Accept every decodable Unicode encoding as an interoperable application/json representation

A is correct. RFC 8259 Section 8.1 requires UTF-8 for JSON exchanged outside a closed ecosystem and prohibits generators from adding a BOM. A parser may ignore an incoming BOM; it is not required to do so. The Section 11 registration for application/json defines no charset parameter. RFC 8259 also defines no signature canonicalization, so transformed bytes cannot silently substitute for the bytes the sender signed. A profile must first fix the wire encoding, then state whether the signature covers exact received bytes or a canonical representation defined by another specification.

Q8: Which design prevents this name-filter bypass under RFC 8259 Section 8.3?

Multiple Choice

A gateway filter rejects a member only when its raw JSON token exactly matches "admin_role". The application parser decodes "\u0061dmin_role" and passes the same admin_role member to authorization logic.

A. Let the filter and application treat them as different names because their raw tokens differ B. Sort object members alphabetically to eliminate differences in escape spelling C. Ban every JSON escape in security fields and compare only the raw source text D. Filter on the parsed name and pass the same validated representation to security decisions

D is correct. RFC 8259 Section 8.3 explains that comparing strings without converting escapes can make two encodings of the same string value appear different. A filter that sees raw spelling while authorization sees the decoded name splits the security boundary. Parse once, compare the decoded Unicode code-unit sequence, and pass the same validated representation to downstream decisions. RFC 8259 does not define a representation-independent signature format; if that property is needed, a separate canonicalization specification is required.

Q9: Which input-profile correction applies RFC 8259 Section 8.2?

Multiple Choice

An Agent Card display name contains the surrogate pair \uD834\uDD1E for a G clef. UTF-16 middleware truncates it after one code unit and writes the lone surrogate \uD834 back into JSON. The gateway, logger, and policy service then disagree about the string's length and value.

A. Accept it because ABNF expressibility means every component sees the same Unicode character B. Rely on native handling because every receiver is required to replace it with U+FFFD C. Validate Unicode scalars before security processing and reject lone surrogates D. Depend on a signature over the original JSON bytes to equalize decoded lengths and values

C is correct. RFC 8259 Section 8.2 explains that the JSON ABNF can admit bit sequences, such as a lone surrogate, that cannot encode a Unicode character; observed receiver behavior ranges from different lengths and values to fatal runtime exceptions. The RFC does not require a common replacement procedure. An application profile can require interoperable Unicode scalar sequences and reject lone surrogates before data reaches logging, policy, or post-signature processing. A byte signature detects modification but does not make multiple runtimes decode the value identically.

Q10: Which receiver change addresses this resource boundary?

Multiple Choice

An unauthenticated peer sends a 50 MiB JSON document nested 10,000 levels deep. The service builds the full application model before checking its configured 1 MiB and 64-level policy.

A. After authorization and business processing complete B. Enforce the declared limits at the input and parser boundary C. Only in the sender because a conforming parser cannot reject deep input D. Remove the limits because RFC-conforming JSON has no resource cost

A: A late check lets hostile input consume parser and model-building resources first. B: RFC 8259 Section 9 permits limits on text size and maximum nesting depth; applying the profile's declared limits before high-cost processing protects this boundary. C: A parser may impose such limits. D: Grammar conformance says nothing about acceptable resource consumption. The values 1 MiB and 64 levels are application policy, not limits mandated by RFC 8259.

Q11: Which design review conclusion is justified by RFC 8259?

Multiple Choice

A signed A2A grant contains `{"role":"reader","role":"admin"}`. The signature verifier exposes the first `role`, while the authorization service's JSON library exposes the last. Both process the same signed bytes successfully.

A. Accept it because Section 4 says names only SHOULD be unique, so every parser interpretation is equally safe for authorization B. Let each component apply its native duplicate-name behavior because signature coverage makes their member mappings equivalent C. Reject duplicate decision fields at the input boundary and make all security checks consume one unambiguous parsed representation

RFC 8259 Section 4 says object names SHOULD be unique and explains the interoperability reason: implementations disagree when names repeat, variously retaining the first, the last, all values, or rejecting the object. A signature over the bytes does not force those parsers to derive the same name-value mapping. For an authorization field, disagreement creates a security boundary. An A2A profile can strengthen the base JSON guidance by requiring unique names and rejecting duplicates before signature results and authorization data flow into different parsers. The same validated representation should then feed all decision points. Because Section 4 uses SHOULD rather than MUST, RFC 8259 alone does not make every duplicate-name JSON text syntactically nonconforming. The mandatory rejection in this scenario comes from the application's security profile and its need for an unambiguous interpretation, supported by the interoperability risk the RFC documents.

Interoperable JSON parsing and generation

Primary reference

Q1: Which handling correctly separates RFC 8259 Sections 2 and 3 from an application schema?

Q2: Can RFC 8259 alone make a missing member equivalent to `null`?

Q3: Which correction follows from RFC 8259 Section 4?

Q4: Which handling satisfies both RFC 8259 Section 5 and the task-batch schema?

Q5: Which correction follows from RFC 8259 Sections 6, 9, and 10?

Q6: Which representation avoids cross-runtime identifier rounding?

Q7: Which receiving profile follows from RFC 8259 Sections 8.1 and 11?

Q8: Which design prevents this name-filter bypass under RFC 8259 Section 8.3?

Q9: Which input-profile correction applies RFC 8259 Section 8.2?

Q10: Which receiver change addresses this resource boundary?

Q11: Which design review conclusion is justified by RFC 8259?