RFC 8615 Quiz

Q1: Which path is a well-known URI under RFC 8615 for a supporting scheme?

Multiple Choice

A. /.well-known/agent-card.json B. /agents/.well-known/agent-card.json C. /.well-known/

**Explanation:** A: It begins with the registered top-level /.well-known/ prefix. B: A nested occurrence of .well-known is not well-known by definition. C: RFC 8615 defines no resource format for the prefix itself and clients should not expect it to exist.

Q2: A new protocol wants the suffix "metadata/agents". What is the registration problem?

Multiple Choice

A. Registered names must begin with a slash B. The registered name cannot contain the slash character C. All registered names must end in .json

**Explanation:** A: The registry stores the suffix relative to /.well-known/, not a leading slash. B: Registered names must conform to segment-nz, which excludes slash. C: RFC 8615 does not require a filename extension.

Q3: What must a well-known URI registration define at minimum?

Multiple Choice

A. A globally fixed hostname and certificate authority B. A mandatory redirect target for every deployment C. A specification for the format, media types, and applicable schemes

**Explanation:** A: RFC 8615 does not choose the hostname and does not define a dedicated CA. B: Redirect behavior is application-specific and not a minimum registry field. C: The registration must reference a specification defining the retrieved representation and schemes.

Q4: Does RFC 8615 tell an A2A client which hostname contains an agent's metadata?

Multiple Choice

A. Yes, it always uses the issuer hostname B. No, the application must define how the hostname is chosen C. Yes, it requires www.example.com for discovery

**Explanation:** A: RFC 8615 does not define an issuer concept or hostname-selection rule. B: RFC 8615 explicitly leaves hostname determination to the application. C: The example hostname is illustrative and not a deployment requirement.

Q5: What does retrieving a document from a well-known URI establish by itself?

Multiple Choice

A. Only that a resource was obtained from that URI under the transport and origin checks used B. That every claim in the document is globally trusted C. That the resource owner authorized every advertised operation

**Explanation:** A: The path convention does not by itself authenticate claims inside the document. B: Trust in metadata needs application-defined validation beyond path placement. C: RFC 8615 is a location convention and carries no operation authorization semantics.

Q6: A deployment serves well-known metadata from a non-default HTTPS port. What is required?

Multiple Choice

A. The port is inferred from the registered suffix B. The client must scan all ports on the host C. The application must explicitly specify the alternate port

**Explanation:** A: The suffix does not encode an alternate port. B: RFC 8615 does not authorize port scanning as discovery. C: RFC 8615 requires explicit application specification when an alternative port is used.

Q7: Why should write access to a well-known location be tightly controlled?

Multiple Choice

A. Because well-known resources cannot be cached B. Because the location can represent the entire origin C. Because every well-known response runs executable code

**Explanation:** A: RFC 8615 does not generally prohibit caching. B: A co-located tenant with write access could affect discovery for the whole origin. C: The media type and processing model are defined by the application.

Q8: An application shares an HTTPS origin with unrelated web content. Which assumption is unsafe?

Multiple Choice

A. Only the discovery application can interact with cookies and storage on that origin B. Sensitive metadata may need encryption or access controls C. Identifier names should avoid collisions with co-located applications

**Explanation:** A: Other content on the origin can share browser security mechanisms and may issue requests. B: RFC 8615 calls out sensitive-data exposure as a deployment concern. C: Flexible identifier names can reduce origin-wide collisions.

Q9: A protocol chooses the generic registered name "metadata" only to reserve it before others. How does RFC 8615 view this?

Multiple Choice

A. It is required for permanent registrations B. It is safe if the resource returns JSON C. It is discouraged as squatting and the name should be application-specific

**Explanation:** A: Permanent status does not require a generic name. B: Media type does not justify occupying an imprecise suffix. C: RFC 8615 recommends precise names rather than generic terms.

Q10: What should an A2A profile define in addition to choosing a well-known suffix?

Multiple Choice

A. Only the visual filename and display label shown to users B. Hostname selection, metadata scope, representation, and validation rules C. A rule that every possible web origin must publish the same resource

**Explanation:** A: A filename does not define authority, representation, or validation behavior. B: These decisions turn the generic location convention into an interoperable discovery profile. C: RFC 8615 does not force an application resource to exist on every origin.

Discovery locations and origin boundaries

References

Q1: Which path is a well-known URI under RFC 8615 for a supporting scheme?

Q2: A new protocol wants the suffix "metadata/agents". What is the registration problem?

Q3: What must a well-known URI registration define at minimum?

Q4: Does RFC 8615 tell an A2A client which hostname contains an agent's metadata?

Q5: What does retrieving a document from a well-known URI establish by itself?

Q6: A deployment serves well-known metadata from a non-default HTTPS port. What is required?

Q7: Why should write access to a well-known location be tightly controlled?

Q8: An application shares an HTTPS origin with unrelated web content. Which assumption is unsafe?

Q9: A protocol chooses the generic registered name "metadata" only to reserve it before others. How does RFC 8615 view this?

Q10: What should an A2A profile define in addition to choosing a well-known suffix?