Is your feature request related to a problem? Please describe.

Current AgentCard.protocolVersion field is a string and there's no clear way for servers to easily advertise support of multiple protocol versions.
This might become a problem in environments where we don't have control over client updates. Adopting a new protocol version might mean loosing compatibility with older clients.

Describe the solution you'd like

Extend AgentInterface

Make protocolVersions a part of AgentInterface.

additionalInterfaces?: AgentInterface[];
...
export interface AgentInterface {
  url: string;
  transport: TransportProtocol | string;
+ protocolVersions?: string[];
}

The structure was used for transport negotiation and this seems to extend naturally into "transport+protocol version negotiation".

A tuple (URL, PrefferedTransport) in the root + additional (url, transport) pairs
also extend into
(URL, PreferredTransport, protocolVersion) in the root + additional (url, transport, versions)
For better consistency we might want to keep protocolVersion singular, but this introduces redundancy if a server wants to support multiple versions on the same endpoint.

If we make protocolVersions an optional field and treat its absence as "supports only the interface specified in the protocolVersion on the root level" all existing AgentCards stay compatible with the new format.

Communicate the version

Define a header like X-A2A-Version that a client must pass when trying to connect to an interface which supports multiple versions. The server must reject requests / connection if a version is not provided.

Describe alternatives you've considered

Root-level field changes

Considered different variations like:

Adding a new field with a different name:

  "protocolVersion": "0.4.0",
+ "supportedVersions": ["0.4.0", "1.0.0"],

Adding a new field with a similar name:

  "protocolVersion": "0.4.0",
+ "protocolVersions": ["0.4.0", "1.0.0"],

Changing the existing field:

- "protocolVersion": "0.4.0",
+ "protocolVersion": ["0.4.0", "1.0.0"],

The first two version introduce new field coupling semantics to the type (do they need to be in sync, which should take preference etc.).
The third version breaks compatibility for all the existing cards.
All these variations provide less flexibility than AgentInterface extension because we can't serve older version on different endpoint.

Subdomain-based versioning

For example, https://v1.myagent.com supports 0.0.4 and https://v2.myagent.com supports 1.0.0.
Pros: no protocol changes needed, allows running completely different server implementations.
Cons: requires extra infrastructure setup (multiple deployments, DNS management) and seems better suited for agent versioning.

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct