Multi Round-Trip Requests Track: Brief

[markdroth]

Add the "Multi Round-Trip Requests" track briefing doc to the repo.

Note that there was some previous discussion in the original location.

[scottslewis]

Hi Mark.

I'm sorry...I did not know about this track until just now.

Just to let you know...there is a proposal on adding Groups to the protocol (i.e. groups of Tools, Prompts, Resources), and the current proposal has IMO problems associated with required number of round trips.

I understand that this is not exactly the same notion of round trips, but I do think it's relevant, because of the fact that Group names are essentially opaque references to other primitives...that has to be retrieved, updated and maintained.

As an alternative, I have proposed allowing and supporting efficient serializing/validation of references via json pointer spec. I believe that this could also help with the update notifications...as an object graph (of changes since last sent notification) could be provided without major changes to the protocol (addition of optional fields).

[markdroth]

@scottslewis This approach isn't introducing any new opaque name that would need to be cross-referenced with anything else. So if I understand your concern correctly, I don't think that will be an issue here.

[scottslewis]

@scottslewis This approach isn't introducing any new opaque name that would need to be cross-referenced with anything else. So if I understand your concern correctly, I don't think that will be an issue here.

I wasn't very clear...apologies. What I was thinking was that mcp update notifications could be enhanced to add a server-provided 'event/changelist'...represented as an object graph as data in the update notification (e.g. for Tools, Resources, Prompts)...that clients could use to update their local replica of TRG meta-data...rather than initiate additional round trips (e.g. ListToolsRequest/Result) to get updates.

FWIW, etcd3 service has a similar approach for a key-value store...basically a client sets up a 'watch' for set of keys, and notifications are sent by etcd3 server on key value create/delete/update...with essentially a 'here's the state that changed since last notification' list of Events (an object graph). Clients then take that change list and apply the changes to the local copy of their kv store to stay in sync with server (persistent and primary copy).

With FIFO delivery order guarantees and fail-stop, state updates can be (eventually) synchronized across server to all clients via notifications/watches.

[CaitieM20]

@markdroth can we close this one since we now have SEP-XXXX: Multi Round-Trip Requests

[markdroth]

This PR is the track brief, which I think we still want to merge.

I will close #7 as a duplicate of #12, though.

[markdroth]

@scottslewis Sorry, I just noticed I never replied to your last comment here.

The kind of notification mechanism you're describing is definitely on the transport WG roadmap, but it's not part of the MRTR track. That's going to be handled as part of the Caching and Optimization track, which we will turn our attention to later this year, probably after the mid-year MCP spec release. (We currently have our hands full trying to land changes for the MRTR track (this PR), the sessions track (#3), and the HTTP Standardization Track before the mid-year MCP spec release.)