WebTransport review request

[wilaw]

Ciao TAG!

I'm requesting a review of the WebTransport API Specification.

WebTransport is an API that allows web applications to establish interactive, bidirectional, multiplexed network connections
It fills gaps in the web platform, such as lack of UDP-like networking API and lack of WebSocket-like API without head-of-line blocking, by proving a web accessible interface to the WebTransport protocol being developed by the IETF WebTransport Working Group. It provides:

• Reliable streams
• Unreliable datagrams
• Encryption and congestion control
• An origin-based security model
• Multiplexing with existing HTTP/3 connections

It's great for sending or receiving high-frequency, small messages that don't need to be reliable (like game state), sending or receiving low-latency media and transferring files.

• Explainer¹ : https://github.com/w3c/webtransport/blob/main/explainer.md
• Specification URL: https://w3c.github.io/webtransport/
• Tests: https://wpt.fyi/results/webtransport?label=master&label=experimental&aligned&q=webtransport and https://github.com/bashi/rfcs/blob/08cd404ee62df4dd93b11175310d44fa98187c96/rfcs/webtransport_h3_test_server.md (still under development)
• Security and Privacy self-review²: https://w3c.github.io/webtransport/#privacy-security
• GitHub repo (if you prefer feedback filed there): https://github.com/w3c/webtransport
• Primary contacts (and their relationship to the specification):
  • Yutaka Hirano (@yutakahirano) - Google - editor
  • Bernard Aboba (@aboba) - Microsoft Corporation - editor
  • Victor Vasiliev (@vasilvv) - Google - editor
  • Jan-Ivar Bruaroey (@jan-ivar) - Mozilla - co-chair
  • Will Law (@wilaw) - Akamai - co-chair
  • Yves Lafon (@ylafon) - W3C - staff contact
• Organization(s)/project(s) driving the specification: W3C WebTransport Working Group
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://www.chromestatus.com/feature/4854144902889472

Further details:

• [x ] I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: we have a prepared a milestone for a minimum viable implementation and TAG oversight is requested as part of that milestone.
• The group where the work on this specification is currently being done: W3C WebTransport Working Group
• This work is being funded by: Google, Microsoft, Mozilla and Akamai through WG participation.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback. Please prefix the title with [TAG] and we will triage appropriately.

[yutakahirano]

I'm planning to send an intent to ship to blink-dev in mid September, and it'd be great if it's reviewed by then.

[jan-ivar]

Note the https://github.com/w3c/webtransport/blob/main/security-questionnaire.md has now been filled in.

[torgo]

Just noting that we seem to have completed a review in 2020. Sorry for the late reply here but can you clarify what has changed so we can try to expedite this and get it done at our upcoming virtual f2f.

[jan-ivar]

Sure thing, and thanks. Major changes since July 2020:

1. The spec is now in the W3C, not WICG
2. Removed the multiple-transport abstraction. HTTP/3 is now the sole transport, simplifying the model significantly
   • We're still working on implicit HTTP/2 Fallback support w3c/webtransport#107 where HTTP/3 is unavailable
3. Integrates with the fetch spec to obtain a connection; may be pooled but this has no implementations yet, so JS gets a dedicated server connection by default
4. Connection URLs now use the “https" scheme, and must include the port
5. SecureContext only, exposed on Window and DedicatedWorker
6. WHATWG streams are used throughout, even for datagrams (where they provide local back-pressure sender-side)
7. Fleshed out streams algorithms with underlying queues, back pressure, and error handling
8. Removed custom network (QUIC) abort APIs and integrated with WHATWG stream abort semantics instead:

   stream.abort(new WebTransportError({streamErrorCode})) // aborts stream with same code on client & server

9. Operates on BufferSource data, with (streams) semantics lower-level than WebSocket (message) semantics:
   • Use single stream for data you need to arrive in order (but BYO framing)
   • Use separate streams for data that should arrive in parallel but can arrive out of order
10. Close code and message from server (not an error): const {closeCode, reason} = await wt.closed
11. CSP

Unfortunately, the explainer is a bit outdated. I hope to get to that soon in w3c/webtransport#319.

[yutakahirano]

Chrome shipped the API in 97.

[atanassov]

@plinss and I had a chance to review this during our Madripoor TAG f2f. Thank you for summarizing all changes since last review and updating the security questionnaire. Given most changes are about simplifications and feature completion, moving the capability into a most stable state, we are happy to sign off.

Thank you for your patience and working with us. Best of luck finishing the work at the WebTransportWG.