From 7a8ed04ad6987a614a07d1c6858d9edb57c3cf5c Mon Sep 17 00:00:00 2001
From: Kurtis Van Gent <31518063+kurtisvg@users.noreply.github.com>
Date: Mon, 23 Feb 2026 15:31:09 -0700
Subject: [PATCH] feat: add 2026-02-04 weekly meeting notes (#14)

---
 meetings/2026-02-04_weekly.md | 74 +++++++++++++++++++++++++++++++++++
 1 file changed, 74 insertions(+)
 create mode 100644 meetings/2026-02-04_weekly.md

diff --git a/meetings/2026-02-04_weekly.md b/meetings/2026-02-04_weekly.md
new file mode 100644
index 0000000..f5d8661
--- /dev/null
+++ b/meetings/2026-02-04_weekly.md
@@ -0,0 +1,74 @@
+# 2026-02-04 Transports WG (Weekly)
+
+## TL;DR
+The group focused on finalizing the Multi-Round Trip Request (MRTR) proposal to
+prepare it for submission as a public Specification Enhancement Proposal (SEP).
+Mark Roth led the review of the drafted SEP, clarifying the distinction between
+ephemeral (stateless) and persistent (stateful/tasks) workflows. A key technical
+debate centered on data structures for dependent requests (Map vs. Array) and
+the role of server-side state. The group achieved consensus to keep the "State"
+mechanism (related to proposal 1685) as a separate but parallel SEP to keep the
+MRTR proposal focused. Additionally, the group identified a missing method name
+in the persistent task workflow and agreed to define a specific method (e.g.,
+`tasks/provide_input`) to handle client responses. The meeting concluded with an
+agreement to push the MRTR proposal to a public SEP after incorporating the
+discussed tweaks.
+
+## Detailed Summary
+
+### MRTR Proposal: Ephemeral vs. Persistent Workflows
+* **Clarification of Scope:** Mark Roth presented the updated SEP,
+  distinguishing between "ephemeral tool workflows" (independent requests, no
+  server state) and "persistent tool workflows" (requiring server-side
+  state/Tasks).
+* **State Accumulation:** Caitie McCaffrey and Mark Roth discussed refining the
+  document to focus on message patterns rather than over-defining server-side
+  state storage, ensuring the spec describes *how* messages flow rather than
+  *why* a server might store state.
+* **Schema Updates:** The group proposed adding a new `incomplete response` type
+  to the JSON-RPC response schema. This allows any node to return a response
+  indicating that more information (dependent requests) is needed to complete
+  the operation.
+
+### Technical Decisions: Data Structures and Keys
+* **Map vs. Array:** A significant debate occurred regarding the structure of
+  dependent requests. Mark Roth advocated for a Map (using keys) to allow
+  servers to safely associate responses with requests during rolling upgrades or
+  restarts.
+* **Key Generation:** Gabriel Zimmerman and Mike Kistler debated the complexity
+  of generating these keys. The group discussed whether the server needs to see
+  the full original request to validate the response or if a key/hash is
+  sufficient.
+* **Decision:** The group leaned towards allowing the server to use keys for
+  association, noting that if full request context is needed, it can be handled
+  via the separate State mechanism.
+
+### State Mechanism (Proposal 1685)
+* **Separation of Concerns:** The group agreed to separate the "State" mechanism
+  (passing opaque blobs/tokens back and forth, similar to HTTP cookies or hidden
+  fields) into its own SEP (referencing proposal 1685).
+* **Parallel Tracking:** While separate, both SEPs (MRTR and State) will be
+  tracked and moved through the process together to ensure they work seamlessly,
+  as State is often necessary for complex multi-round trip scenarios.
+* **Security:** Simon Russell suggested encouraging the use of strings for state
+  so they can be signed by the server to prevent client tampering.
+
+### Persistent Workflow (Tasks)
+* **Missing Method Name:** The group identified a gap in the persistent workflow
+  where the client sends task results back to the server (Step 7). Currently,
+  this step lacks a defined JSON-RPC method.
+* **Naming Proposals:** Mark Roth and Caitie McCaffrey discussed potential names
+  like `tasks/provide_input` or `tasks/provide_dependent_results`. They agreed
+  to select a name to ensure proper routing and logging, treating the "Input
+  Required" state as a form of recoverable error.
+* **Next Steps:** The group agreed to move forward with the MRTR proposal as a
+  public SEP, with the persistent workflow requiring a specific method name for
+  the client response.
+
+## Action Items
+- [ ] **Mark Roth** and **Caitie McCaffrey** to incorporate the agreed-upon
+  tweaks (including the method name for tasks) and push the proposal to a public
+  SEP.
+- [ ] @gjz22 is going to present discussion around SEP-1685
+- [ ] **Caitie McCaffrey** had requested that we try to check in on the other
+  in-flight SEPs
\ No newline at end of file