The register

Human readable name of the agent.

`name` is in the AgentCard `required` array (L195).

A URL to the address the agent is hosted at.

No dedicated agent identifier field. The required `url` (the A2A service endpoint) is the only per-agent address in the card; spec §4.2 says clients verify the server's identity via its TLS certificate (docs/specification.md L89).

`https://{server_domain}/.well-known/agent.json`

§5.3 "Recommended Location": the line above (L142) reads "If using the well-known URI strategy, the recommended location for an agent's Agent Card is:". §5.2 also lists registries/catalogs and direct configuration. `agent.json` does not appear in IANA's well-known URI registry (checked 2026-09-15).

A JSON metadata document published by an A2A Server

The spec names no media type for the Agent Card document. Its only Content-Type rule covers JSON-RPC payloads (`application/json`, L67). IANA's application media-type registry has no a2a entry (checked 2026-09-15).

The Agent Card is a JSON document that describes the server's identity, capabilities, skills, service endpoint URL

Defines optional capabilities supported by an agent.

AgentCapabilities has only pushNotifications, stateTransitionHistory and streaming (L99-L116). AgentCard has no `extensions` or `metadata` property, and the word "extension" does not occur in docs/specification.md at this commit.

verify the A2A Server's identity by validating its TLS certificate against trusted certificate authorities

No signature or trust field in the AgentCard schema at this commit. The only trust statement is transport-level: clients SHOULD verify the server's TLS certificate (§4.2).

The version of the agent - format is up to the provider.

No field carries the protocol/spec version. The only version field, `version`, is the agent's own; the prose calls it "Agent or A2A implementation version string" (docs/specification.md L204).

Human readable name of the agent.

`name` is in the AgentCard `required` array (L210).

A URL to the address the agent is hosted at.

Unchanged: no dedicated agent identifier field; required `url` is the service endpoint.

`https://{server_domain}/.well-known/agent.json`

§5.3 "Recommended Location": the line above (L143) reads "If using the well-known URI strategy, the recommended location for an agent's Agent Card is:". §5.2 also lists registries/catalogs and direct configuration. `agent.json` does not appear in IANA's well-known URI registry (checked 2026-09-15).

A JSON metadata document published by an A2A Server

The spec names no media type for the Agent Card document. Its only Content-Type rule covers JSON-RPC payloads (`application/json`, L68). IANA's application media-type registry has no a2a entry (checked 2026-09-15).

The Agent Card is a JSON document that describes the server's identity, capabilities, skills, service endpoint URL

A list of extensions supported by this agent.

AgentCapabilities.extensions: AgentExtension[] (schema L102-L108). AgentExtension: `uri` required; `required`, `description`, `params` optional (docs/specification.md L215-L218).

verify the A2A Server's identity by validating its TLS certificate against trusted certificate authorities

No signature or trust field in the AgentCard schema at this commit. The only trust statement is transport-level: clients SHOULD verify the server's TLS certificate (§4.2).

The version of the agent - format is up to the provider.

Unchanged: no protocol/spec version field in the card.

Human readable name of the agent.

`name` is in the AgentCard `required` array (L243).

A URL to the address the agent is hosted at.

Same line continues: "This represents the preferred endpoint as declared by the agent." v0.2.4 added `preferredTransport` and `additionalInterfaces` (more transport/URL pairs); `url` stays the required endpoint. Still no dedicated agent identifier field.

`https://{server_domain}/.well-known/agent.json`

§5.3 "Recommended Location": the line above (L143) reads "If using the well-known URI strategy, the recommended location for an agent's Agent Card is:". §5.2 also lists registries/catalogs and direct configuration. `agent.json` does not appear in IANA's well-known URI registry (checked 2026-09-15).

A JSON metadata document published by an A2A Server

The spec names no media type for the Agent Card document. Its only Content-Type rule covers JSON-RPC payloads (`application/json`, L68). IANA's application media-type registry has no a2a entry (checked 2026-09-15).

The Agent Card is a JSON document that describes the server's identity, capabilities, skills, service endpoint URL

A list of extensions supported by this agent.

verify the A2A Server's identity by validating its TLS certificate against trusted certificate authorities

No signature or trust field in the AgentCard schema at this commit. The only trust statement is transport-level: clients SHOULD verify the server's TLS certificate (§4.2).

The version of the A2A protocol this agent supports.

Top-level string, in the AgentCard `required` array (L244); schema example "0.2.5" (L187). The agent's own version stays in `version`.

A human-readable name for the agent.

`name` is in the AgentCard `required` array (L273-L283).

The preferred endpoint URL for interacting with the agent.

Same line continues: "This URL MUST support the transport specified by 'preferredTransport'." Still no dedicated agent identifier field.

`https://{server_domain}/.well-known/agent-card.json`

Still the "recommended location" if using the well-known URI strategy (L292). IANA's well-known URI registry lists `agent-card.json` as permanent, Linux Foundation, dated 2025-08-01 (checked 2026-09-15); that entry postdates this commit.

A JSON metadata document published by an A2A Server

Still no media type named for the Agent Card document. The string `a2a+json` does not occur in docs/specification.md at this commit; Content-Type rules cover JSON-RPC and REST payloads (`application/json`, L79 and L100).

The Agent Card is a JSON document that describes the server's identity, capabilities, skills, service endpoint URL

A list of protocol extensions supported by the agent.

AgentCapabilities.extensions (AgentCapabilities starts at L113).

Represents a JSON Web Signature (JWS) used to verify the integrity of the AgentCard.

Optional `signatures` array (schema L241: "JSON Web Signatures computed for this AgentCard."). AgentCardSignature "follows the JSON format of an RFC 7515 JSON Web Signature (JWS)" (schema L287); `protected` and `signature` required. No canonicalization rule at this commit.

The version of the A2A protocol this agent supports.

Top-level, required (L279); schema default "0.3.0" (L199).

string name = 1 [(google.api.field_behavior) = REQUIRED];

Comment at L357: "A human readable name for the agent."

The URL where this interface is available. Must be a valid absolute HTTPS URL in production.

No top-level `url` any more. The endpoint lives in each `supportedInterfaces[]` entry: AgentInterface.url REQUIRED (L339); AgentCard.supported_interfaces REQUIRED, "Ordered list of supported interfaces. The first entry is preferred." (L364-L365). Still no dedicated agent identifier field.

Accessing `https://{server_domain}/.well-known/agent-card.json`

§14.3 adds a well-known URI registration template: "URI suffix: agent-card.json" (L3305), "Status: Permanent" (L3314).

The resource at this URI MUST return an AgentCard object as defined in Section 4.4.1 of the A2A specification.

No media type is stated for the card at the well-known URI. §14.1 (L3203) defines `application/a2a+json` as an IANA registration template, "intended for the HTTP+JSON/REST binding" (L3227); IANA's application registry has no a2a entry (checked 2026-09-15). At this commit the REST binding says `application/json` for requests and responses (L2729), yet the §6.9 example returns the extended Agent Card with `Content-Type: application/a2a+json` (L1837).

A JSON metadata document published by an A2A Server, describing its identity, capabilities, skills, service endpoint, and authentication requirements.

The normative AgentCard is now the Protocol Buffers message in specification/a2a.proto; JSON serializations MUST use camelCase field names (§5.5, L1206), following ProtoJSON (ADR-001).

A list of protocol extensions supported by the agent.

`repeated AgentExtension extensions = 3;` in AgentCapabilities (L412). §4.6.1: "Agents declare their supported extensions in the AgentCard using the `extensions` field" (docs/specification.md L1006); its example nests it under `capabilities`.

Agent Cards **MAY** be digitally signed using JSON Web Signature (JWS)

New here: before signing, the card MUST be canonicalized with JCS, RFC 8785 (L1983), and the `signatures` field is excluded from the signed content. `repeated AgentCardSignature signatures = 13;` is optional (proto L390).

The version of the A2A protocol this interface exposes.

Nested per interface and REQUIRED (`string protocol_version = 4`, L349); JSON name `protocolVersion`. The top-level `protocolVersion` is gone. §3.6 (L710): versions are Major.Minor; patch numbers SHOULD NOT be used in Agent Cards. Appendix A.2.1 still tells implementers to use an AgentCard `protocolVersions` field (L3486, L3494) that the proto does not define.

string name = 1 [(google.api.field_behavior) = REQUIRED];

Unchanged from v1.0.0.

The URL where this interface is available. Must be a valid absolute HTTPS URL in production.

Unchanged: endpoint in REQUIRED `supportedInterfaces[].url` (L339). Changed nearby: optional AgentInterface.tenant is now described as "An opaque string used for routing requests to a specific agent or tenant when multiple agents are served behind a single A2A endpoint" (L344-L345); the protocol "does not define its format or semantics" (L349).

Accessing `https://{server_domain}/.well-known/agent-card.json`

§14.3 template unchanged (L3328, L3337). IANA's well-known URI registry lists `agent-card.json` as permanent (checked 2026-09-15).

The resource at this URI MUST return an AgentCard object as defined in Section 4.4.1 of the A2A specification.

Still no media type for the card at the well-known URI. Changed here: the REST binding now says "application/a2a+json **SHOULD** be used for requests and responses" (L2750), which covers `GET /extendedAgentCard`; the JSON-RPC binding keeps `application/json` (L2236). `application/a2a+json` is still not in IANA's application registry (checked 2026-09-15).

A JSON metadata document published by an A2A Server, describing its identity, capabilities, skills, service endpoint, and authentication requirements.

Unchanged: proto is normative; JSON uses camelCase (§5.5, L1204).

A list of protocol extensions supported by the agent.

`repeated AgentExtension extensions = 3;` (L417). Unchanged.

Agent Cards **MAY** be digitally signed using JSON Web Signature (JWS)

Unchanged: JCS (RFC 8785) canonicalization before signing (L2008); `signatures` optional (proto L395).

The version of the A2A protocol this interface exposes.

REQUIRED (L354). Unchanged. Appendix A.2.1 still mentions an AgentCard `protocolVersions` field (L3509, L3517).

**title** (string, optional): Human-readable server display name

Nested in `serverInfo`, which follows the `Implementation` interface (L151).

**name** (string, required): Server identifier for programmatic use

No format is given for the name. Example value: "example-mcp-server" (L51).

/.well-known/mcp/server-card.json

The same text disagrees with itself: the Abstract (L12) and Proposed Solution (L26) say `.well-known/mcp.json`. A second endpoint, an MCP resource at `mcp://server-card.json` (L206), is SHOULD for all servers, so cards can also be read after connecting.

MUST return `Content-Type: application/json`

Generic JSON type (IANA, RFC 8259). No card-specific media type is defined. The MCP resource also uses MIME type application/json (L207).

Static resource containing the server card JSON

Schema examples are JSON blocks (L45, L91).

**_meta** (object, optional): Additional metadata following

Follows MCP's standard `_meta` definition. `capabilities.experimental` (L162) is part of the copied server capabilities, not a card extension point.

because server cards are advisory (the actual connection still requires initialization and authentication)

No signature or trust mechanism. Same line: cards SHOULD be served over HTTPS and clients SHOULD validate TLS certificates. Clients MUST check that the tools seen at initialization match the advertised ones (L317).

**version** (string, required): Schema version for the server card document (e.g., "1.0")

$schema = URL of the card's JSON schema (L148). version = card document schema version (L149). protocolVersion = the MCP protocol version the server supports (L150). serverInfo.version = server software version (L154).

**title** (string, optional): Optional human-readable title or display name for the MCP server.

**name** (string, required): Server name in reverse-DNS format.

Same line: 'Must contain exactly one forward slash separating namespace from server name.' Example: "io.modelcontextprotocol.anonymous/brave-search" (L68).

/.well-known/mcp/server-card

The multi-tenant example uses sub-paths `/.well-known/mcp/server-card/<id>` (L54). `.well-known/ai-catalog.json` is named as the AI Card domain mechanism (L43). The MCP resource `mcp://server-card.json` is still SHOULD (L348).

MUST return `Content-Type: application/json`

Unchanged: generic JSON, no card-specific type.

Static resource containing the server card JSON

**\_meta** (object, optional): Additional metadata following

because server cards are advisory (the actual connection still requires initialization and authentication)

Unchanged: HTTPS SHOULD, no signature.

**version** (string, required): Version string for this server. SHOULD follow semantic versioning

version = server version ('Equivalent of Implementation.version', same line). $schema = card schema URI 'that evolves in-place per major version iteration' (L289). remotes[].supportedProtocolVersions (L298) and packages[].supportedProtocolVersions (L304) = MCP protocol versions each remote or package supports. The initial draft's card-document `version` and `protocolVersion` are removed.

**title** (string, optional): Optional human-readable title or display name for the MCP server.

**name** (string, required): Server name in reverse-DNS format.

/.well-known/mcp/server-card

Path unchanged. `.well-known` is now the only endpoint: 'MCP Server Cards supporting HTTP-based transports ... _SHOULD_ provide a server card via a .well-known URI.' (L304). Local stdio servers are pointed to server.json and the MCP Registry instead (L306).

MUST return `Content-Type: application/json`

MUST return `Content-Type: application/json`

The MCP-resource line that said 'server card JSON' was removed in this commit. The served Content-Type is the remaining statement of encoding.

**\_meta** (object, optional): Additional metadata following

because server cards are advisory (the actual connection still requires initialization and authentication)

**supportedProtocolVersions** (array of string, optional): list of MCP protocol versions actively supported by this Remote.

$schema (L189) and version (L191) are unchanged. packages[].supportedProtocolVersions now appears only in the separate server.json schema (L296-L297), not in the card.

**title** (string, optional): Optional human-readable title or display name for the MCP server.

**name** (string, required): Server name in reverse-DNS format.

/.well-known/mcp-server-card

Hosts with several servers SHOULD use `/.well-known/mcp-server-card/{server-name}` (L319), where `{server-name}` matches the card's `name` (L322). IANA registration is planned for suffix `mcp-server-card` (L436, L440).

MUST return `Content-Type: application/json`

MUST return `Content-Type: application/json`

**\_meta** (object, optional): Additional metadata following

because server cards are advisory (the actual connection still requires initialization and authentication)

**supportedProtocolVersions** (array of string, optional): list of MCP protocol versions actively supported by this Remote.

$schema L189, version L191.

Optional human-readable title or display name for the MCP server.

`title?: string` (L81). MCP Catalog entries also carry a required `displayName` (docs/discovery.md L56), which is a catalog field, not a card field.

Server name in reverse-DNS format. Must contain exactly one forward slash

Pattern `^[a-zA-Z0-9.-]+/[a-zA-Z0-9._-]+$` (L50) does not itself require a dot. Catalog entries get their own identifier: 'MUST begin with `urn:mcp:server:` and end with the `name` value' of the card (docs/discovery.md L60).

publishing at a `.well-known/mcp-server-card` URI for pre-connection discovery.

Card path unchanged in schema.ts. New: domain-level MCP Catalog at `/.well-known/mcp/catalog.json` (docs/discovery.md L31). Its entries carry each card's `url`, and the example uses `https://example.com/.well-known/mcp-server-card` (L75). The README at this SHA uses the slash form `/.well-known/mcp/server-card` (README.md L13); that mismatch was later tracked as ext issue #11.

Server Cards use the media type `application/mcp-server+json`.

Named in the text but not registered: it is absent from the IANA application media-type registry (checked 2026-09-15). The catalog entry `mediaType` 'MUST be `application/mcp-server+json`' (L57). The SEP at the same time (ce0d2da) still said the card endpoint 'MUST return `Content-Type: application/json`'.

An **MCP Server Card** is a JSON document that describes a single MCP server

README.md L27 at this SHA: schema.json is 'Generated JSON Schema 2020-12'.

Extension metadata using reverse-DNS namespacing for vendor-specific data.

`_meta?: MetaObject` (L121), following the protocol's standard `_meta` definition (L117).

Domains that want richer metadata (trust manifests, publisher identity, collections) can adopt the full AI Catalog format

At this SHA, schema.ts, README.md and discovery.md say nothing about card authenticity, signing or advisory status. The cited line leaves trust manifests to the full AI Catalog format. The HTTPS/TLS rule (L199) covers MCP Catalogs only. The SEP branch at the same date still called cards advisory (ce0d2da).

Schema URLs are versioned by the `vN` segment rather than by date so that

$schema pattern `^https://static\.modelcontextprotocol\.io/schemas/v1/[^/]+\.schema\.json$` (L40). version = server version, 'Equivalent of `Implementation.version`' (L55-L57). remotes[].supportedProtocolVersions (L217-L220). The separate `Server` superset (server.json shape) also has packages[].supportedProtocolVersions (L261-L263).

Optional human-readable title or display name for the MCP server.

MCP Catalog entries still carry a required `displayName` (docs/discovery.md L56).

Server name in reverse-DNS format. Must contain exactly one forward slash

Catalog identifier is still `urn:mcp:server:` + card `name` (docs/discovery.md L60).

The Catalog is the discovery entrypoint, and every Catalog Entry already carries the

The card no longer has a well-known path. 'Clients therefore never need to _guess_ a Server Card's location' and a card 'MAY be hosted at any unreserved URI' (L175-L177). Reserved default: 'MCP Servers MAY host their Server Card at `GET <streamable-http-url>/server-card`' (L181). A `.well-known` card path was considered and not recommended (L202). The catalog is at `/.well-known/mcp/catalog.json` (L31). schema.ts L14-L15 says the same.

Server Cards use the media type `application/mcp-server-card+json`.

Clients SHOULD send `Accept: application/mcp-server-card+json` (L190). Not in the IANA registry (checked 2026-09-15).

An **MCP Server Card** is a JSON document that describes a single MCP server

Extension metadata using reverse-DNS namespacing for vendor-specific data.

Clients MUST NOT treat Server Card contents as authoritative for security or

Cards are advisory, with no signature or manifest. Clients 'SHOULD verify a Server Card's claims against the live connection, preferring the runtime values' (L169-L170). schema.ts L25-L27 says the same.

Schema URLs are versioned by the `vN` segment rather than by date so that

$schema pattern still allows any `/v1/<name>.schema.json` (L49). remotes[].supportedProtocolVersions at L230.

Optional human-readable title or display name for the MCP server.

Catalog entries no longer repeat the name. Clients 'can read the server's `title`, `description`, and `version` from the card itself' (docs/discovery.md L54-L55).

Server name in reverse-DNS format. Must contain exactly one forward slash

The card keeps its reverse-DNS `name`. AI Catalog entry identifiers use `urn:air:{publisher}:{namespace}:{name}` (docs/discovery.md L48); a card named `com.example/weather` 'can use the catalog identifier `urn:air:example.com:mcp:weather`' (L51-L52). urn:air is catalog-level, not a card field.

Fetch `https://{domain}/.well-known/ai-catalog.json`

Step 1 of the SHOULD client flow (L104). 'Clients performing domain-level discovery SHOULD attempt to retrieve this well-known URL' (L29), and the catalog SHOULD use `application/ai-catalog+json` (L30). An entry carries `url` or inline `data` (L42-L43). The card's own location is unchanged: any unreserved URI, with `GET <streamable-http-url>/server-card` reserved (L174). schema.ts L12-L13: clients learn a card's URL 'from an AI Catalog rather than guessing it'.

Server Cards use the media type `application/mcp-server-card+json`.

The catalog entry `type` 'MUST be `application/mcp-server-card+json`' (L41). Not IANA-registered (checked 2026-09-15).

An **MCP Server Card** is a JSON document that describes a single MCP server

Extension metadata using reverse-DNS namespacing for vendor-specific data.

README.md L27 (since #28): namespaced `_meta` 'remains the card's extension point'. README.md L63: card objects are open (no `additionalProperties: false`).

Clients MUST NOT treat Server Card contents as authoritative for security or

Unchanged: advisory, checked against the live `server/discover` result (L146-L163).

Schema URLs are versioned by the `vN` segment rather than by date; a

Since #28 the $schema pattern is pinned to `.../schemas/v1/server-card\.schema\.json$` (L40), and 'a breaking revision of the Server Card shape publishes a new `vN` family' (L37). remotes[].supportedProtocolVersions at L199-L202.

Optional human-readable title or display name for the MCP server.

`title?: string` (L81). Clients read `title` from the card, not the catalog entry (docs/discovery.md L54-L55).

Server name in reverse-DNS format. Must contain exactly one forward slash

Pattern `^[a-zA-Z0-9.-]+/[a-zA-Z0-9._-]+$` (L50). The valid example examples/ServerCard/valid/minimal.json uses `example-org/minimal`, with no dot. Catalog-level identifier: `urn:air:{publisher}:{namespace}:{name}` (docs/discovery.md L48).

Fetch `https://{domain}/.well-known/ai-catalog.json`

Card location: 'MCP Servers MAY host their Server Card at `GET <streamable-http-url>/server-card`, which we reserve for this purpose, though any unreserved URI (on any domain) is valid' (L174-L175). SEP 5c8483d L90: 'Cards can be hosted at any unreserved URI, with `<streamable-http-url>/server-card` reserved as the recommended location.'

Server Cards use the media type `application/mcp-server-card+json`.

Not in the IANA application media-type registry (checked 2026-09-15); the only 'mcp' matches are unrelated vnd.3gpp.mcptt-* types. Clients SHOULD send `Accept: application/mcp-server-card+json` (L182).

An **MCP Server Card** is a JSON document that describes a single MCP server

extension metadata, which remains the card's extension point.

The line begins 'Vendors who genuinely need to attach install hints to a Server Card can use namespaced [`_meta`]'. schema.ts L115 and L121 define `_meta?: MetaObject`. SEP 5c8483d L89: '`_meta` is not used to advertise MCP capabilities or negotiated extension support.'

Clients MUST NOT treat Server Card contents as authoritative for security or

Advisory only. The 'Server Card Accuracy' security note (L229-L238) calls an inaccurate card 'a mild confusion or downgrade vector'. Hosted cards MUST use HTTPS, TLS 1.2 or later, in production (L273). No signature or trust manifest.

Schema URLs are versioned by the `vN` segment rather than by date; a

$schema must equal `https://static.modelcontextprotocol.io/schemas/v1/server-card.schema.json` (L35, L40). version = server version, 'Equivalent of `Implementation.version`' (L55-L57). remotes[].supportedProtocolVersions = 'MCP protocol versions actively supported by this remote endpoint' (L199-L202). README.md L63: 'The `v1` shape is still pre-release and card-only'.

displayName: text,

CatalogEntry CDDL, no '?' marker. Prose lists `displayName` (L188) under 'It MUST contain the following members' (L180).

A string identifying this artifact. This SHOULD be a URN

Entry `identifier`. L184 continues '[[RFC8141]] or URI [[RFC3986]] (e.g., `urn:example:agent:name`)'. No URN namespace is prescribed.

/.well-known/ai-catalog.json

Hosts MAY serve it there; 'Use of the well-known URI is OPTIONAL' (L657) and a catalog MAY be served from any URL (L636). Link relation `ai-catalog` via HTTP Link header or HTML <link> (L670), with an IANA link relation registration section (L897). No well-known URI registration section yet.

application/ai-catalog+json

IANA Considerations: 'This section registers the `application/ai-catalog+json` media type' (L850). Not in the IANA media types registry (checked 2026-09-15), so recorded as de-facto.

An AI Catalog document is a JSON object that MUST contain the following

An open map of string keys to arbitrary values for custom data.

Optional entry `metadata` (L234). The same open map is on the catalog top level (L148) and the Trust Manifest (L356).

The Trust Manifest is an OPTIONAL companion to catalog entries and

Optional entry `trustManifest` (L243), also allowed on the host. Its optional `signature` is 'a detached JWS [[RFC7515]]' (L351-352) over the JCS-canonicalized manifest (L453-462).

`specVersion`

Required top-level member: 'the version of this specification that the catalog conforms to, in "Major.Minor" format' (L103-104). Entry `version` is the artifact's version, not the spec's.

displayName: text,

CatalogEntry CDDL, no '?' marker. Unchanged since #27.

A string identifying this artifact. This SHOULD be a URN

Unchanged: L193 '[[RFC8141]] or URI [[RFC3986]] (e.g., `urn:example:agent:name`)'.

/.well-known/ai-catalog.json

Still OPTIONAL (L832). Link relation `ai-catalog` (L845). New: 'This section registers the `ai-catalog.json` well-known URI' (L1184), in addition to the link relation registration (L1168).

application/ai-catalog+json

Registration section at L1121. Not in the IANA registry (checked 2026-09-15).

An AI Catalog document is a JSON object that MUST contain the following

An open map of string keys to arbitrary values for custom data.

Entry `metadata` (L243). New Metadata Extensibility section (L729): reverse-DNS key prefixes RECOMMENDED for vendor-specific keys (L738-742); short unqualified names also allowed.

The Trust Manifest is an OPTIONAL companion to catalog entries and

Detached JWS `signature` (L389-390). Security Considerations recast as progressive trust layers; Layer 2 'includes a `signature` field (detached JWS)' (L956).

`specVersion`

New Version Handling section (L764): 'Major.Minor' format, minor = additive, major = breaking.

displayName: text,

CatalogEntry CDDL, no '?' marker.

the standard `urn:air` naming structure is **HIGHLY RECOMMENDED** and **MUST** be used for open or federated systems.

The field itself stays open text ('any valid URI or URN is accepted', same line). Format `urn:air:{publisher}:{namespace}:{name}` (L195), {publisher} = the publisher's domain name. Closed or local systems may use other formats. Trust Manifest `identity` now aligns with the identifier's publisher domain segment (L366) instead of matching it exactly.

/.well-known/ai-catalog.json

Link relation `ai-catalog` (L858). Registration sections: link relation (L1181), well-known URI (L1197).

application/ai-catalog+json

Catalog document media type unchanged (registration section L1134, not registered). The entry-level rename (`mediaType` to `type`) is about the referenced artifact's type, not the catalog's.

An AI Catalog document is a JSON object that MUST contain the following

An open map of string keys to arbitrary values for custom data.

Entry `metadata` (L261); unchanged.

The Trust Manifest is an OPTIONAL companion to catalog entries and

Detached JWS `signature` (L409-410).

`specVersion`

Because `displayName` is OPTIONAL, a consumer rendering a catalog entry

Listed under 'The following members are OPTIONAL:' (L241, L243). Conflict at this SHA: the CDDL, which the spec calls 'the normative schema' (L1260), still reads `displayName: text,` with no '?' (L1283). #56 fixed it.

the standard `urn:air` naming structure is **HIGHLY RECOMMENDED** and **MUST** be used for open or federated systems.

Format `urn:air:{publisher}:{namespace}:{name}` (L193). New last-resort name fallback: the identifier's trailing segment.

/.well-known/ai-catalog.json

Link relation `ai-catalog` (L902); registrations at L1225 (link relation) and L1241 (well-known URI).

application/ai-catalog+json

Registration section L1178; not registered.

An AI Catalog document is a JSON object that MUST contain the following

An open map of string keys to arbitrary values for custom data.

Entry `metadata` (L277); unchanged.

The Trust Manifest is an OPTIONAL companion to catalog entries and

Detached JWS `signature` (L453-454).

`specVersion`

? displayName: text,

CDDL and prose (L241-244, L293) now agree.

the standard `urn:air` naming structure is **HIGHLY RECOMMENDED** and **MUST** be used for open or federated systems.

Format line L193; unchanged.

/.well-known/ai-catalog.json

Link relation `ai-catalog` (L902); unchanged.

application/ai-catalog+json

Registration section L1178; not registered.

An AI Catalog document is a JSON object that MUST contain the following

An open map of string keys to arbitrary values for custom data.

Unchanged.

The Trust Manifest is an OPTIONAL companion to catalog entries and

Unchanged.

`specVersion`

? displayName: text,

Prose: L243, resolution order L322.

the standard `urn:air` naming structure is **HIGHLY RECOMMENDED** and **MUST** be used for open or federated systems.

Format line L193; unchanged.

/.well-known/ai-catalog.json

Link relation `ai-catalog` (L1019); registrations L1341 (link relation), L1357 (well-known URI).

application/ai-catalog+json

Registration section L1294; not registered.

An AI Catalog document is a JSON object that MUST contain the following

Still plain JSON. The Extensions example shows an extension value that itself carries an `@context` key; that is extension data, not the document encoding.

represent the extension type (namespace), and the corresponding value contains the extension data.

L881: 'The `extensions` field is a JSON object (map). Each key in the object MUST'. Keys 'MUST be a valid URL or a reverse-DNS string' (L884-885). Entry `extensions` at L306, also on the catalog top level (L143) and Trust Manifest (L545). One official extension: `https://ai-catalog.org/extensions/metadata`. The Level 1 text still says `metadata` (L1076); #47 fixed it.

The Trust Manifest is an OPTIONAL companion to catalog entries and

Detached JWS `signature` (L540-541).

`specVersion`

Version Handling section L937.

? displayName: text,

Prose resolution order L330.

the standard `urn:air` naming structure is **HIGHLY RECOMMENDED** and **MUST** be used for open or federated systems.

Format line L201. The Trust Manifest `identity` domain MUST align with the publisher domain in the entry `identifier`, even across URI schemes.

/.well-known/ai-catalog.json

Link relation `ai-catalog` (L1244); registrations L1617 (link relation), L1633 (well-known URI).

application/ai-catalog+json

Registration section L1570; not registered.

An AI Catalog document is a JSON object that MUST contain the following

represent the extension type (namespace), and the corresponding value contains the extension data.

Keys URL or reverse-DNS (L1110). Level 1 text now says `extensions` (L1301).

contain at least one *substantive* trust member:

Substantive = signature, non-empty attestations or provenance, or trustSchema. `trustManifest` itself stays OPTIONAL: 'the `trustManifest` member is itself OPTIONAL' (L542-543). Level 3 requires signature + subject + issuedAt on relied-upon entries. New optional top-level catalog `signature`, a detached JWS over the JCS-canonicalized catalog (L148-149). The CDDL at this SHA has no top-level `signature` (L1658-1663) and no `subject`/`issuedAt`/`expiresAt` in TrustManifest (L1697-1707).

`specVersion`

? displayName: text,

Prose: listed under OPTIONAL (L259, L261). Resolution order (L342): entry displayName, then the artifact's own name, then the identifier's trailing segment.

the standard `urn:air` naming structure is **HIGHLY RECOMMENDED** and **MUST** be used for open or federated systems.

Open-text field ('any valid URI or URN is accepted', same line). Format `urn:air:{publisher}:{namespace}:{name}` (L209).

/.well-known/ai-catalog.json

OPTIONAL; a catalog MAY be served from any URL. Link relation `ai-catalog` (L1256). Registration sections: link relation (L1629), well-known URI (L1645). Neither is in the IANA registries (checked 2026-09-15); IANA lists only RFC 9727 `api-catalog`.

application/ai-catalog+json

Registration section L1582. `curl https://www.iana.org/assignments/media-types/application.csv | grep -i catalog` on 2026-09-15 returns no ai-catalog entry.

An AI Catalog document is a JSON object that MUST contain the following

represent the extension type (namespace), and the corresponding value contains the extension data.

Keys 'MUST be a valid URL or a reverse-DNS string' (L1121-1122). Entry `extensions` L326; catalog top level L151; Trust Manifest L612.

contain at least one *substantive* trust member:

`trustManifest` is OPTIONAL (L553-555). Trust Manifest `signature` is a detached JWS (L604-605); optional top-level catalog `signature` JWS (L156-157). The CDDL still lacks the top-level `signature` (L1670-1675) and TrustManifest `subject`/`issuedAt`/`expiresAt` (L1709-1719).

`specVersion`

'Major.Minor' format (L104); Version Handling section L1174.

| displayName | String | Human-readable name. |

Row of the table introduced by 'Each object in the entries array MUST contain:' (L159).

urn:ai:<publisher>:<namespace>:<agent-name>

§4.2.1 (L189): the identifier MUST follow a domain-anchored URN format complying with RFC 8141. NID is 'ai' (L198); <publisher> MUST be an FQDN (L199).

Hosting the manifest at https://{domain}/.well-known/ai-catalog.json.

Link relation: rel="ai-catalog" in an HTML <link> tag (L395). Also listed: an Agentmap directive in robots.txt (L394) and DNS Service Binding records (L396).

"type": "application/ai-catalog+json",

No media type is defined for the manifest document. application/ai-catalog+json appears only as the `type` of an entry whose `data` is a nested catalog (L101); the spec does not call it the manifest's media type or state its registration status.

A decentralized publishing mechanism where developers and enterprises host static JSON manifests.

The manifest file is ai-catalog.json (L65); all examples are JSON.

| metadata | Map | Custom metadata key-value pairs. |

Optional entry field. §4.5 (L341) also lets entries use Schema.org vocabulary in descriptive fields as Search filter dimensions.

Optional. Detached JWS signature computed over the Trust Manifest content.

trustManifest is an optional entry field (L185); identity is its only required member (L353). Verification procedures are deferred to the ai-catalog specification (L380).

"specVersion": "1.0",

Shown in the §4.1 manifest example only; no field table defines manifest top-level members at this commit. The JSON Schema added 2026-05-20 (1530a30) requires it, enum ["1.0"], described as the version of the ai-catalog specification.

| displayName | String | Human-readable name. |

Row of the table introduced by 'Each object in the entries array MUST contain:' (L163).

urn:air:<publisher>:<namespace>:<agent-name>

Changed from urn:ai in this commit (ADR-0009, NID length). ai-catalog.schema.json pattern ^urn:air:... (L70). The §4.2.1 NID bullet (L202) still read 'ai' until f7e6fc0 (2026-06-22).

Hosting the manifest at https://{domain}/.well-known/ai-catalog.json.

Link relation: rel="ai-catalog" (L395). Agentmap (L394) and DNS Service Binding records (L396) also listed. The DNS bullet gained SVCB/TXT detail on 2026-07-02 (0991376); path and relation unchanged.

"type": "application/ai-catalog+json",

No media type is defined for the manifest document. application/ai-catalog+json is the `type` of entries that carry (L107) or point to (L153) a nested catalog. §4 (L67) says the manifest builds upon and extends the ai-catalog schema. Registration status is not stated.

A decentralized publishing mechanism where developers and enterprises host static JSON manifests.

Appendix D (L706) describes the CDDL as supporting both JSON and CBOR encodings; the manifest file is ai-catalog.json (L71).

| metadata | Map | Custom metadata key-value pairs. |

ai-catalog.schema.json L122: 'Arbitrary key-value pairs for custom extensions.' §4.5 (L342) allows Schema.org vocabulary in descriptive fields.

Optional. Detached JWS signature computed over the Trust Manifest content.

trustManifest is optional (L189); identity is its only required member (L354). ai-catalog.schema.json L203: 'Detached JWS signature generated over the fields of the trustManifest.' Verification is deferred to the ai-catalog specification (L380).

Version of the ai-catalog specification used in this manifest.

Required at the manifest root (L7), enum ["1.0"] (L12). ard.cddl L9: specVersion: "1.0".

| displayName | MUST | Human-readable name. |

Row of the table introduced by 'An ARD entry MUST carry:' (L86).

Domain-anchored URN form (`urn:air:<publisher>:<namespace>:<agent-name>`); see Appendix C.

The JSON-LD @id MAY mirror the identifier (L90). ard-entry.schema.json pattern ^urn:air:... (L26).

Hosting a manifest of entries at `https://{domain}/.well-known/ard.json`.

Link relation: rel="ard" (L199). A consumer MUST fetch /.well-known/ard.json and MUST honour rel="ard"; it MAY also consult the predecessor /.well-known/ai-catalog.json and rel="ai-catalog" (L202). A publisher on the predecessor path SHOULD move to ard.json (L204). In-page JSON-LD markup (L197), Agentmap and DNS (L200) are also listed.

The manifest is a JSON document with an `entries` array of ARD entries (§4)

No media type is defined for the manifest document. Entry `type` is the artifact's IANA media type (L92); registries are found through entries whose type is application/ai-registry+json (L215). The application/ai-catalog+json nested-catalog examples are gone.

An entry is a JSON-LD node describing an agentic resource.

Per entry. A consumer MUST expand an entry with the ARD base context (L80; spec/schemas/ard.context.jsonld). Carrying @context in the entry is OPTIONAL (L82). The /.well-known/ard.json manifest itself is 'a JSON document' (L196).

Terms from any additional namespace declared in the entry's `@context` MAY also appear

Such terms become filter dimensions with no spec change (L108). `metadata` remains an optional descriptive term (L106). The schema sets additionalProperties: true by design (L530); ard.cddl ard-entry ends with a `* tstr => any` wildcard (L25).

ARD does not define a signing or verification procedure of its own.

trustManifest is optional; ARD requires only trustManifest.identity (L173), whose trust domain MUST align with the URN publisher (L177). Signing, canonicalization and key resolution come from the framework named in trustManifest.trustSchema (L181). ard-entry.schema.json L170 no longer names JWS. The schema's entry property key is `TrustManifest` (L81); the spec, ard.cddl (L45) and the base context use `trustManifest`.

ARD requires only an `entries` array of ARD entries

ArdManifest requires only entries (L106); other top-level members are transport-defined and ignored by ARD. ard.cddl ard-manifest is entries plus a wildcard (L13-L15). specVersion is no longer defined. The base context URL ends /context/v1 (spec L78) and entry `version` is the artifact version; neither is a spec-version field.

| displayName | MUST | Human-readable name. |

Row of the table introduced by 'An ARD entry MUST carry:' (L86).

Domain-anchored URN form (`urn:air:<publisher>:<namespace>:<agent-name>`); see Appendix C.

The JSON-LD @id MAY mirror the identifier (L90). ard-entry.schema.json pattern ^urn:air:... (L26).

Hosting a manifest of entries at `https://{domain}/.well-known/ard.json`.

Link relation: rel="ard" (L199). A consumer MUST fetch /.well-known/ard.json and MUST honour rel="ard"; it MAY also consult the predecessor /.well-known/ai-catalog.json and rel="ai-catalog" (L202). A publisher on the predecessor path SHOULD move to ard.json (L204). In-page JSON-LD markup (L197), Agentmap and DNS (L200) are also listed.

The manifest is a JSON document with an `entries` array of ARD entries (§4)

No media type is defined for the manifest document. Entry `type` is the artifact's IANA media type (L92); registries are found through entries whose type is application/ai-registry+json (L215). The application/ai-catalog+json nested-catalog examples are gone.

An entry is a JSON-LD node describing an agentic resource.

Per entry. A consumer MUST expand an entry with the ARD base context (L80; spec/schemas/ard.context.jsonld). Carrying @context in the entry is OPTIONAL (L82). The /.well-known/ard.json manifest itself is 'a JSON document' (L196).

Terms from any additional namespace declared in the entry's `@context` MAY also appear

Such terms become filter dimensions with no spec change (L108). `metadata` remains an optional descriptive term (L106). The schema sets additionalProperties: true by design (L530); ard.cddl ard-entry ends with a `* tstr => any` wildcard (L25).

ARD does not define a signing or verification procedure of its own.

trustManifest is optional; ARD requires only trustManifest.identity (L173), whose trust domain MUST align with the URN publisher (L177). Signing, canonicalization and key resolution come from the framework named in trustManifest.trustSchema (L181). ard-entry.schema.json L170 no longer names JWS. The schema's entry property key is `TrustManifest` (L81); the spec, ard.cddl (L45) and the base context use `trustManifest`.

ARD requires only an `entries` array of ARD entries

ArdManifest requires only entries (L106); other top-level members are transport-defined and ignored by ARD. ard.cddl ard-manifest is entries plus a wildcard (L13-L15). specVersion is no longer defined. The base context URL ends /context/v1 (spec L78) and entry `version` is the artifact version; neither is a spec-version field.

`name` — Unicode string, unique within the issuing vendor namespace

Listed under the agent section's 'Required subfields' (L125); L109 requires `agent` 'with at least `name` and `id`'. No separate human display-name field is defined.

`id` — Globally unique identifier (DID, URI, or vendor-scoped UUID)

Required `agent.id`; schemes open (DID, URI, or vendor-scoped UUID); example uses did:web (L70). Security §11 adds 'Validate `agent.id` against known identifier schemes' (L222).

v0.1 is silent on how a .fafa document is found or fetched. The only 'discovery' wording is capability `tags` 'for filtering / discovery' (L150), which is about filtering capabilities, not locating the document.

**MIME Type (proposed):** `application/vnd.fafa+yaml`

Named vendor-tree type, not registered: L7 'IANA Registration: Queued — to be submitted after `vnd.fafm+yaml` clears DE review'. 'de-facto' here = named in the spec but unregistered. The IANA page (registered 2026-06-26) postdates this commit, so the spec line is cited.

A `.fafa` file is a single YAML document

§12 (L239): '`.fafa` is YAML 1.2 / RFC 9512 compliant.'

`metadata` (free-form vendor extensions)

Optional top-level `metadata`. §12 also: 'Treat unknown top-level fields as forward-compatible extensions' (L243) and unknown subfields within agent/capabilities/endpoints (L244).

signature: # OPTIONAL — provenance / integrity

Example block has only `method: ...` and `value: ...` (L103–104); no algorithm, key or format defined. §11 (L223): 'Treat `endpoints` as untrusted until verified against `signature` if present'. Open question 2 (L297): single object or array.

The `version` field at document top-level declares which version of this spec the document conforms to.

Top-level `version` = .fafa spec version (example "0.1", L66); distinct from `agent.version` = 'Semantic version of the agent (NOT of the .fafa spec)' (L131).

**Required:** `name` (Unicode string, unique within the issuing vendor namespace)

No display-name field in the spec text.

`id` (globally unique identifier — DID, URI, or vendor-scoped UUID)

Same schemes as v0.1. §15 (L242): multiple .fafa documents per scope 'distinguished by `agent.id`'. §18 defers 'Multiple simultaneous identifier schemes for `agent.id`' (L283). v0.1's 'Validate `agent.id` against known identifier schemes' MUST is no longer present.

It does not define discovery, transport, authorization, or orchestration.

Explicitly out of scope: 'It defines the **document** those mechanisms carry, reference, and resolve.' §15 (L241) names a standard filename `agent.fafa` (alongside `project.faf` at the project layer). That is a file convention, not a discovery path.

**MIME Type (proposed):** `application/vnd.fafa+yaml`

L7: 'IANA Registration: Planned (queued behind `application/vnd.fafm+yaml`, registered 2026-05-13)'. IANA registered .fafa on 2026-06-26, but this text was not updated until 2026-08-15 (0156596), so from 2026-06-26 to 2026-08-15 the spec text lagged the registry.

A `.fafa` file is a single YAML document:

§13 (L215): '`.fafa` is YAML 1.2 / RFC 9512 compliant.'

**Optional top-level fields:** `attachment`, `provenance`, `signature`, `metadata` (free-form vendor extensions).

§13 (L218): consumers MUST treat unknown top-level fields, and unknown subfields within agent/capabilities/endpoints, as forward-compatible extensions.

Where present, `signature` carries provenance/integrity material; verification is the consumer's responsibility.

Same `signature` block (`method`, `value`; L86–88). Same line: 'The format does not itself provide cryptographic services.' §18 defers '`signature` as an array (multiple signers)' (L284) and content-addressed provenance (L287).

The top-level `version` field declares which version of this specification the document conforms to.

Distinct from `agent.version` ('semantic version of the agent, NOT of this spec', L103). §16 (L251) also lists media-type 'Optional parameters: version'.

**Required:** `name` (Unicode string, unique within the issuing vendor namespace)

No display-name field in the spec text.

`id` (globally unique identifier — DID, URI, or vendor-scoped UUID)

Same schemes as v0.1. §15 (L242): multiple .fafa documents per scope 'distinguished by `agent.id`'. §18 defers 'Multiple simultaneous identifier schemes for `agent.id`' (L283). v0.1's 'Validate `agent.id` against known identifier schemes' MUST is no longer present.

It does not define discovery, transport, authorization, or orchestration.

Explicitly out of scope: 'It defines the **document** those mechanisms carry, reference, and resolve.' §15 (L241) names a standard filename `agent.fafa` (alongside `project.faf` at the project layer). That is a file convention, not a discovery path.

(registered 2026-06-26, last updated 2026-06-26)

From the IANA record, not the spec text; every other value is carried over unchanged from v1.0 stable (canonical repo).

A `.fafa` file is a single YAML document:

§13 (L215): '`.fafa` is YAML 1.2 / RFC 9512 compliant.'

**Optional top-level fields:** `attachment`, `provenance`, `signature`, `metadata` (free-form vendor extensions).

§13 (L218): consumers MUST treat unknown top-level fields, and unknown subfields within agent/capabilities/endpoints, as forward-compatible extensions.

Where present, `signature` carries provenance/integrity material; verification is the consumer's responsibility.

Same `signature` block (`method`, `value`; L86–88). Same line: 'The format does not itself provide cryptographic services.' §18 defers '`signature` as an array (multiple signers)' (L284) and content-addressed provenance (L287).

The top-level `version` field declares which version of this specification the document conforms to.

Distinct from `agent.version` ('semantic version of the agent, NOT of this spec', L103). §16 (L251) also lists media-type 'Optional parameters: version'.

**Required:** `name` (Unicode string, unique within the issuing vendor namespace)

The spec text still has no display-name field. The companion schema schemas/fafa.schema.json documents an optional `agent.displayName` from 9e79b6914b6cb0ef6df299e52de17ccc47657a5e (2026-07-05), and FAFA's published card uses it (agent.fafa L9). See notes.

`id` (globally unique identifier — DID, URI, or vendor-scoped UUID)

Practice: FAFA's card uses `id: did:web:faf.one:agent`.

It does not define discovery, transport, authorization, or orchestration.

Spec unchanged. Practice only (not in spec): faf.one serves FAFA's card at /.well-known/fafa with Content-Type application/vnd.fafa+yaml (checked 2026-09-15). The one well-known URI request filed is for /.well-known/faf (protocol-registries/well-known-uris#97, open, labels 'new registration' and 'waiting for stable reference'). No request covers /.well-known/fafa.

(registered 2026-06-26, last updated 2026-06-26)

Spec at this SHA: L5 '**MIME Type:** `application/vnd.fafa+yaml`', L7 '**IANA Registration:** Registered 2026-06-26 (vendor tree)' (https://github.com/Wolfe-Jam/faf/blob/190c3380847c022da3e13a28af57c4dc68b3e02c/AGENT-FORMAT.md#L7). The IANA record's 'Published specification' is https://github.com/Wolfe-Jam/faf/blob/main/AGENT-FORMAT.md.

A `.fafa` file is a single YAML document:

§13 (L216): YAML 1.2 / RFC 9512.

**Optional top-level fields:** `attachment`, `provenance`, `signature`, `metadata` (free-form vendor extensions).

§13 (L219): forward-compat rule for unknown top-level fields and unknown agent/capabilities/endpoints subfields. It does not name `provenance` subfields.

Where present, `signature` carries provenance/integrity material; verification is the consumer's responsibility.

Unchanged. FAFA's published card carries no `signature` block.

The top-level `version` field declares which version of this specification the document conforms to.

Spec §16 (L252) lists 'Optional parameters: version', but the IANA record says 'Optional parameters: N/A' and 'versioning is handled in-band via the top-level "version" field'.