Spec gap: no defined success response for session-termination DELETE (only 405 is specified)

Problem

The Streamable HTTP transport spec says clients SHOULD send an HTTP DELETE to terminate a session and servers MAY respond 405 if they don't allow client-initiated termination. It never states what a successful termination response looks like (200? 204? any 2xx?), nor whether 404 is acceptable for a session that is already gone.

This bit us while reviewing #322 (server-session-lifecycle scenario): with no spec anchor, any strict status assertion invents a requirement. The scenario currently treats non-2xx/405 as WARNING rather than FAILURE, and 404 as already-terminated, but that's a harness judgment call, not spec.

Ask

Track here for now; this should become a clarification issue/PR on the spec repo (modelcontextprotocol) pinning the expected success status family for DELETE, and the semantics of 404 on an already-terminated session. Once the spec answers, tighten the #322 checks to match.

Start with the Streamable HTTP DELETE behavior described in the issue and review #322's server-session-lifecycle scenario. Compare the current WARNING handling for non-2xx/405 and 404 already-terminated cases with the clarification expected from the modelcontextprotocol spec repo. Done means the external spec defines the success status and 404 semantics, after which #322 can be tightened.