transports-wg

Summary Early-stage proposal (SEP format) to sound out with the Transports WG before pursuing a core SEP. Adds a deterministic, opaque surface digest carried on the of every server result — a content hash of the caller-visible primitive surface (tools, prompts, resources, resource templates). It gives stateless clients a deterministic, pull-based way to detect that a server's surface changed on any subsequent request, without an SSE stream, , or session IDs. Builds on the stateless/sessionless direction of SEP-2575 / SEP-2567, complements the TTL caching model of SEP-2549 (validator + budget), and follows the conventions of SEP-414. Why this fits the Transports WG This is squarely a transport-layer change-detection concern: how does a client learn the server's surface changed (deploy, permission change, schema drift) when the transport is stateless and may be load-balanced across instances? Motivated by concrete operational pain running a large remote MCP server: didn't want to stand up an SSE GET stream solely for deploy updates; isn't universally honored (and stateless clients won't open either); revocable session IDs were meant to force renegotiation but bricked the server with real clients in testing; pushing a deploy-driven to the right connection in a scaled fleet needs cross-instance fan-out and has no single 'change instant' during a rolling deploy. A per-response digest needs zero cross-instance coordination: each instance stamps the surface it serves; the client compares. Key points Response-side detection: on every result; optional per-kind . Reflection / conditional requests: clients MAY echo on a request; servers MAY reject a stale before executing with a new (-32005, HTTP-412-style). Handles output/input-schema drift and lets the harness re-plan/re-prompt. Deterministic, not TTL-based: deploys, permission changes, and schema changes all deterministically change the digest. Status Status: Draft**, seeking a sponsor. File: . Feedback welcome on capability shape, whether to mandate RFC 8785 canonicalization, reflection scope, and deploy-time retry guidance (see Open Questions).

Bringing this to the Transports WG for review and comment before bringing to the core maintainers. Upstream SEP: modelcontextprotocol/modelcontextprotocol#2792 (now draft, pending WG input). Reference implementation: modelcontextprotocol/typescript-sdk#2158 — full client + server, stdio and Streamable HTTP, byte-equality enforcement, 11-case integration matrix. What this proposes A single, transport-agnostic way for clients to express language preference per request, and for servers to indicate the language used per response: on requests (and ) on responses Values are RFC 9110 / strings (BCP 47 language-range lists with quality values), so no new grammar. Why this is a transports concern For Streamable HTTP, the proposal mirrors into the standard / HTTP headers: Following the precedent set by SEP-2243 for / (RPC content surfaced as headers for infra observability and routing). With strict byte-equality between header and when both are present, rejected via a new JSON-RPC error (provisional , HTTP 400). Header absence is tolerated (CDNs strip by default); is the authoritative carrier. is MUST on cacheable responses whose body depends on negotiated language. SSE responses MAY omit the response header (headers flushed before body is known); is still authoritative. For stdio: same fields, no transport changes. Why per-request, not session Aligns with the recent stateless-by-default direction: language can change mid-conversation (user retries in another language, agent serves multiple end-users) without renegotiation. There is no -time language state.