diff --git a/meetings/2026-02-11_weekly.md b/meetings/2026-02-11_weekly.md new file mode 100644 index 0000000..72cb5e0 --- /dev/null +++ b/meetings/2026-02-11_weekly.md @@ -0,0 +1,77 @@ +# 2026-02-11 Transports WG (Weekly) + +## TL;DR +The meeting, facilitated by Mark Roth, focused on reviewing three in-flight +Specification Enhancement Proposals (SEPs) to prepare them for the core +maintainers. The group approved Shaun Smith's SEP to disallow unsolicited +server-to-client requests, pending a clear definition of "associated" requests. +Mike Kistler's HTTP Standardization SEP was also approved with modifications, +specifically making schema validation optional for custom parameters on +intermediate servers. Lastly, Luca Chang's Task Progress SEP faced pushback +regarding the deprecation of SSE progress notifications; the group agreed to +amend the SEP to add progress capabilities to tasks without removing the +existing SSE mechanism, but will review the revised proposal again next week +before advancing it. + +## Detailed Summary + +### Process & General Updates +* **Facilitation:** Mark Roth facilitated the meeting as Kurtis Van Gent was + driving. +* **Agent Contexts:** Kryspin Ziemski briefly shared concepts for agents + utilizing dynamic resources and stateful code modes to predict cause and + effect. +* **MRTR Next Steps:** Mark Roth will meet with Caitie McCaffrey and Gabriel + Zimmerman on Friday to resolve open questions on the Multi-Round Trip Request + (MRTR) proposal. + +### Technical Decisions: Sampling & Elicitation SEP +* **Scope & Ambiguity:** Shaun Smith presented an SEP to clarify that + server-initiated requests (like sampling and elicitation) cannot be + unsolicited. Mike Kistler clarified that this applies to *all* + server-initiated requests, not just sampling and elicitation. +* **Defining Association:** Debate arose over how to associate server requests + with client requests, especially for the standard IO transport. The group + agreed to explicitly define "associated" in the SEP, meaning the server + request must supply a matching JSON RPC request ID from the client. +* **Decision:** The SEP was approved with changes to advance to the core + maintainers. Shaun Smith will update the wording and coordinate with Mike + Kistler. + +### Technical Decisions: HTTP Standardization SEP +* **Validation Requirements:** Mike Kistler's SEP regarding HTTP headers was + reviewed. The primary debate focused on whether intermediate servers (like + load balancers) cracking the payload must validate custom headers against + schemas they might not have access to. +* **Decision:** The group agreed that if a server modifies or processes the + payload, it must validate standard parameters. However, validating custom + parameters is optional if the server lacks the schema; it can simply pass them + along. The SEP was approved with these changes, and Kurtis Van Gent agreed to + sponsor it. + +### Technical Decisions: Task Progress SEP +* **Deprecating SSE:** Luca Chang presented an SEP to move progress + notifications to the Tasks API and deprecate the current SSE-based progress + mechanism. +* **Pushback:** Significant objections came from Shaun Smith, Stephen Halter, + and Simon Russell. They argued that removing SSE progress notifications breaks + low-stakes, real-time use cases (e.g., multimodal inference, sub-agents, + streaming results) where setting up a persistent Task is too heavyweight. +* **Decision:** Mark Roth proposed modifying the SEP to *only add* progress + notifications to tasks, abandoning the removal of the old SSE mechanism for + now. Luca agreed. Caitie McCaffrey requested to review this revised proposal + next week before it goes to the core maintainers. + +## Action Items +- [ ] **Shaun Smith** to update the Sampling/Elicitation SEP with the agreed + definition of "associated", sync with Mike Kistler, and move the PR to the + main repo by Friday. +- [ ] **Mike Kistler** to address comments on the HTTP Standardization PR, + update the validation rules for custom parameters, and move the PR to the main + repo by Friday. +- [ ] **Luca Chang** to update the Task Progress SEP by Friday to only add + progress to tasks without removing the old SSE mechanism. +- [ ] **Group** to review Luca's updated Task Progress SEP asynchronously on + Monday and Tuesday. +- [ ] **Mark Roth** to add the revised Task Progress SEP and the MRTR proposal + to next week's agenda. \ No newline at end of file diff --git a/meetings/2026-02-18_weekly.md b/meetings/2026-02-18_weekly.md new file mode 100644 index 0000000..eeedfc6 --- /dev/null +++ b/meetings/2026-02-18_weekly.md @@ -0,0 +1,94 @@ +# 2026-02-18 Transports WG (Weekly) + +## TL;DR +The meeting focused on core maintainer feedback for in-flight Specification +Enhancement Proposals (SEPs) and refining the Multi-Round Trip Request (MRTR) +proposal. PR 2260 (deprecating unsolicited server requests) is expected to pass, +while PR 2243 (HTTP Headers) requires revisions to optimize header usage and +generalize custom parameters. The bulk of the session centered on MRTR, +particularly addressing SDK maintainer concerns regarding backwards +compatibility and breaking changes. The group debated using capabilities versus +protocol versioning to gracefully migrate clients to the new stateless flow. +Technical clarifications were made regarding the use of Tasks for MRTR, handling +race conditions idempotently, and generalizing the MRTR pattern beyond just tool +calls. The group reached an 80-90% consensus to advance MRTR to a formal SEP, +pending a few wording updates and a final review next week. Peter Alexander will +also engage the Python and TypeScript SDK teams to ensure smooth architectural +alignment. + +## Detailed Summary + +### Core Maintainer PR Updates +* **PR 2260 (Out-of-Context Elicitation):** Caitie McCaffrey reported that the + SEP to eliminate unsolicited server out-of-context elicitation and sampling is + expected to pass the official core maintainer vote with only minor comments to + address. +* **PR 2243 (HTTP Standardization):** Core maintainers requested more time to + review this SEP and provided three main points of feedback: + 1. **Header Optimization:** Can multiple headers be combined, or can headers + like tool names be reused for methods/resources? + 2. **Custom Parameters:** Suggestion to generalize the custom parameter + mirroring to cover *any* field in the MCP body via a key-value map, + rather than restricting it to tool parameters. + 3. **Encoding Prior Art:** Requests for prior art or examples regarding the + encoding strategy. Mike Kistler and Kurtis Van Gent will work on these + revisions. + +### MRTR: Backwards Compatibility & SDK Impact +* **Breaking Changes:** Peter Alexander relayed significant concerns from SDK + maintainers about the MRTR proposal breaking existing client code. +* **Capabilities vs. Versioning:** The group debated how to handle the + migration. Mark Roth suggested leveraging protocol versioning to eventually + deprecate the old flow. Simon Russell and Stephen Halter advocated for + capability-based negotiation so clients can opt into the new MRTR flow, + allowing servers to choose their implementation while clients support both + during the transition. +* **Migration Plan:** Caitie McCaffrey emphasized that a clear socialization and + migration plan (potentially involving a migration bot) must accompany the SEP + to help developers transition before the old flow is officially deprecated. + +### MRTR: Technical Clarifications +* **Generalizing the Pattern:** Mike Kistler pointed out that the document + leaned too heavily on tool calls. Mark Roth agreed to update the wording to + clarify that the MRTR pattern applies to *any* client-initiated request (e.g., + resources with templates), framed as a split between ephemeral/stateless + patterns and persistent/stateful patterns. +* **Progress Notifications:** Clarified that in the ephemeral flow, a server can + still send progress notifications via the SSE stream *before* it sends the + elicitation request (incomplete result) and closes the stream. +* **Encryption Examples:** Kurtis Van Gent requested clarification on encryption + requirements. Mark Roth confirmed that AESGCM and assigned JWTs are merely + illustrative examples, not mandatory requirements; servers can use other + encryption methods. +* **Load Shedding:** Simon Russell highlighted a buried feature: a server can + send an incomplete response with request state but *no* input requests, purely + for load shedding (asking the client to resume later). Mark Roth will make + this feature more prominent in the SEP. + +### MRTR: Tasks and Race Conditions +* **New Task Method:** A new API method was introduced for clients to send input + requests back to tasks. Luca Chang and Caitie McCaffrey explained that + separating this from the `tasks/get` (status) call ensures consistent + performance and better database observability for the status endpoint. +* **Handling Input Race Conditions:** Kurtis Van Gent asked how the protocol + handles multiple clients/threads submitting conflicting inputs to the same + task. Mark Roth and Caitie McCaffrey argued against adding complex "declined" + error states. Instead, the server should process inputs idempotently (e.g., + taking the first valid submission). If an input is invalid, the task simply + remains in the "input required" state. + +## Action Items +- [ ] **Mark Roth** to update the MRTR SEP wording to generalize the pattern + beyond tool calls. +- [ ] **Mark Roth** to clarify in the MRTR SEP that AESGCM and JWT are just + examples of encryption, not requirements. +- [ ] **Mark Roth** to explicitly add the new method for sending input requests + to tasks to the list of methods in the SEP. +- [ ] **Mark Roth** to elevate the visibility of the "load shedding" feature + (incomplete response with state but no input request) within the document. +- [ ] **Mark Roth** to complete all document changes before next week's meeting + for a final review. +- [ ] **Peter Alexander** to meet with the Python and TypeScript SDK maintainers + to discuss the MRTR proposal and architectural impacts. +- [ ] **Caitie McCaffrey & Group** to begin working on the necessary schema + changes to formally convert the MRTR document into a proper SEP. \ No newline at end of file