LGTM3 On Wednesday, October 22, 2025 at 8:04:47 AM UTC-7 Mike Taylor wrote:
> LGTM2 > On 10/15/25 10:46 a.m., Rick Byers wrote: > > 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 > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9sxSxZavPHSSsK9bWgXvSFkMfx7pagXLUUsAwun2vAzg%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/4803f6a0-aef7-42d8-9407-c88a5bc39a78n%40chromium.org.
