feat: add 2026-03-18 weekly meeting notes (#29)

meetings/2026-03-18_weekly.md

@@ -0,0 +1,78 @@
+# 2026-03-18 Transports WG (Weekly)
+
+## TL;DR
+The meeting began with a discussion on the acceptable level of breaking changes
+for the Multi-Round Trip Request (MRTR) approach, focusing heavily on SDK
+backwards compatibility and the upgrade path for existing servers. The second
+half of the meeting was dedicated to a fierce debate on the necessity of Data
+Layer Sessions. Two opposing views emerged: one advocating for formal session
+creation/deletion methods, and another proposing the complete omission of
+sessions in favor of MRTR and model-managed identifiers. The lack of consensus
+on the core purpose and lifetime of a session led to a challenge for attendees
+to present compelling, non-transport-related use cases for sessions before a
+final vote next week.
+
+## Detailed Summary
+
+### Client Changes & SDK Backwards Compatibility (MRTR)
+* **The Upgrade Story:** Felix Weinberger (representing the SDK team) raised
+  concerns about how SDKs are supposed to maintain backwards compatibility when
+  servers upgrade to the new MRTR flow. He stressed that SDKs cannot magically
+  solve compatibility issues if the protocol introduces a breaking change.
+* **The "Bottom-Left Quadrant" Problem:** The group discussed a scenario where a
+  newly built server (supporting the new horizontally scaled MRTR flow)
+  interacts with an older client that only supports the previous SSE-based
+  elicitation flow. Mark Roth argued this scenario doesn't matter because it
+  represents a stateful routing case that currently doesn't work anyway. Felix
+  Weinberger countered that the spec must explicitly state that this scenario is
+  unsupported (i.e., the server simply ignores the old client's elicitation
+  request) to prevent unexpected outcomes.
+* **Dual APIs vs. Compatibility Shim:** To support clients interacting with both
+  old and new servers, the group debated two paths. Mark Roth strongly preferred
+  building a compatibility shim in the SDK so existing code continues to work.
+  Simon Russell and others argued that a "magic solution" is too complex,
+  suggesting the SDK should instead offer two distinct APIs (one for the old
+  flow, one for the new flow) forcing developers to handle the integration
+  explicitly.
+* **Next Steps for MRTR:** Caitie McCaffrey will draft a problem statement
+  outlining the options for bridging the API gap. She will meet with the SDK
+  maintainers on Friday to whiteboard the client/server decisions and SDK API
+  changes.
+
+### The Great Sessions Debate
+* **The Pro-Sessions Stance:** Shaun Smith presented a proposal to add explicit
+  `session create` and `session delete` methods, along with a `session required`
+  error. In this model, the server generates a Session ID, and the client echoes
+  it back with every request, allowing the server to correlate tasks and
+  maintain opaque application state (e.g., a sandbox environment). Jordan
+  Zimmerman supported this, noting HTTP's 30-year precedent of using cookies for
+  similar handle-based correlation.
+* **The Anti-Sessions Stance:** Peter Alexander argued that with the upcoming
+  stateless MRTR changes, the historical reasons for sessions (capabilities,
+  subscriptions, multi-turn flows) are gone. For application state (like a
+  shopping cart), he proposed that the model should call a tool (e.g.,
+  `create_basket`), receive an ID, and pass that ID into subsequent tool calls.
+  This removes the overhead of session lifecycle management and allows for
+  greater flexibility, such as sharing a state object across multiple
+  sub-agents.
+* **The Core Disagreement:** Geoff Goodman highlighted that the primary issue
+  with sessions is the lack of consensus on session lifetime between the client
+  and server. Mark Roth noted that after six months, there is still no agreement
+  on what sessions are actually for, which heavily favors Peter Alexander's
+  proposal to omit them entirely to avoid cementing a flawed feature into the
+  protocol. Stephen Halter pushed back, arguing that removing the feature breaks
+  existing, working scenarios (like VS Code refreshing).
+* **Next Steps for Sessions:** Kurtis Van Gent challenged the group to bring
+  concrete, non-transport-related use cases for sessions to the next meeting.
+
+## Action Items
+- [ ] **Caitie McCaffrey** to write up a problem statement with options for
+  bridging the gap between the current and future SDK APIs.
+- [ ] **Caitie McCaffrey, Stephen Halter, Max Isbey, Felix Weinberger, and Mark
+  Roth** to meet on Friday to whiteboard and mock up options for SDK API
+  changes.
+- [ ] **Kurtis Van Gent** to reserve 30 minutes at the start of next week's
+  meeting to definitively tackle the problem of sessions.
+- [ ] **All** to review their use cases and verify if
+  sessions are still required assuming MRTR and task correlation issues are
+  fixed.