feat: add 2026-07-15 weekly meeting notes (#48)

meetings/2026-07-15_weekly.md

@@ -0,0 +1,156 @@
+# 2026-07-15 MCP: Transport Working Group (Weekly)
+
+## TL;DR
+The MCP: Transport Working Group conducted a smaller weekly meeting to review
+administrative updates, discuss Gabriel Zimmerman's capabilities Specification
+Enhancement Proposal (SEP), map out key design questions and use cases for
+reintroducing sessions, and establish future workshop topics. While the team
+aligned on prioritizing a comprehensive justification for session reintroduction
+and formally evaluating the trade-offs between transport mechanisms to resolve
+architectural and security concerns, they debated client-side versus server-side
+filtering, state handles versus session IDs for concurrency, and the security of
+localhost HTTP transport versus running HTTP/2 over standard I/O. The overall
+vibe was collaborative yet cautious, with members acknowledging that a stronger,
+more bulletproof case is needed before proposing sessions back to the core
+maintainers.
+
+## Detailed Summary
+
+### Administrative and Meeting Scheduling
+* **Attendance Updates:** The working group noted a smaller attendance for the
+  current session. Summer vacations and other obligations have reduced turnout.
+  Kurtis Van Gent noted that Katie McCaffrey appears to have completed her
+  contributions now that her stateless session logic is merged, though she may
+  return for topics of interest. Additionally, Gabriel Zimmerman shared that
+  Mike Kistler has retired from his role.
+* **Scheduling Form Reminder:** Kurtis reminded attendees to complete the
+  meeting time preference form by Friday so the group can reschedule. While
+  three people completed it at the last minute, everyone else is urged to submit
+  their preferences or accept whatever time is chosen.
+
+### Client Capabilities and Server Filtering
+* **Tool Execution Failures:** Gabriel Zimmerman raised the problem of tool
+  execution failures occurring when an LLM attempts to call a tool that is not
+  supported by the client.
+* **Extensions and Capabilities Filtering:** Gabriel proposed that servers
+  return required extensions and capabilities so clients can filter out
+  unsupported tools before execution. Stephen Halter noted that this problem
+  also exists for tasks, referencing how the SDK previously handled "tool
+  execution" before it was simplified out.
+* **Client-Side vs. Server-Side Filtering:** Kurtis Van Gent questioned why this
+  filtering cannot be handled entirely on the server side, which is the current
+  recommended pattern. Gabriel explained that server-side filtering is
+  complicated by the "cache key issue" where varying capabilities in different
+  client execution environments can lead to a "weird cache key" when caching
+  tools.
+* **Caching and TTL Guidance:** Kurtis suggested that rather than introducing
+  complex client-side capabilities, the protocol could simply update the TTL
+  mechanism with clear guidance on what invalidates a cache key and forces the
+  client to fetch a new list of tools. Gabriel Zimmerman agreed to update his
+  Specification Enhancement Proposal (SEP) to represent both server-side and
+  client-side options and detail specific caching invalidation rules.
+
+### Reintroducing Stateful Sessions: Core Challenges
+* **The Session ID Conflict:** Kurtis Van Gent explained that the previous
+  session implementation failed because the session ID was overloaded for both
+  transport-level bookkeeping and application state, breaking user expectations
+  and leading to its removal from the protocol.
+* **Design Open Questions:** Kurtis presented several design challenges that
+  must be addressed to construct a compelling proposal for the core maintainers:
+* *Naming:* "Session" is overloaded; alternatives like "thread ID",
+  "conversation ID", or "context ID" should be evaluated.
+* *ID Generation:* Debating the pros and cons of client-generated versus
+  server-minted IDs. Stephen Halter strongly advocated for server-side minting,
+  arguing that client-generated IDs limit utility, make requests easy to forge,
+  and remove trusted values.
+* *Lifecycle:* Clarifying how sessions are created, when they are cleaned up,
+  and their relation to standard I/O process lifetime.
+* *Scope of Impact:* Determining whether a session can alter the tools list,
+  tool call outputs, resources, or prompts.
+* *Concurrency:* Managing parallel requests and sub-agent behaviors (e.g.,
+  whether sub-agents get unique IDs or reuse parent session IDs).
+* *Optionality:* Deciding if sessions are strictly opt-in and how to handle
+  clients that do not support them.
+- **State Handles vs. Session IDs:** Gabriel Zimmerman raised a concern from a
+  Microsoft engineer regarding the determinism of state handles (e.g., shopping
+  carts) and whether harnesses can guarantee they are correctly passed through
+  downstream workflows. Stephen Halter agreed that while higher-level state
+  handles are useful for shopping carts, session IDs are essential for
+  environments like LLM competitions where the harness must prevent cheating by
+  remaining in control.
+
+### Session Use Cases and Alternatives
+- **Infrastructure Routing and Instance Affinity:** The group discussed the
+  necessity of routing session calls consistently to a specific microVM.
+* *Option A (Client-provided Headers):* Middleware handles routing via a
+  client-provided header. Kurtis and Luca Chang noted the downside: there is no
+  standard header name, meaning arbitrary clients cannot connect to arbitrary
+  servers dynamically.
+* *Option B (Server State Handles):* Initializing a conversation returns a state
+  handle used for downstream routing. Luca Chang strongly opposed this, stating
+  that gateways would have to rewrite upstream tools to add handle parameters,
+  which would conflict with servers managing explicit state handles. Stephen
+  Halter added that no generic session-aware gateway exists to support this.
+- **Observability and Auditing:** Tracking the order and metrics of tool calls.
+* *Option A (Non-MCP Tracing):* Cloud Code or other harnesses pass a
+  conversation ID header for tracking.
+* *Option B (Resource-based Indexing):* Indexing audit logs at the resource
+  level itself (e.g., Cloud SQL instances). Luca Chang noted that a gateway
+  cannot extract telemetry automatically because it does not know the semantics
+  of specific tools, whereas the server can emit this natively.
+* *Cookie Jar Mechanism:* Gabriel Zimmerman suggested echoing a metadata field
+  back and forth. Kurtis noted this was previously rejected for protocol
+  complexity.
+- **Progressive Discovery of Tools:** Kurtis suggested that discovering tools
+  through skills activation (`skills:activate`) is a viable path because models
+  are already trained to utilize skills. Stephen Halter questioned if this would
+  replace or merely supplement the standard tools list.
+- **Multi-step Stateful Workflows:** For workflows like counters, the group
+  agreed that state handles are a cleaner and more appropriate solution than
+  sessions.
+
+### Future Workshop Topics and Transport Security
+- **Upcoming Topics:** Kurtis outlined a typed list of future topics: pluggable
+  transports (e.g., gRPC support), tool versioning, HTTP over standard I/O,
+  internationalization, and content type support.
+- **HTTP over Standard I/O:** Andreas Schlapbach and Stephen Halter discussed
+  running HTTP/1.1 or HTTP/2 over local standard I/O streams to align local and
+  remote transport behaviors. Stephen noted that multiplexing for parallelism
+  would make HTTP/2 a strong choice.
+- **Security Risks of HTTP Transports:** Kurtis expressed security concerns
+  regarding localhost HTTP, specifically DNS rebinding risks and the lack of
+  encryption when token verification is used. Luca Chang suggested that
+  applications could pass an unguessable token to the subprocess to verify
+  requests, but Kurtis countered that localhost HTTP remains unencrypted. The
+  group agreed on the critical need to define a comprehensive threat model
+  before evolving local transports.
+
+## Next Steps & Timeline
+- Between now and the next meeting, Kurtis Van Gent will draft comprehensive
+  briefs for the future workshop topics, including pluggable transports, tool
+  versioning, and HTTP over standard I/O.
+- All working group members are requested to fill out the meeting scheduling
+  preference form by Friday to help determine the next meeting time.
+- Once responses are collected, Kurtis will reschedule and organize the next
+  meeting.
+- Andreas Schlapbach will begin investigating standard I/O transport mechanisms.
+- Gabriel Zimmerman will update his capabilities Specification Enhancement
+  Proposal (SEP) with server-side options and caching invalidation triggers.
+
+## Action Items
+- [ ] **Gabriel Zimmerman** Update capabilities Specification Enhancement
+  Proposal (SEP) to include server-side options, clarify cache invalidation
+  rules, and address caching key/TTL feedback.
+- [ ] **Luca Chang** Review Kurtis's sessions use cases draft and comment on the
+  PR to articulate why existing middleware routing is insufficient and document
+  gateway conflict concerns.
+- [ ] **Kurtis Van Gent** Draft technical briefs for the upcoming workshop
+  topics (pluggable transports, tool versioning, internationalization, and HTTP
+  over standard I/O).
+- [ ] **Kurtis Van Gent** Reschedule and organize the next working group meeting
+  based on the scheduling form results.
+- [ ] **The group** Complete the meeting time preference form by Friday.
+- [ ] **The group** Review the reintroducing sessions proposal and identify
+  potential gaps or solutions to strengthen the case for core maintainers.
+- [ ] **Andreas Schlapbach** Investigate the feasibility and security
+  implications of standard input/output as a transport mechanism.