feat: add 2026-02-18 weekly meeting notes

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.

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.