Thanks for the explainer. This seems like a small and clearly beneficial extension to WebTransport to me without any red flags. LGTM1
On Tue, Oct 14, 2025 at 5:33 PM 'Victor Vasiliev' via blink-dev < [email protected]> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAZdMaf9K4z1XWiQFpXq%3DAVG_WXr1UMRQSjQ7Q6qk2S8jZRMjg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAFUtAY9sxSxZavPHSSsK9bWgXvSFkMfx7pagXLUUsAwun2vAzg%40mail.gmail.com.
