Hey Victor, I appreciate you taking the time to outline this here. I have some background on Web Transport (was co-TL for Project Fugu), but it would be great for this to be in a separate Explainer document using the usual template, as it isn't clear what we're winning, which applications this enables, and how it actually interacts with ALPN and the other parts of the various handshakes involved. Our overriding question from the API OWNERS perspective is "*does this problem solve an important problem well?*".
When we're the leading implementation on a feature (which is the usual case these days), we need to provide some arguments and evidence that the use-cases are meaningful to developers, and input from developers about how this is necessary and useful to them. Explainers provide a format for structuring those arguments and explaining the motivating use-cases. Thanks again, Alex On Tuesday, September 23, 2025 at 3:10:54 AM UTC-7 Victor Vasiliev wrote: > Hi Alex, > > WebTransport provides web developers with a networking abstraction that is > semantically similar to having a QUIC connection; because of that, all of > the user data within a WebTransport session is sent on independent data > streams that may arrive in arbitrary order. > > Normally, this is to the advantage of the applications that are built on > top of QUIC or WebTransport. However, one thing that applications often > want to do is negotiate the protocol version at the start; in the > multistream world, this is difficult, since you don't know upfront which > stream actually has the version negotiation info (they can arrive out of > order). > > Protocols that are built on top of QUIC directly solve this problem by > negotiating versions inside the handshake that happens before any actual > application data is exchanged, using a mechanism called TLS ALPN (this > actually works for TCP too, this is how a Web server can, for instance, > support HTTP/1.1 and HTTP/2 at the same TCP port). The feature in question > adds a similar mechanism to WebTransport, by performing an ALPN-like > negotiation inside the WebTransport handshake. > > Thanks, > Victor. > > On Mon, Sep 22, 2025 at 2:49 PM Alex Russell <[email protected]> > wrote: > >> Hey Victor, >> >> As there's no explainer, can you outline what the use-cases for protocol >> negotiation are? The linked part of the spec does not provide clarity as to >> why this is valuable, who it's valuable to, or why we should support it. >> That is, we are always trying to understand "*does this feature solve an >> important problem well?*" it isn't clear (yet) in this case. >> >> Best, >> >> Alex >> >> On Monday, September 22, 2025 at 12:38:46 AM UTC-7 Chromestatus wrote: >> >>> *Contact emails* >>> [email protected] >>> >>> *Explainer* >>> None >>> >>> *Specification* >>> https://w3c.github.io/webtransport/#dom-webtransportoptions-protocols >>> >>> *Summary* >>> WebTransport Application Protocol Negotiation allows negotiation of the >>> protocol used by the web application within the WebTransport handshake. A >>> web application can specify a list of application protocols offered when >>> constructing a WebTransport object, which are then conveyed to the server >>> via HTTP headers; if the server picks one of those protocols, it can >>> indicate that within response headers, and that reply is available within >>> the WebTransport object. >>> >>> *Blink component* >>> Blink>Network>WebTransport >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%3EWebTransport%22> >>> >>> *Web Feature ID* >>> webtransport <https://webstatus.dev/features/webtransport> >>> >>> *TAG review* >>> None >>> >>> *TAG review status* >>> Not applicable >>> >>> *Risks* >>> >>> >>> *Interoperability and Compatibility* >>> The feature was designed to work cleanly with existing servers that do >>> not support protocol negotiation. If the server does not support >>> application protocol negotiation, or does not accept any of the protocols >>> offered, the API will return null as the selected protocol. >>> >>> *Gecko*: Positive ( >>> https://github.com/mozilla/standards-positions/issues/167) Firefox has >>> been positive on WebTransport, and Mozilla representatives have been >>> involved in the discussion regarding this flag (and have told me in the >>> past that I don't need to file new standards position for every spec >>> feature). >>> >>> *WebKit*: Support ( >>> https://github.com/WebKit/standards-positions/issues/18) Safari has >>> expressed support for WebTransport in general; we've not reached out >>> regarding this individual feature, given that Safari has not shipped >>> WebTransport itself. >>> >>> *Web developers*: Positive ( >>> https://github.com/moq-wg/moq-transport/pull/499) IETF MOQ relies on >>> this feature for version negotiation; I've been repeatedly pinged by >>> multiple people there asking when Chrome is going to ship this. >>> >>> *Other signals*: >>> >>> *WebView application risks* >>> >>> Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? >>> None >>> >>> >>> *Debuggability* >>> Since the negotiation is done via HTTP headers, those should be visible >>> through DevTools. >>> >>> *Will this feature be supported on all six Blink platforms (Windows, >>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>> Yes >>> >>> *Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>> Yes >>> https://wpt.fyi/results/webtransport/connect.https.any.html?label=experimental&label=master&aligned >>> >>> *Flag name on about://flags* >>> None >>> >>> *Finch feature name* >>> WebTransportApplicationProtocol >>> >>> *Rollout plan* >>> Will ship enabled for all users >>> >>> *Requires code in //chrome?* >>> False >>> >>> *Tracking bug* >>> https://issues.chromium.org/u/1/issues/416080492 >>> >>> *Estimated milestones* >>> Shipping on desktop 142 >>> Shipping on Android 142 >>> >>> *Anticipated spec changes* >>> >>> Open questions about a feature may be a source of future web compat or >>> interop issues. Please list open issues (e.g. links to known github issues >>> in the project for the feature specification) whose resolution may >>> introduce web compat/interop risk (e.g., changing to naming or structure of >>> the API in a non-backward-compatible way). None >>> >>> *Link to entry on the Chrome Platform Status* >>> https://chromestatus.com/feature/6521719678042112?gate=4663773843161088 >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com>. >>> >>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e9059ca8-cd66-422d-a2a9-2812ef9b50f0n%40chromium.org.
