I think this is a great move, biggest question I had is whether we should align the JSON-RPC methods and the gRPC method names, for example instead of message/send and message/stream use "SendMessage" and "SendStreamingMessage" etc. This way the JSON-RPC essentially implements the proto service.

Ultimately, I wonder if the service and method definitions in the proto should be the source of truth for the method names and inputs and output for all transports. HTTP+REST can use AIP-127 to transcode those functions.

Another question was about the filtering/pagination params for methods like GetTasks. I feel like this can be defined in the spec generically and not tied specifically to the transport implementation. i.e. can I filter the list based on a Task's status field shouldn't change based on gRPC vs REST, even if the transports put the fields in different places (body vs query params for example)

I like a lot the idea - this opens the way for other transports like stdio, unix socket etc.

One comment/question I have, is to add the option to to encode additional parameters which are necessary
for a certain transport. In particular, the URL only may not be sufficient/handy to encode all the information,
as described in #1074 for stdio:

Specifying configuration to the running process as described can be cumbersome. It involves encoding all configuration in a string, rather than allowing structured env and args configuration, which is how most tooling integrates this.
Unfortunately, we don’t have a great place for putting an env or args field in the AgentCard in relation to the transport. We could augment this proposal to support transport-specific arguments. That could be useful beyond this case, such as for gRPC servers that that use custom channel configuration.

As follow up for this proposal, we could define a "transport_config" field in the AgentCard (and in the AgentInterface) that would allow to specify these parameters in a structured way.

A way I can think of is using a oneof construct with all the standard transport configuration and a final google.protobuf.Struct allowing extension to custom transports:

message TransportConfig {
  oneof {
    GrpcConfiguration grpc = 1;
    StdioConfiguration srdio = 2;
    JsonRpcConfiguration jsonrpc = 3;
    ...
    google.protobuf.Struct custom_transport = N;
  }
}

@Tehsmash I think as long as their is an explicit mapping I think we can have the most natural experience using each "transport". I don't think we should mash one transport's conventions into another. This is only a mapping that SDK devs will really need to deal with, so I don't think it affects a lot of people.

Regarding the pagination, I need to look closer at that. I agree that it should be defined generically and then mapped to transports.

@msardara This effort is the first step towards providing explicit guidance on how communicate all parameters even for those transports that don't have access to things like query parameters and HTTP headers. We want to define all features in a transport agnostic way.

@darrelmiller great point, I don't think we should enforce it as long as there is a mapping.

The reason for my suggestion was to allow for the a2a.proto service definitions to be the source of truth for the "A2A Protocol Operations" section of the spec in the same way the a2a.proto is for the types. Essentially using the a2a.proto as a formal language definition of that section of the spec.

I think if we went that way it would be "best practise" to use the names from the a2a.proto service method definitions unless it is a convention or required by the transport to do something else like in the HTTP transport.

In JSON-RPC it doesn't seem to be a convention to format the method as something like "messages/send", and the method is just a string in the JSON-RPC wrapper so could match "SendMessage" etc.

If the core transports stick the best practise, then it sets a precedent for other transports to do the same. Ideally, using code generation from the a2a.proto to create the functions that implement the transports methods (protoc compiler to JSON-RPC server).

Separate from this point: I realised don't see a section in the spec describing the fields which are currently carried in the metadata or headers for each transport, like the enabled extensions. Maybe we can start by just listing these fields, then work out if we can encode them into the a2a.proto methods somehow like extra fields in "SendMessageRequest" so that we can handle them in a more standard way.

I really like this idea. There were a lot of discrepancies that came up for gRPC vs. JSON-RPC so I think this will help to avoid that type of thing going forward.

@Tehsmash

In JSON-RPC it doesn't seem to be a convention to format the method as something like "messages/send", and the method is just a string in the JSON-RPC wrapper so could match "SendMessage" etc.

This is good callout. It seems like the "messages/send" convention is aligning with MCP rather than anything specific to JSON RPC.

Separate from this point: I realised don't see a section in the spec describing the fields which are currently carried in the metadata or headers for each transport, like the enabled extensions.

Yep. I'm sure there are a fair number of things missing. I didn't want to invest too much time in cleaning this up before I got consensus that it is a direction we wanted to go in.

@holtskinner All the checks are passing now and I think I fixed the issue with the proto definitions snippets not appearing in the document.

Are there still things that are concerning you about the doc generation that would warrant splitting the PR? I'm ok with doing the split, I just want to better understand your concerns.

@holtskinner All the checks are passing now and I think I fixed the issue with the proto definitions snippets not appearing in the document.

Are there still things that are concerning you about the doc generation that would warrant splitting the PR? I'm ok with doing the split, I just want to better understand your concerns.

Main concern is this #1160 (comment)

And I want to unblock the other updates to the spec, which don't necessarily require the JSON to be generated from the Proto

@holtskinner Sorry, I didn't see that. The a2a.json will not match because of enums. We decided as of Wednesday to attempt to move forward using a ProtoJSON mapping, which means SCREAMING_SNAKE_CASE enums instead of camelCase.
The file not found problem definitely is a bigger deal.
I will try and split out the PR as you suggest. But it will be a couple of hours as I have to disappear for a bit.

@holtskinner After a conversation with @muscariello we concluded that the plan is to merge this PR as is. The Python SDK generation is no longer triggered from changes to main as it is now connected to a tag. The issue you are seeing with generating Pydantic types from a2a.json is expected. There is ongoing work to resolve this.

We think we know what we are doing :-) So, I'm going to merge this PR.