ToppyMicroServices

RFC 1958 Quiz

Internet architecture as evolving guidance

πŸ‡ΊπŸ‡ΈπŸ‡―πŸ‡΅
0 / 0

References (URLs)

Q1: Using RFC 1958 Section 2.3 as a review lens, which conclusion stays within what the RFC can establish?

Multiple Choice

A gateway validates a grant and session-bound proof, then sends the backend a signed assertion containing proof_valid=true, the target resource, and freshness data. The backend owns the resource and makes the final authorization decision, but cannot verify the original grant or proof. The architecture does not state whether the gateway is a trusted security endpoint or how its assertion is bound to the backend request.

**Explanation:** A: RFC 1958 is Informational design guidance, not a protocol conformance rule, and Section 2.3 does not categorically prohibit intermediary security functions. B: An authenticated assertion can be evidence in a trusted-gateway design, but its signature and freshness do not define which request, session, resource, or decision it covers. C: Supported. The end-to-end argument asks whether the complete function can be implemented with the required knowledge. Either direct backend verification or reliance on a trusted gateway may be designed, but the latter must define gateway identity and trust, assertion integrity, request and resource binding, freshness, replay handling, and the backend's authorization responsibility. RFC 1958 alone does not choose between those trust models or declare either one conformant. D: A component label does not create the missing assurance contract. The architecture still has to define what the assertion proves and where the final check occurs.

Q2: Which concern can RFC 1958 Sections 2.1 and 2.3 most directly raise about this design?

Multiple Choice

A2A endpoints from two providers are IP-reachable, but only one provider's gateway can translate task state and authorization semantics. The stated requirement is that endpoints recover the same meaning after that gateway fails or the provider is changed.

**Explanation:** A: Sections 2.1 and 2.3 do not normatively forbid gateway processing; a gateway can be an explicit application endpoint. B: Classification does not remove the stated failure requirement or explain who reconstructs the semantics. C: The supported concern is the mismatch between an essential end-to-end function and its single failure dependency. RFC 1958 does not choose a translation protocol or trust model. D: Packet reachability and application-level interoperability are distinct. Section 2.2's discussion of one Internet-layer protocol is not direct support for this application-gateway question, so it is not cited here.

Q3: Which judgment most accurately uses RFC 1958 Section 2.3 to review integrity?

Multiple Choice

An agent approves the exact octet sequence of a 2 GB artifact. A gateway chunks it and an object store reconstructs it. Every hop uses TLS and chunk checksums; the backend must establish that the reconstructed octets equal the approved octets.

**Explanation:** A: Per-hop success explains each segment, not necessarily equality of the exact octets across chunking, storage, and reconstruction. B: The backend checks the complete required property over the same octet sequence the agent approved. Hop checks remain useful as supporting mechanisms. C: A gateway signature proves what the gateway saw, not that those octets are the artifact the agent approved unless a separate binding establishes that relation. D: Completion and size are useful operational evidence but do not prove content equality. RFC 1958 does not choose the digest method; this application follows from the stated exact-octet requirement.

Q4: Using RFC 1958 Section 2.3 as a review lens, which state placement most directly addresses the requirement?

Multiple Choice

The task owner durably keeps authoritative task state and a resume cursor. A relay cluster holds only subscriber mappings. The requirement is to preserve the authoritative cursor after loss of the entire relay cluster and resume a reconnected stream within 30 seconds.

**Explanation:** A: This can improve process availability, but the premise includes loss of the whole cluster, which would remove the only mapping source. B: A durable store could be justified, but it introduces two authorities and an extra consistency dependency not required by the premise. C: Authoritative state shares the task owner's fate, while relay state is self-healing. Replication can still support the recovery-time objective. D: Treating the agent cursor as authoritative introduces replay and rollback questions. Section 2.3 guides review of state fate and reconstruction; it does not prescribe a database technology or a 30-second objective.

Q5: Under RFC 1958 Sections 2.4 and 3.14, which claim-evidence mappings are supported? Select all that apply.

Multi-Select

Two independent implementations of A2A profile X interoperate under loss, reordering, and version mismatch. Profile Y has a detailed formal model but only one implementation. Neither has been evaluated at Internet scale or under attack.

**Explanation:** A: Supported. This is an interoperability claim bounded to observed conditions. B: Unsupported. It extrapolates to properties that were not evaluated. C: Supported. Formal evidence is assessed within its model and assumptions, rather than placed in a single ranking against running code. D: Supported. RFC 1958 values implementation feedback, but it does not by itself settle standardization procedure or untested claims.

Q6: Which conclusion uses RFC 1958 Sections 3.1, 3.3, and 3.4 as a review lens?

Multiple Choice

A profile targets A2A over the public Internet, including mobile agents, but requires a fixed 200 ms deadline, an 8 MB minimum buffer, and frequent heartbeats. Datacenter tests pass; mobile agents time out, and control traffic dominates with one million idle agents.

**Explanation:** A: The observed evidence does not match the Internet-wide claim. A datacenter-scoped profile could potentially justify the values. B: The principles expose the mismatch between scope and evidence. They do not categorically ban fixed values. C: Optionality without negotiation and failure semantics does not establish interoperability. D: Sections 3.3 and 3.4 place scale, performance, and cost inside design review. RFC 1958 does not set the actual deadlines or thresholds.

Q7: Which review conclusion follows from RFC 1958 Section 3.2?

Multiple Choice

Existing Agent Card discovery is widely deployed. A new mechanism reduced metadata leakage by 60% in tests, but requires 18 months of dual lookup and added implementation. Acceptable residual failure and privacy-benefit thresholds are not yet agreed.

**Explanation:** A: Section 3.2 favors reuse but says not to use that argument to reject improvements. B: A measured benefit alone does not evaluate ecosystem-wide interoperability and migration risk. C: Supported. Privacy, performance, or operational improvement can be a good technical reason; it need not be a function the old design could never perform. D: Permanent duplication retains the cost Section 3.2 seeks to avoid. RFC 1958 does not decide whether 60% or 18 months crosses the adoption threshold.

Q8: Which revision is best supported by RFC 1958 Sections 3.5, 3.6, and 3.8?

Multiple Choice

Variation is necessary to serve both low-bandwidth devices and datacenters. The current profile has 14 interacting manual flags; configuration mismatch causes 40% of failures. Three interoperable capability bundles have been tested.

**Explanation:** A: Guidance alone does not resolve the stated manual-coordination failure. B: This reduces options but fails the explicit heterogeneity requirement. C: It keeps required variation while reducing option space and manual configuration. The profile still has to define exact bundle and fallback semantics. D: A larger valid matrix increases implementation and test burden. Section 3.7's almost-complete solution does not license undefined behavior required for interoperability.

Q9: After RFC 1958 Section 3.11 identifies the cycle, which bootstrap design meets the stated assumptions?

Multiple Choice

Fetching an Agent Card requires an OAuth token, but that Card is also the only current source of the token endpoint. The client has no preconfigured issuer; it knows the agent's DNS name and can use DNS and the Web PKI as bootstrap trust.

**Explanation:** A: This breaks the cycle using the trust anchors that the premise makes available. B: Breaking the cycle without source authentication permits metadata substitution; a later token does not retroactively authenticate the discovery response. C: This risks credential disclosure and issuer confusion. D: Parallel requests still lack the information each requires. Section 3.11 identifies the cycle; the concrete metadata format and authentication mechanism come from other specifications and trust policy.

Q10: Which conclusion is supported by RFC 1958 Sections 6.3-6.5 alone?

Multiple Choice

Profile v1 pins Algorithm A and does not include an algorithm identifier in signed data. A migration proposal selects A or B through an integrity-unprotected header. Secure interoperability between different implementations is required.

**Explanation:** A: Section 6.3 discusses designing for alternative algorithms and explicitly labeling the selected algorithm; a fixed unlabeled choice does not cover both. B: Supported. It separates what Sections 6.3-6.5 say from what they leave unspecified. C: Section 6.5 calls for a common algorithm or suite so implementations can establish a secure context. D: A label's existence does not establish resistance to rewriting. RFC 1958 alone does not specify the cryptographic scope of the label, downgrade prevention, or today's allow-list; those require the signature specification, current security guidance, and local policy.