SSE (text/event-stream) framing for event streams

[goelakash]

The problem

SSE (text/event-stream) is how LLM and agent services stream output to browsers today (OpenAI-style APIs, AG-UI, MCP's Streamable HTTP transport). Smithy's @streaming event stream model fits this use case well, but every shipped protocol frames event streams as application/vnd.amazon.eventstream, which browsers don't speak. So teams building these services either drop Smithy for those endpoints or hand-roll the streaming layer.

Why this fits Smithy

The spec already treats framing as a protocol concern: streaming.rst says framing "is defined by the protocol", and the rpcv2Json and rpcv2Cbor specs note "other forms of content streaming MAY be added in the future, utilizing different values for Accept". SSE would be a second framing with an obvious mapping: union member name → event:, JSON payload → data:.

Other IDLs have already gone through this. TypeSpec added SSE support with the same union-of-named-events shape (@typespec/sse, microsoft/typespec#4513, design thread microsoft/typespec#2378), and OpenAPI 3.2 added itemSchema for text/event-stream (OAI/OpenAPI-Specification#4554). Connect RPC decided against SSE because it's text-only and server→client only (connectrpc/connect-go#772) — which suggests limiting this to response streams with non-binary payloads.

Question for maintainers

Is this something Smithy wants, and if so: a new protocol trait (e.g. smithy.protocols#sseJson), or a framing option on existing HTTP protocols? I have a working TypeScript implementation (smithy-lang/smithy-typescript#2177, tracking issue smithy-lang/smithy-typescript#2176) showing the typed union and serde reuse cleanly — only the framing differs — but the design should live at the spec level so all languages stay consistent.

Companion issue: #3222. Happy to write up the detailed design (terminal events, errors/$unknown, resumability) if there's interest.