Hi Alex, Sorry for the late reply; I've been travelling/OOO for a couple of weeks.
The explainer is at < https://github.com/w3c/webtransport/blob/main/explainers/subprotocol_negotiation.md >. Thanks, Victor. On Wed, Sep 24, 2025 at 11:13 AM Alex Russell <[email protected]> wrote: > 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/CAAZdMaf9K4z1XWiQFpXq%3DAVG_WXr1UMRQSjQ7Q6qk2S8jZRMjg%40mail.gmail.com.
