From ad8a5d35ddfe6ee1854a3ac108a7c943e13655ab Mon Sep 17 00:00:00 2001 From: Kurtis Van Gent <31518063+kurtisvg@users.noreply.github.com> Date: Mon, 16 Mar 2026 16:21:15 -0600 Subject: [PATCH] feat: add 2026-03-04 weekly meeting notes (#23) --- meetings/2026-03-04_weekly.md | 102 ++++++++++++++++++++++++++++++++++ 1 file changed, 102 insertions(+) create mode 100644 meetings/2026-03-04_weekly.md diff --git a/meetings/2026-03-04_weekly.md b/meetings/2026-03-04_weekly.md new file mode 100644 index 0000000..4ba8d31 --- /dev/null +++ b/meetings/2026-03-04_weekly.md @@ -0,0 +1,102 @@ +# 2026-03-04 Transports WG (Weekly) + +## TL;DR +The meeting, facilitated by Kurtis Van Gent and Mark Roth, focused on finalizing +imminent Specification Enhancement Proposals (SEPs) and discussing new protocol +extensions. The core maintainers reviewed SEP 2322 (MRTR) positively, agreeing +to accept SDK breaking changes in favor of the new stateless flow. SEP 2243 +(HTTP Standardization) is undergoing a final revote after consolidating header +names and softening intermediary error handling. Significant debate occurred +regarding the Data Layer Sessions proposal, resulting in a mandate to explicitly +define targeted use cases before further design review. Andreas Schlapbach +introduced a new content negotiation proposal for compact responses to support +local LLMs with small context windows. Finally, the group reviewed remaining +gaps for the June release.w + +## Detailed Summary + +### Process & Roadmap +* **June Release Gaps:** Kurtis Van Gent identified two main gaps for the + upcoming specification release: pluggable transports and caching/optimization. +* **Pluggable Transports:** Mark Roth clarified that pluggable transports mostly + require SDK work, not SEP changes. Minor cosmetic updates to loosen the + JSON-RPC requirement might be needed. Stephen Halter emphasized the need to + ensure the transport abstraction still allows for JSON-RPC to support existing + proxy implementations. +* **Caching & Standard IO:** Caching and optimization lack volunteers and will + likely be deferred until after the June release. Standard IO updates are also + firmly out of scope for the current revision. + +### Technical Decisions: MRTR & Tasks (SEP 2322) +* **Core Maintainer Feedback:** Mark Roth reported that the core maintainers + gave positive feedback on the Ephemeral Multi-Round Trip Request (MRTR) SEP. + Minor schema changes were added to help SDKs discriminate between tool call + responses and incomplete responses. +* **URL-Based Elicitation:** The group agreed that the URL-based elicitation + workflow is incompatible with the ephemeral workflow and will be restricted to + the persistent (tasks) workflow. +* **Backward Compatibility:** The consensus was to accept breaking changes in + the SDKs to implement the new MRTR flow, deferring backward compatibility + concerns unless significant user complaints arise. +* **Task Integration:** Luca Chang confirmed that their task-related proposals + (including "jump scares" and "task continue") are inextricably tied to MRTR + and will be pursued under the Transports Working Group. + +### Technical Decisions: HTTP Standardization (SEP 2243) +* **Proposal Updates:** Mike Kistler outlined recent changes to the SEP, which + is up for a revote. Header names (`tool name`, `resource name`, `prompt name`) + were consolidated into a single `MCP name` header. The payload encoding was + explicitly specified as the Base64 encoding of the UTF-8 value. +* **Intermediary Handling:** The requirement for intermediaries was softened so + that if they reject a request based solely on header values (e.g., bad + encoding), they can return a standard `400` HTTP error instead of a JSON-RPC + error. Stephen Halter noted that a `404` should be explicitly avoided to + prevent ending the session. +* **Header Limits:** Following a discussion initiated by Stephen Halter about + protocol limits, the group agreed to remove strict protocol-level limits on + header lengths. These limits will be replaced with a design note advising + application authors against promoting overly long parameters to headers. + +### Technical Decisions: Data Layer Sessions +* **Defining Use Cases:** Mark Roth strongly emphasized that the sessions SEP + cannot proceed without a concrete list of targeted use cases. Scenarios like + "session per tool call" are mutually exclusive with "retaining state across + tool calls". +* **Scope of State:** Shaun Smith argued that sessions should manage opaque, + application-layer state (e.g., associating a chat thread with a sandbox) + rather than MCP protocol state. Peter Alexander challenged this, asking if the + LLM model should be in control of the session state instead of the + application. +* **Concurrency:** Stephen Halter raised concerns about state synchronization + during parallel tool calls. Shaun Smith clarified that the proposal currently + uses a "last write wins" strategy to intentionally discourage high-stakes + strict ordering, advising it be used for low-stakes storage. +* **Next Steps:** The group agreed to hold a special session next week to review + an updated document focused on use cases and design, which will inform a final + recommendation to the core maintainers (including the potential recommendation + to drop sessions entirely). + +### Proposals: Content Negotiation +* **Compact Responses:** Andreas Schlapbach proposed a two-phase content + negotiation extension (similar to HTTP `Accept`) allowing clients with small + context windows (like local LLMs on mobile devices) to request "compact" + responses from servers. +* **Protocol vs. Application Layer:** Simon Russell and Kurtis Van Gent + questioned why this negotiation needs to live at the protocol layer instead of + just passing expressive parameters within individual tool calls. Andreas + argued that an upfront session-level negotiation reduces chattiness and + compute waste. Andreas will continue to refine the proposal and gather + feedback in the repository. + +## Action Items +- [ ] **Shaun Smith** to update the Sessions document by Friday/Saturday, + focusing on defining use cases and the argument for keeping sessions at the + application layer rather than the model layer. +- [ ] **Shaun Smith** to check availability for a special session next Tuesday + or Friday to discuss the updated session document. +- [ ] **Shaun Smith & Kurtis Van Gent** to work together to ensure the Sessions + SEP explicitly outlines the context for application versus transport sessions. +- [ ] **Mike Kistler** to update SEP 2243 to replace the strict limits on header + lengths with an implementation note/design guidance. +- [ ] **Kurtis Van Gent** to follow up with Kryspin and Stephen Halter to + formulate a formal proposal/plan for pluggable transports. \ No newline at end of file