[blink-dev] Intent to Ship: WebTransport serverCertificateHashes option

['Victor Vasiliev' via blink-dev]

Contact emails

yhir...@chromium.org, vasi...@chromium.org

Explainer

https://github.com/w3c/webtransport/blob/main/explainer.md

Spec

https://w3c.github.io/webtransport/#dom-webtransportoptions-servercertificatehashes

WebTransport has been already covered by a series of TAG reviews (389
, 669
).

Summary

In WebTransport, the serverCertificateHashes option allows the website to
connect to a WebTransport server by authenticating the certificate against
the expected certificate hash instead of using the Web PKI.  This feature
allows Web developers to connect to WebTransport servers that would
normally find obtaining a publicly trusted certificate challenging, such as
hosts that are not publically routable, or virtual machines that are
ephemeral in nature.

During the WebTransport Intent to Ship email thread
,
concerns were raised regarding the security considerations of this portion
of the spec being incomplete.  We believe that we have addressed those
concerns (notably, in this PR ).
In terms of the actual code behavior, the only major difference since the
previous thread is that we no longer allow RSA keys for the certificates.

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/I6MS2kOKcx0/m/NAdg7Sc-CwAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)?

Yes.

Debuggability

The certificate-related errors for WebTransport sessions are logged into
the developer console.

Measurement

The use of this feature is tracked by the
WebTransportServerCertificateHashes use counter.

Risks

Interoperability and Compatibility

There is some discussion about adding a mechanism to prevent websites from
using this feature via an HTTP header (either CSP or a new header).  Some
of the proposals could potentially break existing usage under certain
conditions (e.g. if a webpage both uses serverCertificateHashes and has a
connect-src directive, and we decide to extend connect-src); I expect for
those cases to be sufficiently niche to ultimately not be a problem, and
the question itself is of fairly low priority as there does not seem to be
a strong security reason for a website to restrict serverCertificateHashes.

Gecko: worth prototyping


WebKit: no signal


Web / Framework developers: positive (we have received indication in the
past that serverCertificateHashes is a blocker for migrating from WebRTC at
least one of them)

Ergonomics

The API is roughly modeled after a similar WebRTC API (RtcDtlsFingerprint),
with a noted improvement that the certificate hash no longer requires to be
serialized into a specific format.

Activation

Using this feature would require web developers to design their application
in a way that supports generating and distributing ephemeral certificates
on demand.

Security

Security considerations for this feature are discussed at length in PR #375

.

Is this feature fully tested by web-platform-tests
?
Link to test suite results from wpt.fyi.

WebTransport itself is tested by web-platform-tests; this specific feature
requires infra support that is currently not available (issue
).

Entry on the feature dashboard 

https://chromestatus.com/feature/5690646332440576

-- 
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAZdMadAk5z-V7m8L_oVNyPGmE8An%2BcVEKsfSeOTDe9hEbKd-Q%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebTransport

[Yutaka Hirano]

> I'll also note that the TAG just put this on their agenda for this coming
week. If concerns are raised there, I would appreciate us addressing them
thoroughly before shipping.

The week of 2021-10-11 ended but we haven't heard anything from them. I'm
planning to land the change.

On Tue, Oct 12, 2021 at 3:53 PM Yutaka Hirano  wrote:

> Thank you! We'll land the shipping CL
>  after
> addressing TAG review comments.
>
> On Sat, Oct 9, 2021 at 1:07 AM Rick Byers  wrote:
>
>> LGTM3
>>
>> It's exciting to see this shipping! Lack of datagram networking has been
>> a hole in the platform for a long time.
>>
>>
>>
>> On Fri, Oct 8, 2021 at 1:18 AM Yoav Weiss  wrote:
>>
>>> *LGTM2* to ship without certificate fingerprints. It'd be great to
>>> ensure public documentation for this includes the fallback mechanism we
>>> want developers to implement. (both in the web.dev article and future
>>> MDN documentation).
>>>
>>> On Thu, Oct 7, 2021 at 9:19 PM Mike West  wrote:
>>>
 LGTM1, to ship this without the certificate fingerprint portion of 349
 discussed above. There's still some conversation to be had there, and I
 think it's worth finishing the discussion before shipping it since it's
 quite clearly separable. I'd suggest shipping that as a separate intent if
 that's the way the conversation goes.

 I appreciate Philip's comments as well, and I'm happy to see that y'all
 have already put up a PR to add CSP support. I think we should probably
 alter the CSP spec to make your PR more clear, but that's not something I
 think we ought to block on.

 I'll also note that the TAG just put this on their agenda for this
 coming week. If concerns are raised there, I would appreciate us addressing
 them thoroughly before shipping.

 -mike


 On Thu, Oct 7, 2021 at 4:53 PM Yutaka Hirano 
 wrote:

>
>
> On Thu, Oct 7, 2021 at 5:51 PM Yutaka Hirano 
> wrote:
>
>>
>>
>> On Thu, Oct 7, 2021 at 5:38 PM Philip Jägenstedt 
>> wrote:
>>
>>> On Thu, Oct 7, 2021 at 10:04 AM Yutaka Hirano 
>>> wrote:
>>>
 Thank you!

 On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt <
 foo...@chromium.org> wrote:

> On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano 
> wrote:
>
>>
>>
>> On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt <
>> foo...@chromium.org> wrote:
>>
>>> On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano <
>>> yhir...@chromium.org> wrote:
>>>
 Hi Philip,

 Sorry for the belated reply. Comments inline:

 On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <
 foo...@chromium.org> wrote:

> Hi again,
>
> I've made a full pass of the intent now. I have a lot of
> questions, but am pretty convinced we should ship this, it's just 
> a matter
> of what things need to block that, and what things can be left 
> until later.
>
> Comments inline...
>
> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano <
> yhir...@chromium.org> wrote:
>
>> Contact emails
>>
>> yhir...@chromium.org, vasi...@chromium.org
>>
>> Explainer
>>
>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>
>> Specification
>>
>> https://w3c.github.io/webtransport
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>>
>
> I skimmed https://github.com/w3c/webtransport/issues/ and see
> multiple issues filed by other browser vendors. Are any of the 
> remaining
> issues ones that could change the API's shape or behavior? It 
> would be good
> to resolve any such issues, since they won't be possible to 
> address once
> the API is locked in by sites depending on it.
>
>
 I believe we've addressed issues that may require breaking
 changes. You can see open
 /closed
  issues
 for the initial launch (this intent).  I shared our plan
 
  at a WG meeting in May
 

Re: [blink-dev] Intent to Ship: WebTransport

[Yutaka Hirano]

Thank you! We'll land the shipping CL
 after
addressing TAG review comments.

On Sat, Oct 9, 2021 at 1:07 AM Rick Byers  wrote:

> LGTM3
>
> It's exciting to see this shipping! Lack of datagram networking has been a
> hole in the platform for a long time.
>
>
>
> On Fri, Oct 8, 2021 at 1:18 AM Yoav Weiss  wrote:
>
>> *LGTM2* to ship without certificate fingerprints. It'd be great to
>> ensure public documentation for this includes the fallback mechanism we
>> want developers to implement. (both in the web.dev article and future
>> MDN documentation).
>>
>> On Thu, Oct 7, 2021 at 9:19 PM Mike West  wrote:
>>
>>> LGTM1, to ship this without the certificate fingerprint portion of 349
>>> discussed above. There's still some conversation to be had there, and I
>>> think it's worth finishing the discussion before shipping it since it's
>>> quite clearly separable. I'd suggest shipping that as a separate intent if
>>> that's the way the conversation goes.
>>>
>>> I appreciate Philip's comments as well, and I'm happy to see that y'all
>>> have already put up a PR to add CSP support. I think we should probably
>>> alter the CSP spec to make your PR more clear, but that's not something I
>>> think we ought to block on.
>>>
>>> I'll also note that the TAG just put this on their agenda for this
>>> coming week. If concerns are raised there, I would appreciate us addressing
>>> them thoroughly before shipping.
>>>
>>> -mike
>>>
>>>
>>> On Thu, Oct 7, 2021 at 4:53 PM Yutaka Hirano 
>>> wrote:
>>>


 On Thu, Oct 7, 2021 at 5:51 PM Yutaka Hirano 
 wrote:

>
>
> On Thu, Oct 7, 2021 at 5:38 PM Philip Jägenstedt 
> wrote:
>
>> On Thu, Oct 7, 2021 at 10:04 AM Yutaka Hirano 
>> wrote:
>>
>>> Thank you!
>>>
>>> On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt <
>>> foo...@chromium.org> wrote:
>>>
 On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano 
 wrote:

>
>
> On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt <
> foo...@chromium.org> wrote:
>
>> On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano <
>> yhir...@chromium.org> wrote:
>>
>>> Hi Philip,
>>>
>>> Sorry for the belated reply. Comments inline:
>>>
>>> On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <
>>> foo...@chromium.org> wrote:
>>>
 Hi again,

 I've made a full pass of the intent now. I have a lot of
 questions, but am pretty convinced we should ship this, it's just 
 a matter
 of what things need to block that, and what things can be left 
 until later.

 Comments inline...

 On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano <
 yhir...@chromium.org> wrote:

> Contact emails
>
> yhir...@chromium.org, vasi...@chromium.org
>
> Explainer
>
> https://github.com/w3c/webtransport/blob/main/explainer.md
>
> Specification
>
> https://w3c.github.io/webtransport
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>
> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>

 I skimmed https://github.com/w3c/webtransport/issues/ and see
 multiple issues filed by other browser vendors. Are any of the 
 remaining
 issues ones that could change the API's shape or behavior? It 
 would be good
 to resolve any such issues, since they won't be possible to 
 address once
 the API is locked in by sites depending on it.


>>> I believe we've addressed issues that may require breaking
>>> changes. You can see open
>>> /closed
>>>  issues
>>> for the initial launch (this intent).  I shared our plan
>>> 
>>>  at a WG meeting in May
>>> 
>>>  and
>>> we've been working to find and resolve such issues since then.
>>>
>>
>> I see, creating a milestone for this is really handy! Are the
>> remaining issue in
>> https://github.com/w3c/webtransport/milestone/1 not blocking
>> then, even issue #349
>> ?
>>

Re: [blink-dev] Intent to Ship: WebTransport

[Rick Byers]

LGTM3

It's exciting to see this shipping! Lack of datagram networking has been a
hole in the platform for a long time.



On Fri, Oct 8, 2021 at 1:18 AM Yoav Weiss  wrote:

> *LGTM2* to ship without certificate fingerprints. It'd be great to ensure
> public documentation for this includes the fallback mechanism we want
> developers to implement. (both in the web.dev article and future MDN
> documentation).
>
> On Thu, Oct 7, 2021 at 9:19 PM Mike West  wrote:
>
>> LGTM1, to ship this without the certificate fingerprint portion of 349
>> discussed above. There's still some conversation to be had there, and I
>> think it's worth finishing the discussion before shipping it since it's
>> quite clearly separable. I'd suggest shipping that as a separate intent if
>> that's the way the conversation goes.
>>
>> I appreciate Philip's comments as well, and I'm happy to see that y'all
>> have already put up a PR to add CSP support. I think we should probably
>> alter the CSP spec to make your PR more clear, but that's not something I
>> think we ought to block on.
>>
>> I'll also note that the TAG just put this on their agenda for this coming
>> week. If concerns are raised there, I would appreciate us addressing them
>> thoroughly before shipping.
>>
>> -mike
>>
>>
>> On Thu, Oct 7, 2021 at 4:53 PM Yutaka Hirano 
>> wrote:
>>
>>>
>>>
>>> On Thu, Oct 7, 2021 at 5:51 PM Yutaka Hirano 
>>> wrote:
>>>


 On Thu, Oct 7, 2021 at 5:38 PM Philip Jägenstedt 
 wrote:

> On Thu, Oct 7, 2021 at 10:04 AM Yutaka Hirano 
> wrote:
>
>> Thank you!
>>
>> On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt 
>> wrote:
>>
>>> On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano 
>>> wrote:
>>>


 On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt <
 foo...@chromium.org> wrote:

> On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano 
> wrote:
>
>> Hi Philip,
>>
>> Sorry for the belated reply. Comments inline:
>>
>> On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <
>> foo...@chromium.org> wrote:
>>
>>> Hi again,
>>>
>>> I've made a full pass of the intent now. I have a lot of
>>> questions, but am pretty convinced we should ship this, it's just a 
>>> matter
>>> of what things need to block that, and what things can be left 
>>> until later.
>>>
>>> Comments inline...
>>>
>>> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano <
>>> yhir...@chromium.org> wrote:
>>>
 Contact emails

 yhir...@chromium.org, vasi...@chromium.org

 Explainer

 https://github.com/w3c/webtransport/blob/main/explainer.md

 Specification

 https://w3c.github.io/webtransport

 https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/

 https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/

>>>
>>> I skimmed https://github.com/w3c/webtransport/issues/ and see
>>> multiple issues filed by other browser vendors. Are any of the 
>>> remaining
>>> issues ones that could change the API's shape or behavior? It would 
>>> be good
>>> to resolve any such issues, since they won't be possible to address 
>>> once
>>> the API is locked in by sites depending on it.
>>>
>>>
>> I believe we've addressed issues that may require breaking
>> changes. You can see open
>> /closed
>>  issues
>> for the initial launch (this intent).  I shared our plan
>> 
>>  at a WG meeting in May
>> 
>>  and
>> we've been working to find and resolve such issues since then.
>>
>
> I see, creating a milestone for this is really handy! Are the
> remaining issue in https://github.com/w3c/webtransport/milestone/1
> not blocking then, even issue #349
> ?
>

 *Except for issue #349* we have consensus on discussions. As
 Victor commented in this thread, we can ship WebTransport *except
 for *customeCertificationHashes
 
  if
 needed.

>>>
>>> If custom certificates is a nice-to-have then shipping with

Re: [blink-dev] Intent to Ship: WebTransport

[Yoav Weiss]

*LGTM2* to ship without certificate fingerprints. It'd be great to ensure
public documentation for this includes the fallback mechanism we want
developers to implement. (both in the web.dev article and future MDN
documentation).

On Thu, Oct 7, 2021 at 9:19 PM Mike West  wrote:

> LGTM1, to ship this without the certificate fingerprint portion of 349
> discussed above. There's still some conversation to be had there, and I
> think it's worth finishing the discussion before shipping it since it's
> quite clearly separable. I'd suggest shipping that as a separate intent if
> that's the way the conversation goes.
>
> I appreciate Philip's comments as well, and I'm happy to see that y'all
> have already put up a PR to add CSP support. I think we should probably
> alter the CSP spec to make your PR more clear, but that's not something I
> think we ought to block on.
>
> I'll also note that the TAG just put this on their agenda for this coming
> week. If concerns are raised there, I would appreciate us addressing them
> thoroughly before shipping.
>
> -mike
>
>
> On Thu, Oct 7, 2021 at 4:53 PM Yutaka Hirano  wrote:
>
>>
>>
>> On Thu, Oct 7, 2021 at 5:51 PM Yutaka Hirano 
>> wrote:
>>
>>>
>>>
>>> On Thu, Oct 7, 2021 at 5:38 PM Philip Jägenstedt 
>>> wrote:
>>>
 On Thu, Oct 7, 2021 at 10:04 AM Yutaka Hirano 
 wrote:

> Thank you!
>
> On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt 
> wrote:
>
>> On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano 
>> wrote:
>>
>>>
>>>
>>> On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt <
>>> foo...@chromium.org> wrote:
>>>
 On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano 
 wrote:

> Hi Philip,
>
> Sorry for the belated reply. Comments inline:
>
> On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <
> foo...@chromium.org> wrote:
>
>> Hi again,
>>
>> I've made a full pass of the intent now. I have a lot of
>> questions, but am pretty convinced we should ship this, it's just a 
>> matter
>> of what things need to block that, and what things can be left until 
>> later.
>>
>> Comments inline...
>>
>> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano <
>> yhir...@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> yhir...@chromium.org, vasi...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>>
>>> Specification
>>>
>>> https://w3c.github.io/webtransport
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>>>
>>
>> I skimmed https://github.com/w3c/webtransport/issues/ and see
>> multiple issues filed by other browser vendors. Are any of the 
>> remaining
>> issues ones that could change the API's shape or behavior? It would 
>> be good
>> to resolve any such issues, since they won't be possible to address 
>> once
>> the API is locked in by sites depending on it.
>>
>>
> I believe we've addressed issues that may require breaking
> changes. You can see open
> /closed
>  issues
> for the initial launch (this intent).  I shared our plan
> 
>  at a WG meeting in May
> 
>  and
> we've been working to find and resolve such issues since then.
>

 I see, creating a milestone for this is really handy! Are the
 remaining issue in https://github.com/w3c/webtransport/milestone/1
 not blocking then, even issue #349
 ?

>>>
>>> *Except for issue #349* we have consensus on discussions. As Victor
>>> commented in this thread, we can ship WebTransport *except for *
>>> customeCertificationHashes
>>> 
>>>  if
>>> needed.
>>>
>>
>> If custom certificates is a nice-to-have then shipping without it
>> seems fine to me. That would mean removing serverCertificateHashes from 
>> the
>> dictionary, right? I ask because the spec also says something
>> about NotSupportedError when the protocol doesn't support it, but it 
>> seems
>> better to behave as if the feature doesn't exis

Re: [blink-dev] Intent to Ship: WebTransport

[Mike West]

LGTM1, to ship this without the certificate fingerprint portion of 349
discussed above. There's still some conversation to be had there, and I
think it's worth finishing the discussion before shipping it since it's
quite clearly separable. I'd suggest shipping that as a separate intent if
that's the way the conversation goes.

I appreciate Philip's comments as well, and I'm happy to see that y'all
have already put up a PR to add CSP support. I think we should probably
alter the CSP spec to make your PR more clear, but that's not something I
think we ought to block on.

I'll also note that the TAG just put this on their agenda for this coming
week. If concerns are raised there, I would appreciate us addressing them
thoroughly before shipping.

-mike


On Thu, Oct 7, 2021 at 4:53 PM Yutaka Hirano  wrote:

>
>
> On Thu, Oct 7, 2021 at 5:51 PM Yutaka Hirano  wrote:
>
>>
>>
>> On Thu, Oct 7, 2021 at 5:38 PM Philip Jägenstedt 
>> wrote:
>>
>>> On Thu, Oct 7, 2021 at 10:04 AM Yutaka Hirano 
>>> wrote:
>>>
 Thank you!

 On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt 
 wrote:

> On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano 
> wrote:
>
>>
>>
>> On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt <
>> foo...@chromium.org> wrote:
>>
>>> On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano 
>>> wrote:
>>>
 Hi Philip,

 Sorry for the belated reply. Comments inline:

 On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <
 foo...@chromium.org> wrote:

> Hi again,
>
> I've made a full pass of the intent now. I have a lot of
> questions, but am pretty convinced we should ship this, it's just a 
> matter
> of what things need to block that, and what things can be left until 
> later.
>
> Comments inline...
>
> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano <
> yhir...@chromium.org> wrote:
>
>> Contact emails
>>
>> yhir...@chromium.org, vasi...@chromium.org
>>
>> Explainer
>>
>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>
>> Specification
>>
>> https://w3c.github.io/webtransport
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>>
>
> I skimmed https://github.com/w3c/webtransport/issues/ and see
> multiple issues filed by other browser vendors. Are any of the 
> remaining
> issues ones that could change the API's shape or behavior? It would 
> be good
> to resolve any such issues, since they won't be possible to address 
> once
> the API is locked in by sites depending on it.
>
>
 I believe we've addressed issues that may require breaking changes.
 You can see open /
 closed  
 issues
 for the initial launch (this intent).  I shared our plan
 
  at a WG meeting in May
 
  and
 we've been working to find and resolve such issues since then.

>>>
>>> I see, creating a milestone for this is really handy! Are the
>>> remaining issue in https://github.com/w3c/webtransport/milestone/1
>>> not blocking then, even issue #349
>>> ?
>>>
>>
>> *Except for issue #349* we have consensus on discussions. As Victor
>> commented in this thread, we can ship WebTransport *except for *
>> customeCertificationHashes
>> 
>>  if
>> needed.
>>
>
> If custom certificates is a nice-to-have then shipping without it
> seems fine to me. That would mean removing serverCertificateHashes from 
> the
> dictionary, right? I ask because the spec also says something
> about NotSupportedError when the protocol doesn't support it, but it seems
> better to behave as if the feature doesn't exist at all.
>
>
 The property is protected by WebTransportCustomCertificates
 ,
 so when we enable only WebTransport, the property will be invisible.

>>>
>>> Great, thanks for confirming!
>>>
>>>
 Looking through some other issues:
>
>- Can https://github.com

Re: [blink-dev] Intent to Ship: WebTransport

[Yutaka Hirano]

On Thu, Oct 7, 2021 at 5:51 PM Yutaka Hirano  wrote:

>
>
> On Thu, Oct 7, 2021 at 5:38 PM Philip Jägenstedt 
> wrote:
>
>> On Thu, Oct 7, 2021 at 10:04 AM Yutaka Hirano 
>> wrote:
>>
>>> Thank you!
>>>
>>> On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt 
>>> wrote:
>>>
 On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano 
 wrote:

>
>
> On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt 
> wrote:
>
>> On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano 
>> wrote:
>>
>>> Hi Philip,
>>>
>>> Sorry for the belated reply. Comments inline:
>>>
>>> On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <
>>> foo...@chromium.org> wrote:
>>>
 Hi again,

 I've made a full pass of the intent now. I have a lot of questions,
 but am pretty convinced we should ship this, it's just a matter of what
 things need to block that, and what things can be left until later.

 Comments inline...

 On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano 
 wrote:

> Contact emails
>
> yhir...@chromium.org, vasi...@chromium.org
>
> Explainer
>
> https://github.com/w3c/webtransport/blob/main/explainer.md
>
> Specification
>
> https://w3c.github.io/webtransport
>
> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>
> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>

 I skimmed https://github.com/w3c/webtransport/issues/ and see
 multiple issues filed by other browser vendors. Are any of the 
 remaining
 issues ones that could change the API's shape or behavior? It would be 
 good
 to resolve any such issues, since they won't be possible to address 
 once
 the API is locked in by sites depending on it.


>>> I believe we've addressed issues that may require breaking changes.
>>> You can see open /
>>> closed  issues
>>> for the initial launch (this intent).  I shared our plan
>>> 
>>>  at a WG meeting in May
>>> 
>>>  and
>>> we've been working to find and resolve such issues since then.
>>>
>>
>> I see, creating a milestone for this is really handy! Are the
>> remaining issue in https://github.com/w3c/webtransport/milestone/1
>> not blocking then, even issue #349
>> ?
>>
>
> *Except for issue #349* we have consensus on discussions. As Victor
> commented in this thread, we can ship WebTransport *except for *
> customeCertificationHashes
> 
>  if
> needed.
>

 If custom certificates is a nice-to-have then shipping without it seems
 fine to me. That would mean removing serverCertificateHashes from the
 dictionary, right? I ask because the spec also says something
 about NotSupportedError when the protocol doesn't support it, but it seems
 better to behave as if the feature doesn't exist at all.


>>> The property is protected by WebTransportCustomCertificates
>>> ,
>>> so when we enable only WebTransport, the property will be invisible.
>>>
>>
>> Great, thanks for confirming!
>>
>>
>>> Looking through some other issues:

- Can https://github.com/w3c/webtransport/issues/59 be resolved for
the WebPKI case? If CSP currently has no effect, then adding it on later
could be hard because some sites could already be using CSP that would
block it, and those sites would be broken by adding CSP support later.


>>> Yes I think so. We check the "connect-src" directive. It is tested as
>>> csp-fail.https.window.js
>>> 
>>> and csp-pass.window.js
>>> 
>>> .
>>>
>>
>> That's good, the risk I was worried about doesn't exist then. Would you
>> consider that this behavior is required by some spec, even though it's not
>> mentioned in https://w3c.github.io/webtransport/? If not, then do you
>> think it's reasonable to prioritize the spec work for this before this
>> reaches stable?
>>
>
> This behavior should be specified, and yes I think that effo

Re: [blink-dev] Intent to Ship: WebTransport

[Yutaka Hirano]

On Thu, Oct 7, 2021 at 5:38 PM Philip Jägenstedt 
wrote:

> On Thu, Oct 7, 2021 at 10:04 AM Yutaka Hirano 
> wrote:
>
>> Thank you!
>>
>> On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt 
>> wrote:
>>
>>> On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano 
>>> wrote:
>>>


 On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt 
 wrote:

> On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano 
> wrote:
>
>> Hi Philip,
>>
>> Sorry for the belated reply. Comments inline:
>>
>> On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <
>> foo...@chromium.org> wrote:
>>
>>> Hi again,
>>>
>>> I've made a full pass of the intent now. I have a lot of questions,
>>> but am pretty convinced we should ship this, it's just a matter of what
>>> things need to block that, and what things can be left until later.
>>>
>>> Comments inline...
>>>
>>> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano 
>>> wrote:
>>>
 Contact emails

 yhir...@chromium.org, vasi...@chromium.org

 Explainer

 https://github.com/w3c/webtransport/blob/main/explainer.md

 Specification

 https://w3c.github.io/webtransport

 https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/

 https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/

>>>
>>> I skimmed https://github.com/w3c/webtransport/issues/ and see
>>> multiple issues filed by other browser vendors. Are any of the remaining
>>> issues ones that could change the API's shape or behavior? It would be 
>>> good
>>> to resolve any such issues, since they won't be possible to address once
>>> the API is locked in by sites depending on it.
>>>
>>>
>> I believe we've addressed issues that may require breaking changes.
>> You can see open /
>> closed  issues
>> for the initial launch (this intent).  I shared our plan
>> 
>>  at a WG meeting in May
>> 
>>  and
>> we've been working to find and resolve such issues since then.
>>
>
> I see, creating a milestone for this is really handy! Are the
> remaining issue in https://github.com/w3c/webtransport/milestone/1
> not blocking then, even issue #349
> ?
>

 *Except for issue #349* we have consensus on discussions. As Victor
 commented in this thread, we can ship WebTransport *except for *
 customeCertificationHashes
 
  if
 needed.

>>>
>>> If custom certificates is a nice-to-have then shipping without it seems
>>> fine to me. That would mean removing serverCertificateHashes from the
>>> dictionary, right? I ask because the spec also says something
>>> about NotSupportedError when the protocol doesn't support it, but it seems
>>> better to behave as if the feature doesn't exist at all.
>>>
>>>
>> The property is protected by WebTransportCustomCertificates
>> ,
>> so when we enable only WebTransport, the property will be invisible.
>>
>
> Great, thanks for confirming!
>
>
>> Looking through some other issues:
>>>
>>>- Can https://github.com/w3c/webtransport/issues/59 be resolved for
>>>the WebPKI case? If CSP currently has no effect, then adding it on later
>>>could be hard because some sites could already be using CSP that would
>>>block it, and those sites would be broken by adding CSP support later.
>>>
>>>
>> Yes I think so. We check the "connect-src" directive. It is tested as
>> csp-fail.https.window.js
>> 
>> and csp-pass.window.js
>> 
>> .
>>
>
> That's good, the risk I was worried about doesn't exist then. Would you
> consider that this behavior is required by some spec, even though it's not
> mentioned in https://w3c.github.io/webtransport/? If not, then do you
> think it's reasonable to prioritize the spec work for this before this
> reaches stable?
>

This behavior should be specified, and yes I think that effort should be
prioritized. I'm happy to work on that.


>
>
>>>- https://github.com/w3c/webtransport/issues/175 sounds editorial
>>>but doesn't have that label. If any code would change as a result of 
>

Re: [blink-dev] Intent to Ship: WebTransport

[Philip Jägenstedt]

On Thu, Oct 7, 2021 at 10:04 AM Yutaka Hirano  wrote:

> Thank you!
>
> On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt 
> wrote:
>
>> On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano 
>> wrote:
>>
>>>
>>>
>>> On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt 
>>> wrote:
>>>
 On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano 
 wrote:

> Hi Philip,
>
> Sorry for the belated reply. Comments inline:
>
> On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt 
> wrote:
>
>> Hi again,
>>
>> I've made a full pass of the intent now. I have a lot of questions,
>> but am pretty convinced we should ship this, it's just a matter of what
>> things need to block that, and what things can be left until later.
>>
>> Comments inline...
>>
>> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano 
>> wrote:
>>
>>> Contact emails
>>>
>>> yhir...@chromium.org, vasi...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>>
>>> Specification
>>>
>>> https://w3c.github.io/webtransport
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>>>
>>
>> I skimmed https://github.com/w3c/webtransport/issues/ and see
>> multiple issues filed by other browser vendors. Are any of the remaining
>> issues ones that could change the API's shape or behavior? It would be 
>> good
>> to resolve any such issues, since they won't be possible to address once
>> the API is locked in by sites depending on it.
>>
>>
> I believe we've addressed issues that may require breaking changes.
> You can see open /
> closed  issues
> for the initial launch (this intent).  I shared our plan
> 
>  at a WG meeting in May
> 
>  and
> we've been working to find and resolve such issues since then.
>

 I see, creating a milestone for this is really handy! Are the remaining
 issue in https://github.com/w3c/webtransport/milestone/1 not blocking
 then, even issue #349 ?

>>>
>>> *Except for issue #349* we have consensus on discussions. As Victor
>>> commented in this thread, we can ship WebTransport *except for *
>>> customeCertificationHashes
>>> 
>>>  if
>>> needed.
>>>
>>
>> If custom certificates is a nice-to-have then shipping without it seems
>> fine to me. That would mean removing serverCertificateHashes from the
>> dictionary, right? I ask because the spec also says something
>> about NotSupportedError when the protocol doesn't support it, but it seems
>> better to behave as if the feature doesn't exist at all.
>>
>>
> The property is protected by WebTransportCustomCertificates
> ,
> so when we enable only WebTransport, the property will be invisible.
>

Great, thanks for confirming!


> Looking through some other issues:
>>
>>- Can https://github.com/w3c/webtransport/issues/59 be resolved for
>>the WebPKI case? If CSP currently has no effect, then adding it on later
>>could be hard because some sites could already be using CSP that would
>>block it, and those sites would be broken by adding CSP support later.
>>
>>
> Yes I think so. We check the "connect-src" directive. It is tested as
> csp-fail.https.window.js
> 
> and csp-pass.window.js
> 
> .
>

That's good, the risk I was worried about doesn't exist then. Would you
consider that this behavior is required by some spec, even though it's not
mentioned in https://w3c.github.io/webtransport/? If not, then do you think
it's reasonable to prioritize the spec work for this before this reaches
stable?


>>- https://github.com/w3c/webtransport/issues/175 sounds editorial but
>>doesn't have that label. If any code would change as a result of fixing 
>> it,
>>should this be done before shipping?
>>
>> I think this is to describe our current protection and won't affect
> implementation.
>
>
>>
>>- https://github.com/w3c/webtransport/issues/236 has no discussion,
>>could it have any impact on implementation?
>>
>> This is about how to describe algorithms in the spec 

Re: [blink-dev] Intent to Ship: WebTransport

[Yutaka Hirano]

Thank you!

On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt 
wrote:

> On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano  wrote:
>
>>
>>
>> On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt 
>> wrote:
>>
>>> On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano 
>>> wrote:
>>>
 Hi Philip,

 Sorry for the belated reply. Comments inline:

 On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt 
 wrote:

> Hi again,
>
> I've made a full pass of the intent now. I have a lot of questions,
> but am pretty convinced we should ship this, it's just a matter of what
> things need to block that, and what things can be left until later.
>
> Comments inline...
>
> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano 
> wrote:
>
>> Contact emails
>>
>> yhir...@chromium.org, vasi...@chromium.org
>>
>> Explainer
>>
>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>
>> Specification
>>
>> https://w3c.github.io/webtransport
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>>
>
> I skimmed https://github.com/w3c/webtransport/issues/ and see
> multiple issues filed by other browser vendors. Are any of the remaining
> issues ones that could change the API's shape or behavior? It would be 
> good
> to resolve any such issues, since they won't be possible to address once
> the API is locked in by sites depending on it.
>
>
 I believe we've addressed issues that may require breaking changes. You
 can see open /closed
  issues for
 the initial launch (this intent).  I shared our plan
 
  at a WG meeting in May
 
  and
 we've been working to find and resolve such issues since then.

>>>
>>> I see, creating a milestone for this is really handy! Are the remaining
>>> issue in https://github.com/w3c/webtransport/milestone/1 not blocking
>>> then, even issue #349 ?
>>>
>>
>> *Except for issue #349* we have consensus on discussions. As Victor
>> commented in this thread, we can ship WebTransport *except for *
>> customeCertificationHashes
>> 
>>  if
>> needed.
>>
>
> If custom certificates is a nice-to-have then shipping without it seems
> fine to me. That would mean removing serverCertificateHashes from the
> dictionary, right? I ask because the spec also says something
> about NotSupportedError when the protocol doesn't support it, but it seems
> better to behave as if the feature doesn't exist at all.
>
>
The property is protected by WebTransportCustomCertificates
,
so when we enable only WebTransport, the property will be invisible.




> Looking through some other issues:
>
>- Can https://github.com/w3c/webtransport/issues/59 be resolved for
>the WebPKI case? If CSP currently has no effect, then adding it on later
>could be hard because some sites could already be using CSP that would
>block it, and those sites would be broken by adding CSP support later.
>
>
Yes I think so. We check the "connect-src" directive. It is tested as
csp-fail.https.window.js

and csp-pass.window.js

.


>- https://github.com/w3c/webtransport/issues/175 sounds editorial but
>doesn't have that label. If any code would change as a result of fixing it,
>should this be done before shipping?
>
> I think this is to describe our current protection and won't affect
implementation.


>
>- https://github.com/w3c/webtransport/issues/236 has no discussion,
>could it have any impact on implementation?
>
> This is about how to describe algorithms in the spec in terms of
threading, and this won't impact implementation.


>
>-
>
> Having consensus on the issues is great, but some things are still much
> harder to fix after shipping, or harder to get prioritized after shipping,
> so that's why I'm asking.
>
> Activation
>>
>> Since UDP is often blocked on the network, the developers have to
>> assume that the API often would not work even in the situations when it 
>> is
>> implemented in the browser.
>>
>
> This is interesting. How do web develope

Re: [blink-dev] Intent to Ship: WebTransport

[Philip Jägenstedt]

On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano  wrote:

>
>
> On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt 
> wrote:
>
>> On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano 
>> wrote:
>>
>>> Hi Philip,
>>>
>>> Sorry for the belated reply. Comments inline:
>>>
>>> On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt 
>>> wrote:
>>>
 Hi again,

 I've made a full pass of the intent now. I have a lot of questions, but
 am pretty convinced we should ship this, it's just a matter of what things
 need to block that, and what things can be left until later.

 Comments inline...

 On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano 
 wrote:

> Contact emails
>
> yhir...@chromium.org, vasi...@chromium.org
>
> Explainer
>
> https://github.com/w3c/webtransport/blob/main/explainer.md
>
> Specification
>
> https://w3c.github.io/webtransport
>
> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>
> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>

 I skimmed https://github.com/w3c/webtransport/issues/ and see multiple
 issues filed by other browser vendors. Are any of the remaining issues ones
 that could change the API's shape or behavior? It would be good to resolve
 any such issues, since they won't be possible to address once the API is
 locked in by sites depending on it.


>>> I believe we've addressed issues that may require breaking changes. You
>>> can see open /closed
>>>  issues for
>>> the initial launch (this intent).  I shared our plan
>>> 
>>>  at a WG meeting in May
>>> 
>>>  and
>>> we've been working to find and resolve such issues since then.
>>>
>>
>> I see, creating a milestone for this is really handy! Are the remaining
>> issue in https://github.com/w3c/webtransport/milestone/1 not blocking
>> then, even issue #349 ?
>>
>
> *Except for issue #349* we have consensus on discussions. As Victor
> commented in this thread, we can ship WebTransport *except for *
> customeCertificationHashes
> 
>  if
> needed.
>

If custom certificates is a nice-to-have then shipping without it seems
fine to me. That would mean removing serverCertificateHashes from the
dictionary, right? I ask because the spec also says something
about NotSupportedError when the protocol doesn't support it, but it seems
better to behave as if the feature doesn't exist at all.

Looking through some other issues:

   - Can https://github.com/w3c/webtransport/issues/59 be resolved for the
   WebPKI case? If CSP currently has no effect, then adding it on later could
   be hard because some sites could already be using CSP that would block it,
   and those sites would be broken by adding CSP support later.
   - https://github.com/w3c/webtransport/issues/175 sounds editorial but
   doesn't have that label. If any code would change as a result of fixing it,
   should this be done before shipping?
   - https://github.com/w3c/webtransport/issues/236 has no discussion,
   could it have any impact on implementation?

Having consensus on the issues is great, but some things are still much
harder to fix after shipping, or harder to get prioritized after shipping,
so that's why I'm asking.

Activation
>
> Since UDP is often blocked on the network, the developers have to
> assume that the API often would not work even in the situations when it is
> implemented in the browser.
>

 This is interesting. How do web developers detect and deal with this
 situation, and distinguish it from the network temporarily going down? I've
 skimmed https://web.dev/webtransport/ and it doesn't mention this kind
 of blocking, does this need to be highlighted in documentation and
 reference docs for WebTransport?

>>>
>>> For usual loading browsers detect the network conditions and choose the
>>> right version (HTTP/3, HTTP/2 and HTTP/1.1). We may be able to do similar
>>> things in the future (on the other hand, we may end up asking web
>>> developers to detect it). Some people are working on WebTransport over
>>> HTTP/2 .
>>>
>>
>> With the implementation as it is now, what will the behavior be on a
>> network where UDP is blocked? Presumably the initial connection that serves
>> HTML and scripts has then been negotiated to HTTP/2 or HTTP/1.1, but is
>> there any indication in the API that WebTransport is going to fail ahead of
>> time, or error that c

Re: [blink-dev] Intent to Ship: WebTransport

[Yutaka Hirano]

Hi, are there any unanswered questions? Or, do you have more comments or
questions?

We are open to ship this feature *without* the custom certificate part,
which means shipping this feature and continuing discussing issue #349
.

Thanks,

On Tue, Oct 5, 2021 at 10:20 PM Yutaka Hirano  wrote:

>
>
> On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt 
> wrote:
>
>> On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano 
>> wrote:
>>
>>> Hi Philip,
>>>
>>> Sorry for the belated reply. Comments inline:
>>>
>>> On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt 
>>> wrote:
>>>
 Hi again,

 I've made a full pass of the intent now. I have a lot of questions, but
 am pretty convinced we should ship this, it's just a matter of what things
 need to block that, and what things can be left until later.

 Comments inline...

 On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano 
 wrote:

> Contact emails
>
> yhir...@chromium.org, vasi...@chromium.org
>
> Explainer
>
> https://github.com/w3c/webtransport/blob/main/explainer.md
>
> Specification
>
> https://w3c.github.io/webtransport
>
> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>
> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>

 I skimmed https://github.com/w3c/webtransport/issues/ and see multiple
 issues filed by other browser vendors. Are any of the remaining issues ones
 that could change the API's shape or behavior? It would be good to resolve
 any such issues, since they won't be possible to address once the API is
 locked in by sites depending on it.


>>> I believe we've addressed issues that may require breaking changes. You
>>> can see open /closed
>>>  issues for
>>> the initial launch (this intent).  I shared our plan
>>> 
>>>  at a WG meeting in May
>>> 
>>>  and
>>> we've been working to find and resolve such issues since then.
>>>
>>
>> I see, creating a milestone for this is really handy! Are the remaining
>> issue in https://github.com/w3c/webtransport/milestone/1 not blocking
>> then, even issue #349 ?
>>
>
> *Except for issue #349* we have consensus on discussions. As Victor
> commented in this thread, we can ship WebTransport *except for *
> customeCertificationHashes
> 
>  if
> needed.
>
>
>>
>> Activation
>
> Since UDP is often blocked on the network, the developers have to
> assume that the API often would not work even in the situations when it is
> implemented in the browser.
>

 This is interesting. How do web developers detect and deal with this
 situation, and distinguish it from the network temporarily going down? I've
 skimmed https://web.dev/webtransport/ and it doesn't mention this kind
 of blocking, does this need to be highlighted in documentation and
 reference docs for WebTransport?

>>>
>>> For usual loading browsers detect the network conditions and choose the
>>> right version (HTTP/3, HTTP/2 and HTTP/1.1). We may be able to do similar
>>> things in the future (on the other hand, we may end up asking web
>>> developers to detect it). Some people are working on WebTransport over
>>> HTTP/2 .
>>>
>>
>> With the implementation as it is now, what will the behavior be on a
>> network where UDP is blocked? Presumably the initial connection that serves
>> HTML and scripts has then been negotiated to HTTP/2 or HTTP/1.1, but is
>> there any indication in the API that WebTransport is going to fail ahead of
>> time, or error that can be distinguished from an intermittent network
>> error? I'm thinking of the code to fall back to WebSockets that might be
>> necessary here, how one would determine that the fallback is needed.
>>
>
> To prevent malicious web developers from sniffing the network conditions,
> we don't expose detailed network error information to web developers when
> session establishment fails.
> So currently web developers can 1) retry establishing a session with a
> fallback protocol (e.g., WebSocket), or 2) race two (or more?) session
> establishment operations.
> Of course, web apps can use other information such as the results of past
> attempts, geolocation information, and so on.
>
> The current way is very primitive, and we may be able to provide more
> sophisticated means in the future.
>
>
>> Speaking of reference docs... Getting a feature document

Re: [blink-dev] Intent to Ship: WebTransport

[Yutaka Hirano]

On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt 
wrote:

> On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano  wrote:
>
>> Hi Philip,
>>
>> Sorry for the belated reply. Comments inline:
>>
>> On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt 
>> wrote:
>>
>>> Hi again,
>>>
>>> I've made a full pass of the intent now. I have a lot of questions, but
>>> am pretty convinced we should ship this, it's just a matter of what things
>>> need to block that, and what things can be left until later.
>>>
>>> Comments inline...
>>>
>>> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano 
>>> wrote:
>>>
 Contact emails

 yhir...@chromium.org, vasi...@chromium.org

 Explainer

 https://github.com/w3c/webtransport/blob/main/explainer.md

 Specification

 https://w3c.github.io/webtransport

 https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/

 https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/

>>>
>>> I skimmed https://github.com/w3c/webtransport/issues/ and see multiple
>>> issues filed by other browser vendors. Are any of the remaining issues ones
>>> that could change the API's shape or behavior? It would be good to resolve
>>> any such issues, since they won't be possible to address once the API is
>>> locked in by sites depending on it.
>>>
>>>
>> I believe we've addressed issues that may require breaking changes. You
>> can see open /closed
>>  issues for
>> the initial launch (this intent).  I shared our plan
>> 
>>  at a WG meeting in May
>> 
>>  and
>> we've been working to find and resolve such issues since then.
>>
>
> I see, creating a milestone for this is really handy! Are the remaining
> issue in https://github.com/w3c/webtransport/milestone/1 not blocking
> then, even issue #349 ?
>

*Except for issue #349* we have consensus on discussions. As Victor
commented in this thread, we can ship WebTransport *except for *
customeCertificationHashes

if
needed.


>
> Activation

 Since UDP is often blocked on the network, the developers have to
 assume that the API often would not work even in the situations when it is
 implemented in the browser.

>>>
>>> This is interesting. How do web developers detect and deal with this
>>> situation, and distinguish it from the network temporarily going down? I've
>>> skimmed https://web.dev/webtransport/ and it doesn't mention this kind
>>> of blocking, does this need to be highlighted in documentation and
>>> reference docs for WebTransport?
>>>
>>
>> For usual loading browsers detect the network conditions and choose the
>> right version (HTTP/3, HTTP/2 and HTTP/1.1). We may be able to do similar
>> things in the future (on the other hand, we may end up asking web
>> developers to detect it). Some people are working on WebTransport over
>> HTTP/2 .
>>
>
> With the implementation as it is now, what will the behavior be on a
> network where UDP is blocked? Presumably the initial connection that serves
> HTML and scripts has then been negotiated to HTTP/2 or HTTP/1.1, but is
> there any indication in the API that WebTransport is going to fail ahead of
> time, or error that can be distinguished from an intermittent network
> error? I'm thinking of the code to fall back to WebSockets that might be
> necessary here, how one would determine that the fallback is needed.
>

To prevent malicious web developers from sniffing the network conditions,
we don't expose detailed network error information to web developers when
session establishment fails.
So currently web developers can 1) retry establishing a session with a
fallback protocol (e.g., WebSocket), or 2) race two (or more?) session
establishment operations.
Of course, web apps can use other information such as the results of past
attempts, geolocation information, and so on.

The current way is very primitive, and we may be able to provide more
sophisticated means in the future.


> Speaking of reference docs... Getting a feature documented on MDN isn't
>>> part of the Blink launch process, but are you working with anyone to get it
>>> documented by the time the feature reaches Chrome stable?
>>>
>>>
>> I haven't talked with anyone. Do you have a good idea?
>>
>
> As I said this isn't a required part of the launch process, but +Joe
> Medley  knows the documentation process very well.
> Joe, where would you suggest to start in order to ensure a feature becomes
> documented on MDN around the time it reaches stable?

Re: [blink-dev] Intent to Ship: WebTransport

[Philip Jägenstedt]

On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano  wrote:

> Hi Philip,
>
> Sorry for the belated reply. Comments inline:
>
> On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt 
> wrote:
>
>> Hi again,
>>
>> I've made a full pass of the intent now. I have a lot of questions, but
>> am pretty convinced we should ship this, it's just a matter of what things
>> need to block that, and what things can be left until later.
>>
>> Comments inline...
>>
>> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano 
>> wrote:
>>
>>> Contact emails
>>>
>>> yhir...@chromium.org, vasi...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>>
>>> Specification
>>>
>>> https://w3c.github.io/webtransport
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>>>
>>
>> I skimmed https://github.com/w3c/webtransport/issues/ and see multiple
>> issues filed by other browser vendors. Are any of the remaining issues ones
>> that could change the API's shape or behavior? It would be good to resolve
>> any such issues, since they won't be possible to address once the API is
>> locked in by sites depending on it.
>>
>>
> I believe we've addressed issues that may require breaking changes. You
> can see open /closed
>  issues for the
> initial launch (this intent).  I shared our plan
> 
>  at a WG meeting in May
> 
>  and
> we've been working to find and resolve such issues since then.
>

I see, creating a milestone for this is really handy! Are the remaining
issue in https://github.com/w3c/webtransport/milestone/1 not blocking then,
even issue #349 ?

Activation
>>>
>>> Since UDP is often blocked on the network, the developers have to assume
>>> that the API often would not work even in the situations when it is
>>> implemented in the browser.
>>>
>>
>> This is interesting. How do web developers detect and deal with this
>> situation, and distinguish it from the network temporarily going down? I've
>> skimmed https://web.dev/webtransport/ and it doesn't mention this kind
>> of blocking, does this need to be highlighted in documentation and
>> reference docs for WebTransport?
>>
>
> For usual loading browsers detect the network conditions and choose the
> right version (HTTP/3, HTTP/2 and HTTP/1.1). We may be able to do similar
> things in the future (on the other hand, we may end up asking web
> developers to detect it). Some people are working on WebTransport over
> HTTP/2 .
>

With the implementation as it is now, what will the behavior be on a
network where UDP is blocked? Presumably the initial connection that serves
HTML and scripts has then been negotiated to HTTP/2 or HTTP/1.1, but is
there any indication in the API that WebTransport is going to fail ahead of
time, or error that can be distinguished from an intermittent network
error? I'm thinking of the code to fall back to WebSockets that might be
necessary here, how one would determine that the fallback is needed.

Speaking of reference docs... Getting a feature documented on MDN isn't
>> part of the Blink launch process, but are you working with anyone to get it
>> documented by the time the feature reaches Chrome stable?
>>
>>
> I haven't talked with anyone. Do you have a good idea?
>

As I said this isn't a required part of the launch process, but +Joe Medley
 knows the documentation process very well. Joe, where
would you suggest to start in order to ensure a feature becomes documented
on MDN around the time it reaches stable?

-- 
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeOwNUPUcG1eREVNXQDzKk24yXWmMQRcp4rNZx9mRDfGw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebTransport

[Yutaka Hirano]

On Mon, Oct 4, 2021 at 3:49 PM Yang Guo  wrote:

> Thank you for thinking about debuggability! I understand the rationale
> behind not providing more details. Would it make sense though to link to
> chrome://net-export from DevTools' Network Panel?
>
> Actually after implementing the minimal support we asked if there were
more requests on this front
.
There were no requests at that time, and I thought web developers might
want more debugging features after we ship the feature. We're open to add
more debugging features if there is a strong demand.

> Would it make sense though to link to chrome://net-export from DevTools'
Network Panel?
Interesting. How can we do that?




> On Sunday, October 3, 2021 at 2:32:53 AM UTC+2 Victor Vasiliev wrote:
>
>> On Thu, Sep 30, 2021 at 6:31 AM Philip Jägenstedt 
>> wrote:
>>
>>> Our launch process docs
>>>  says "You should
>>> have TAG sign-off on your API design by now" but I consider this a bug in
>>> the process docs. The request was sent on Aug 19 and has no feedback yet, I
>>> don't think we should block this intent on TAG review. If it happens soon
>>> enough, it would of course still be important to take it into account and
>>> possibly make adjustments before the feature reaches stable.
>>>
>>
>> Note that this has already received an early design review from TAG at <
>> https://github.com/w3ctag/design-reviews/issues/389>, though the draft
>> did change quite a bit since that happened.
>>
>

-- 
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6G%2BjhYJp5pq_fMebGr0-ezMMmV3UzfL-32DewSLEjYX5A%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebTransport

['Yang Guo' via blink-dev]

Thank you for thinking about debuggability! I understand the rationale 
behind not providing more details. Would it make sense though to link to 
chrome://net-export from DevTools' Network Panel? 

On Sunday, October 3, 2021 at 2:32:53 AM UTC+2 Victor Vasiliev wrote:

> On Thu, Sep 30, 2021 at 6:31 AM Philip Jägenstedt  
> wrote:
>
>> Our launch process docs 
>>  says "You should 
>> have TAG sign-off on your API design by now" but I consider this a bug in 
>> the process docs. The request was sent on Aug 19 and has no feedback yet, I 
>> don't think we should block this intent on TAG review. If it happens soon 
>> enough, it would of course still be important to take it into account and 
>> possibly make adjustments before the feature reaches stable.
>>
>
> Note that this has already received an early design review from TAG at <
> https://github.com/w3ctag/design-reviews/issues/389>, though the draft 
> did change quite a bit since that happened.
>

-- 
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/07aa2294-d04f-4729-bc57-9a244d280fc1n%40chromium.org.

Re: [blink-dev] Intent to Ship: WebTransport

['Victor Vasiliev' via blink-dev]

On Thu, Sep 30, 2021 at 6:31 AM Philip Jägenstedt 
wrote:

> Our launch process docs
>  says "You should have
> TAG sign-off on your API design by now" but I consider this a bug in the
> process docs. The request was sent on Aug 19 and has no feedback yet, I
> don't think we should block this intent on TAG review. If it happens soon
> enough, it would of course still be important to take it into account and
> possibly make adjustments before the feature reaches stable.
>

Note that this has already received an early design review from TAG at <
https://github.com/w3ctag/design-reviews/issues/389>, though the draft did
change quite a bit since that happened.

-- 
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAZdMaciagCV708%2B6b7xn5_81gROEtzbS1fUQudhJX7RqVLjJA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebTransport

[Yutaka Hirano]

Hi Philip,

Sorry for the belated reply. Comments inline:

On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt 
wrote:

> Hi again,
>
> I've made a full pass of the intent now. I have a lot of questions, but am
> pretty convinced we should ship this, it's just a matter of what things
> need to block that, and what things can be left until later.
>
> Comments inline...
>
> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano 
> wrote:
>
>> Contact emails
>>
>> yhir...@chromium.org, vasi...@chromium.org
>>
>> Explainer
>>
>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>
>> Specification
>>
>> https://w3c.github.io/webtransport
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>>
>
> I skimmed https://github.com/w3c/webtransport/issues/ and see multiple
> issues filed by other browser vendors. Are any of the remaining issues ones
> that could change the API's shape or behavior? It would be good to resolve
> any such issues, since they won't be possible to address once the API is
> locked in by sites depending on it.
>
>
I believe we've addressed issues that may require breaking changes. You can
see open /closed
 issues for the
initial launch (this intent).  I shared our plan

 at a WG meeting in May

and
we've been working to find and resolve such issues since then.



> Design docs
>>
>> https://web.dev/webtransport/
>>
>>
>> https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit
>>
>> Summary
>>
>> WebTransport is an interface representing a set of reliable/unreliable
>> streams to a server. The interface potentially supports multiple protocols,
>> but based on discussions on the IETF webtrans working group, we are
>> developing WebTransport over HTTP/3 which uses HTTP3 as the underlying
>> protocol.
>>
>> This time, we want to ship the core part. The following features are
>> excluded:
>>
>>-
>>
>>Connection sharing
>>-
>>
>>Stream Prioritization
>>-
>>
>>Statistics
>>-
>>
>>WebTransport over HTTP/2
>>
>>
>> Blink component
>>
>> Blink>Network>WebTransport
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/669
>>
>> TAG review status
>>
>> Pending
>>
>
> Our launch process docs
>  says "You should have
> TAG sign-off on your API design by now" but I consider this a bug in the
> process docs. The request was sent on Aug 19 and has no feedback yet, I
> don't think we should block this intent on TAG review. If it happens soon
> enough, it would of course still be important to take it into account and
> possibly make adjustments before the feature reaches stable.
>
>
Ack.




> Risks
>>
>> Interoperability and Compatibility
>>
>> This is a new API and doesn’t change any existing behaviors.
>>
>> Gecko: Worth Prototyping
>> . They are
>> actively involved in the specification effort.
>>
>> WebKit: No signal
>> 
>> .
>>
>
> How about the technologies that WebTransport depends on? Per
> https://caniuse.com/http3, it's shipped in Firefox and experimental in
> Safari. Are you aware of any likely problems getting HTTP/3 itself into all
> browsers? If HTTP/3 is on a good track, that reduces the risk here.
>
>
I'm not aware of any problems.

With an HTTP/3 implementation (and Streams API) any browsers can implement
the API in a reasonable timeframe I believe.


> Web developers: Positive
>>
>> Twitch
>>
>> https://twitch.tv
>>
>>
>>
>> Twitch is using WebTransport to serve live video to our users with lower
>> latency and higher quality. We plan on rolling out our new playback
>> experience once it's fully available given our positive results.
>>
>>
>>
>> WebTransport offers all of the benefits of QUIC, but in a browser
>> environment and without the constraints of HTTP semantics. Most notably we
>> can push data over multiple streams, eliminating head-of-line blocking and
>> enabling new functionality during congestion. This is not possible with
>> existing browser standards such as WebSockets and WebRTC data channels.
>>
>> Google Stadia
>>
>> https://stadia.google.com/
>>
>> “Google Stadia is using the WebTransport API in conjunction with the
>> WebCodecs API for several use cases, both internally and with partners. The
>> underlying WebTransport protocol, QUIC, has far greater throughput and
>> resiliency characteristics than other mechanisms available, which enables
>> use cases like webcams, and transmission of results of browser-b

Re: [blink-dev] Intent to Ship: WebTransport

[Martin Thomson]

Given where things stand with issue 349, perhaps you might consider
excluding that from the implementation.  It's an extension that can be
added later very easily.

On Thu, Sep 30, 2021 at 9:22 PM Mike West  wrote:

> Like Philip, I think this is a useful mechanism, and I'd like to see it
> ship. I'm also happy with the work that's gone into it through now, and
> thankful that folks have been proactive both in terms of testing and
> outreach to security and privacy folks.
>
> Like Emily, I think questions like
> https://github.com/w3c/webtransport/issues/349 are critical to get right,
> and will be hard to change once we've shipped. I'd like to see that in
> particular resolved before moving forward.
> https://github.com/w3c/webtransport/issues/332 would also be lovely to
> resolve.
>
> -mike
>
>
> On Thu, Sep 30, 2021 at 12:31 PM Philip Jägenstedt 
> wrote:
>
>> Hi again,
>>
>> I've made a full pass of the intent now. I have a lot of questions, but
>> am pretty convinced we should ship this, it's just a matter of what things
>> need to block that, and what things can be left until later.
>>
>> Comments inline...
>>
>> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano 
>> wrote:
>>
>>> Contact emails
>>>
>>> yhir...@chromium.org, vasi...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>>
>>> Specification
>>>
>>> https://w3c.github.io/webtransport
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>>>
>>
>> I skimmed https://github.com/w3c/webtransport/issues/ and see multiple
>> issues filed by other browser vendors. Are any of the remaining issues ones
>> that could change the API's shape or behavior? It would be good to resolve
>> any such issues, since they won't be possible to address once the API is
>> locked in by sites depending on it.
>>
>> Design docs
>>>
>>> https://web.dev/webtransport/
>>>
>>>
>>> https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit
>>>
>>> Summary
>>>
>>> WebTransport is an interface representing a set of reliable/unreliable
>>> streams to a server. The interface potentially supports multiple protocols,
>>> but based on discussions on the IETF webtrans working group, we are
>>> developing WebTransport over HTTP/3 which uses HTTP3 as the underlying
>>> protocol.
>>>
>>> This time, we want to ship the core part. The following features are
>>> excluded:
>>>
>>>-
>>>
>>>Connection sharing
>>>-
>>>
>>>Stream Prioritization
>>>-
>>>
>>>Statistics
>>>-
>>>
>>>WebTransport over HTTP/2
>>>
>>>
>>> Blink component
>>>
>>> Blink>Network>WebTransport
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/669
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>
>> Our launch process docs
>>  says "You should
>> have TAG sign-off on your API design by now" but I consider this a bug in
>> the process docs. The request was sent on Aug 19 and has no feedback yet, I
>> don't think we should block this intent on TAG review. If it happens soon
>> enough, it would of course still be important to take it into account and
>> possibly make adjustments before the feature reaches stable.
>>
>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> This is a new API and doesn’t change any existing behaviors.
>>>
>>> Gecko: Worth Prototyping
>>> . They are
>>> actively involved in the specification effort.
>>>
>>> WebKit: No signal
>>> 
>>> .
>>>
>>
>> How about the technologies that WebTransport depends on? Per
>> https://caniuse.com/http3, it's shipped in Firefox and experimental in
>> Safari. Are you aware of any likely problems getting HTTP/3 itself into all
>> browsers? If HTTP/3 is on a good track, that reduces the risk here.
>>
>>
>>> Web developers: Positive
>>>
>>> Twitch
>>>
>>> https://twitch.tv
>>>
>>>
>>>
>>> Twitch is using WebTransport to serve live video to our users with lower
>>> latency and higher quality. We plan on rolling out our new playback
>>> experience once it's fully available given our positive results.
>>>
>>>
>>>
>>> WebTransport offers all of the benefits of QUIC, but in a browser
>>> environment and without the constraints of HTTP semantics. Most notably we
>>> can push data over multiple streams, eliminating head-of-line blocking and
>>> enabling new functionality during congestion. This is not possible with
>>> existing browser standards such as WebSockets and WebRTC data channels.
>>>
>>> Google Stadia
>>>
>>> https://stadia.google.com/
>>>
>>> “Google Stadia is using the WebTransport API in conjunction with the
>>> WebCodecs API for several use cases, both internally and with partners. The
>>> underlying WebTransport protocol, QUIC, has far greater throughput and

Re: [blink-dev] Intent to Ship: WebTransport

[Mike West]

Like Philip, I think this is a useful mechanism, and I'd like to see it
ship. I'm also happy with the work that's gone into it through now, and
thankful that folks have been proactive both in terms of testing and
outreach to security and privacy folks.

Like Emily, I think questions like
https://github.com/w3c/webtransport/issues/349 are critical to get right,
and will be hard to change once we've shipped. I'd like to see that in
particular resolved before moving forward.
https://github.com/w3c/webtransport/issues/332 would also be lovely to
resolve.

-mike


On Thu, Sep 30, 2021 at 12:31 PM Philip Jägenstedt 
wrote:

> Hi again,
>
> I've made a full pass of the intent now. I have a lot of questions, but am
> pretty convinced we should ship this, it's just a matter of what things
> need to block that, and what things can be left until later.
>
> Comments inline...
>
> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano 
> wrote:
>
>> Contact emails
>>
>> yhir...@chromium.org, vasi...@chromium.org
>>
>> Explainer
>>
>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>
>> Specification
>>
>> https://w3c.github.io/webtransport
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>>
>
> I skimmed https://github.com/w3c/webtransport/issues/ and see multiple
> issues filed by other browser vendors. Are any of the remaining issues ones
> that could change the API's shape or behavior? It would be good to resolve
> any such issues, since they won't be possible to address once the API is
> locked in by sites depending on it.
>
> Design docs
>>
>> https://web.dev/webtransport/
>>
>>
>> https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit
>>
>> Summary
>>
>> WebTransport is an interface representing a set of reliable/unreliable
>> streams to a server. The interface potentially supports multiple protocols,
>> but based on discussions on the IETF webtrans working group, we are
>> developing WebTransport over HTTP/3 which uses HTTP3 as the underlying
>> protocol.
>>
>> This time, we want to ship the core part. The following features are
>> excluded:
>>
>>-
>>
>>Connection sharing
>>-
>>
>>Stream Prioritization
>>-
>>
>>Statistics
>>-
>>
>>WebTransport over HTTP/2
>>
>>
>> Blink component
>>
>> Blink>Network>WebTransport
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/669
>>
>> TAG review status
>>
>> Pending
>>
>
> Our launch process docs
>  says "You should have
> TAG sign-off on your API design by now" but I consider this a bug in the
> process docs. The request was sent on Aug 19 and has no feedback yet, I
> don't think we should block this intent on TAG review. If it happens soon
> enough, it would of course still be important to take it into account and
> possibly make adjustments before the feature reaches stable.
>
>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> This is a new API and doesn’t change any existing behaviors.
>>
>> Gecko: Worth Prototyping
>> . They are
>> actively involved in the specification effort.
>>
>> WebKit: No signal
>> 
>> .
>>
>
> How about the technologies that WebTransport depends on? Per
> https://caniuse.com/http3, it's shipped in Firefox and experimental in
> Safari. Are you aware of any likely problems getting HTTP/3 itself into all
> browsers? If HTTP/3 is on a good track, that reduces the risk here.
>
>
>> Web developers: Positive
>>
>> Twitch
>>
>> https://twitch.tv
>>
>>
>>
>> Twitch is using WebTransport to serve live video to our users with lower
>> latency and higher quality. We plan on rolling out our new playback
>> experience once it's fully available given our positive results.
>>
>>
>>
>> WebTransport offers all of the benefits of QUIC, but in a browser
>> environment and without the constraints of HTTP semantics. Most notably we
>> can push data over multiple streams, eliminating head-of-line blocking and
>> enabling new functionality during congestion. This is not possible with
>> existing browser standards such as WebSockets and WebRTC data channels.
>>
>> Google Stadia
>>
>> https://stadia.google.com/
>>
>> “Google Stadia is using the WebTransport API in conjunction with the
>> WebCodecs API for several use cases, both internally and with partners. The
>> underlying WebTransport protocol, QUIC, has far greater throughput and
>> resiliency characteristics than other mechanisms available, which enables
>> use cases like webcams, and transmission of results of browser-based
>> processing to applications and games in the cloud. The capability to
>> transmit datagrams to cloud endpoints enables many new use cases for Stadia
>> including communication with custom hardware endpoints. In the future we
>> hope

Re: [blink-dev] Intent to Ship: WebTransport

[Philip Jägenstedt]

Hi again,

I've made a full pass of the intent now. I have a lot of questions, but am
pretty convinced we should ship this, it's just a matter of what things
need to block that, and what things can be left until later.

Comments inline...

On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano  wrote:

> Contact emails
>
> yhir...@chromium.org, vasi...@chromium.org
>
> Explainer
>
> https://github.com/w3c/webtransport/blob/main/explainer.md
>
> Specification
>
> https://w3c.github.io/webtransport
>
> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>
> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>

I skimmed https://github.com/w3c/webtransport/issues/ and see multiple
issues filed by other browser vendors. Are any of the remaining issues ones
that could change the API's shape or behavior? It would be good to resolve
any such issues, since they won't be possible to address once the API is
locked in by sites depending on it.

Design docs
>
> https://web.dev/webtransport/
>
>
> https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit
>
> Summary
>
> WebTransport is an interface representing a set of reliable/unreliable
> streams to a server. The interface potentially supports multiple protocols,
> but based on discussions on the IETF webtrans working group, we are
> developing WebTransport over HTTP/3 which uses HTTP3 as the underlying
> protocol.
>
> This time, we want to ship the core part. The following features are
> excluded:
>
>-
>
>Connection sharing
>-
>
>Stream Prioritization
>-
>
>Statistics
>-
>
>WebTransport over HTTP/2
>
>
> Blink component
>
> Blink>Network>WebTransport
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/669
>
> TAG review status
>
> Pending
>

Our launch process docs 
says "You should have TAG sign-off on your API design by now" but I
consider this a bug in the process docs. The request was sent on Aug 19 and
has no feedback yet, I don't think we should block this intent on TAG
review. If it happens soon enough, it would of course still be important to
take it into account and possibly make adjustments before the feature
reaches stable.


> Risks
>
> Interoperability and Compatibility
>
> This is a new API and doesn’t change any existing behaviors.
>
> Gecko: Worth Prototyping
> . They are
> actively involved in the specification effort.
>
> WebKit: No signal
> 
> .
>

How about the technologies that WebTransport depends on? Per
https://caniuse.com/http3, it's shipped in Firefox and experimental in
Safari. Are you aware of any likely problems getting HTTP/3 itself into all
browsers? If HTTP/3 is on a good track, that reduces the risk here.


> Web developers: Positive
>
> Twitch
>
> https://twitch.tv
>
>
>
> Twitch is using WebTransport to serve live video to our users with lower
> latency and higher quality. We plan on rolling out our new playback
> experience once it's fully available given our positive results.
>
>
>
> WebTransport offers all of the benefits of QUIC, but in a browser
> environment and without the constraints of HTTP semantics. Most notably we
> can push data over multiple streams, eliminating head-of-line blocking and
> enabling new functionality during congestion. This is not possible with
> existing browser standards such as WebSockets and WebRTC data channels.
>
> Google Stadia
>
> https://stadia.google.com/
>
> “Google Stadia is using the WebTransport API in conjunction with the
> WebCodecs API for several use cases, both internally and with partners. The
> underlying WebTransport protocol, QUIC, has far greater throughput and
> resiliency characteristics than other mechanisms available, which enables
> use cases like webcams, and transmission of results of browser-based
> processing to applications and games in the cloud. The capability to
> transmit datagrams to cloud endpoints enables many new use cases for Stadia
> including communication with custom hardware endpoints. In the future we
> hope to explore using this API for other use cases.”
>

This is great feedback, thank you for collecting it! It looks like both
Twitch and Stadia are looking at video, where I assume that avoiding
head-of-line blocking makes it possible to scale down quality faster when
network conditions go bad. Sounds like a win for end users, ultimately!


> Ergonomics
>
> The API is built around ReadableStream/WritableStream interfaces, which
> means that its core I/O principles would be familiar to the developers who
> had already used Streams via Fetch and other APIs.
>
> The API does not use cookies, HTTP authentication or socket pooling.  This
> would help us avoid unexpected interactions with the other elements of the
> network stack.
>
> Activation
>
> Since UDP is often blocked on the networ

Re: [blink-dev] Intent to Ship: WebTransport

[Philip Jägenstedt]

On Thu, Sep 30, 2021 at 9:34 AM Yutaka Hirano  wrote:

> I think that's covered in the Summary of the intent:
>
> > This time, we want to ship the core part. The following features are
> excluded:
>
>-
>
>Connection sharing
>-
>
>Stream Prioritization
>-
>
>Statistics
>-
>
>WebTransport over HTTP/2
>
>
> So, that is intentional.
>

Sorry I missed that. Do you think bugs for each of these would be useful,
or do you not really need that bookkeeping?

How serious is the lack of HTTP/2 support for web developers? Concretely,
is this a serious enough limitation that the initial implementation should
be considered partial

on MDN/BCD?

I guess that connection sharing and stream prioritization aren't observable
to users of the API, and are simply performance improvements that will be
made later, is that right?

-- 
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfMYHgV3XhXyUvtRFk2KLxauJoLYW%2BBWdZczjt0iXqPGQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebTransport

[Yutaka Hirano]

I think that's covered in the Summary of the intent:

> This time, we want to ship the core part. The following features are
excluded:

   -

   Connection sharing
   -

   Stream Prioritization
   -

   Statistics
   -

   WebTransport over HTTP/2


So, that is intentional.


On Wed, Sep 29, 2021 at 11:25 PM Philip Jägenstedt 
wrote:

> On Wed, Sep 29, 2021 at 12:32 PM Yutaka Hirano 
> wrote:
>
>> Hi Philip,
>>
>> On Wed, Sep 29, 2021 at 6:29 PM Philip Jägenstedt 
>> wrote:
>>
>>> Hi Yutaka,
>>>
>>> This is a big new feature and a lot to go over. When looking at the
>>> spec+Blink IDL, I noticed the API didn't require secure contexts:
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1253275
>>>
>>> It looks like that's being fixed now, which is great! I'll reply again
>>> when I've spent some more time reading here.
>>>
>>
>> Thank you for pointing it out, and sorry for not fixing this earlier.
>>
>
> No worries, it's hard to spot these issues because there's no tooling
> around it.
>
> I have spotted another difference that I'm not sure if it's intentional or
> not. The spec has a getStats() method
>  which
> isn't implemented and I can't find a bug for it. Is this intentionally left
> until later, or should it be in the initial feature set?
>
> Best regards,
> Philip
>

-- 
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6HRV6oMPFU38%2BTVQ%3DAfi86uuVftq4B0serinT7UvJ%2BaMw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebTransport

[Philip Jägenstedt]

On Wed, Sep 29, 2021 at 12:32 PM Yutaka Hirano  wrote:

> Hi Philip,
>
> On Wed, Sep 29, 2021 at 6:29 PM Philip Jägenstedt 
> wrote:
>
>> Hi Yutaka,
>>
>> This is a big new feature and a lot to go over. When looking at the
>> spec+Blink IDL, I noticed the API didn't require secure contexts:
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1253275
>>
>> It looks like that's being fixed now, which is great! I'll reply again
>> when I've spent some more time reading here.
>>
>
> Thank you for pointing it out, and sorry for not fixing this earlier.
>

No worries, it's hard to spot these issues because there's no tooling
around it.

I have spotted another difference that I'm not sure if it's intentional or
not. The spec has a getStats() method
 which isn't
implemented and I can't find a bug for it. Is this intentionally left until
later, or should it be in the initial feature set?

Best regards,
Philip

-- 
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYf7oj7Nom43gsW60K1LW%3D2cH-UmJqjRrTHiaCzvg1UCbQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebTransport

[Yutaka Hirano]

Hi Philip,

On Wed, Sep 29, 2021 at 6:29 PM Philip Jägenstedt 
wrote:

> Hi Yutaka,
>
> This is a big new feature and a lot to go over. When looking at the
> spec+Blink IDL, I noticed the API didn't require secure contexts:
> https://bugs.chromium.org/p/chromium/issues/detail?id=1253275
>
> It looks like that's being fixed now, which is great! I'll reply again
> when I've spent some more time reading here.
>

Thank you for pointing it out, and sorry for not fixing this earlier.


> On Wed, Sep 29, 2021 at 12:08 AM Emily Stark  wrote:
>
>> I want to note that there are some pretty big open questions in
>> https://github.com/w3c/webtransport/issues/349. I think we might want to
>> have more restrictions on the allowed types of certificates than the spec
>> currently outlines, and introducing those restrictions after shipping the
>> feature would carry compatibility risks.
>>
>> On Sun, Sep 26, 2021 at 9:55 PM Yutaka Hirano 
>> wrote:
>>
>>> Contact emails
>>>
>>> yhir...@chromium.org, vasi...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>>
>>> Specification
>>>
>>> https://w3c.github.io/webtransport
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>>>
>>> Design docs
>>>
>>> https://web.dev/webtransport/
>>>
>>>
>>> https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit
>>>
>>> Summary
>>>
>>> WebTransport is an interface representing a set of reliable/unreliable
>>> streams to a server. The interface potentially supports multiple protocols,
>>> but based on discussions on the IETF webtrans working group, we are
>>> developing WebTransport over HTTP/3 which uses HTTP3 as the underlying
>>> protocol.
>>>
>>> This time, we want to ship the core part. The following features are
>>> excluded:
>>>
>>>-
>>>
>>>Connection sharing
>>>-
>>>
>>>Stream Prioritization
>>>-
>>>
>>>Statistics
>>>-
>>>
>>>WebTransport over HTTP/2
>>>
>>>
>>> Blink component
>>>
>>> Blink>Network>WebTransport
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/669
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> This is a new API and doesn’t change any existing behaviors.
>>>
>>> Gecko: Worth Prototyping
>>> . They are
>>> actively involved in the specification effort.
>>>
>>> WebKit: No signal
>>> 
>>> .
>>>
>>> Web developers: Positive
>>>
>>> Twitch
>>>
>>> https://twitch.tv
>>>
>>>
>>>
>>> Twitch is using WebTransport to serve live video to our users with lower
>>> latency and higher quality. We plan on rolling out our new playback
>>> experience once it's fully available given our positive results.
>>>
>>>
>>>
>>> WebTransport offers all of the benefits of QUIC, but in a browser
>>> environment and without the constraints of HTTP semantics. Most notably we
>>> can push data over multiple streams, eliminating head-of-line blocking and
>>> enabling new functionality during congestion. This is not possible with
>>> existing browser standards such as WebSockets and WebRTC data channels.
>>>
>>> Google Stadia
>>>
>>> https://stadia.google.com/
>>>
>>> “Google Stadia is using the WebTransport API in conjunction with the
>>> WebCodecs API for several use cases, both internally and with partners. The
>>> underlying WebTransport protocol, QUIC, has far greater throughput and
>>> resiliency characteristics than other mechanisms available, which enables
>>> use cases like webcams, and transmission of results of browser-based
>>> processing to applications and games in the cloud. The capability to
>>> transmit datagrams to cloud endpoints enables many new use cases for Stadia
>>> including communication with custom hardware endpoints. In the future we
>>> hope to explore using this API for other use cases.”
>>>
>>> Ergonomics
>>>
>>> The API is built around ReadableStream/WritableStream interfaces, which
>>> means that its core I/O principles would be familiar to the developers who
>>> had already used Streams via Fetch and other APIs.
>>>
>>> The API does not use cookies, HTTP authentication or socket pooling.
>>> This would help us avoid unexpected interactions with the other elements of
>>> the network stack.
>>>
>>> Activation
>>>
>>> Since UDP is often blocked on the network, the developers have to assume
>>> that the API often would not work even in the situations when it is
>>> implemented in the browser.
>>>
>>> Security
>>>
>>> See  for more
>>> info.
>>>
>>>
>>>
>>> We allow web developers to use an alternative certification verification
>>> method than the usual HTTPS way. We allow a web developer to connect to a
>>> WebTransport over HTTP/3 server when its certif

Re: [blink-dev] Intent to Ship: WebTransport

[Philip Jägenstedt]

Hi Yutaka,

This is a big new feature and a lot to go over. When looking at the
spec+Blink IDL, I noticed the API didn't require secure contexts:
https://bugs.chromium.org/p/chromium/issues/detail?id=1253275

It looks like that's being fixed now, which is great! I'll reply again when
I've spent some more time reading here.

On Wed, Sep 29, 2021 at 12:08 AM Emily Stark  wrote:

> I want to note that there are some pretty big open questions in
> https://github.com/w3c/webtransport/issues/349. I think we might want to
> have more restrictions on the allowed types of certificates than the spec
> currently outlines, and introducing those restrictions after shipping the
> feature would carry compatibility risks.
>
> On Sun, Sep 26, 2021 at 9:55 PM Yutaka Hirano 
> wrote:
>
>> Contact emails
>>
>> yhir...@chromium.org, vasi...@chromium.org
>>
>> Explainer
>>
>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>
>> Specification
>>
>> https://w3c.github.io/webtransport
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>>
>> Design docs
>>
>> https://web.dev/webtransport/
>>
>>
>> https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit
>>
>> Summary
>>
>> WebTransport is an interface representing a set of reliable/unreliable
>> streams to a server. The interface potentially supports multiple protocols,
>> but based on discussions on the IETF webtrans working group, we are
>> developing WebTransport over HTTP/3 which uses HTTP3 as the underlying
>> protocol.
>>
>> This time, we want to ship the core part. The following features are
>> excluded:
>>
>>-
>>
>>Connection sharing
>>-
>>
>>Stream Prioritization
>>-
>>
>>Statistics
>>-
>>
>>WebTransport over HTTP/2
>>
>>
>> Blink component
>>
>> Blink>Network>WebTransport
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/669
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> This is a new API and doesn’t change any existing behaviors.
>>
>> Gecko: Worth Prototyping
>> . They are
>> actively involved in the specification effort.
>>
>> WebKit: No signal
>> 
>> .
>>
>> Web developers: Positive
>>
>> Twitch
>>
>> https://twitch.tv
>>
>>
>>
>> Twitch is using WebTransport to serve live video to our users with lower
>> latency and higher quality. We plan on rolling out our new playback
>> experience once it's fully available given our positive results.
>>
>>
>>
>> WebTransport offers all of the benefits of QUIC, but in a browser
>> environment and without the constraints of HTTP semantics. Most notably we
>> can push data over multiple streams, eliminating head-of-line blocking and
>> enabling new functionality during congestion. This is not possible with
>> existing browser standards such as WebSockets and WebRTC data channels.
>>
>> Google Stadia
>>
>> https://stadia.google.com/
>>
>> “Google Stadia is using the WebTransport API in conjunction with the
>> WebCodecs API for several use cases, both internally and with partners. The
>> underlying WebTransport protocol, QUIC, has far greater throughput and
>> resiliency characteristics than other mechanisms available, which enables
>> use cases like webcams, and transmission of results of browser-based
>> processing to applications and games in the cloud. The capability to
>> transmit datagrams to cloud endpoints enables many new use cases for Stadia
>> including communication with custom hardware endpoints. In the future we
>> hope to explore using this API for other use cases.”
>>
>> Ergonomics
>>
>> The API is built around ReadableStream/WritableStream interfaces, which
>> means that its core I/O principles would be familiar to the developers who
>> had already used Streams via Fetch and other APIs.
>>
>> The API does not use cookies, HTTP authentication or socket pooling.
>> This would help us avoid unexpected interactions with the other elements of
>> the network stack.
>>
>> Activation
>>
>> Since UDP is often blocked on the network, the developers have to assume
>> that the API often would not work even in the situations when it is
>> implemented in the browser.
>>
>> Security
>>
>> See  for more
>> info.
>>
>>
>>
>> We allow web developers to use an alternative certification verification
>> method than the usual HTTPS way. We allow a web developer to connect to a
>> WebTransport over HTTP/3 server when its certificate’s fingerprint matches
>> with the developer provided fingerprint. This is discussed at
>> https://github.com/w3c/webtransport/issues/349 and we will update the
>> spec shortly.
>>
>> Debuggability
>>
>> Printing an error message with the reason when the opening handshake
>> fails.
>>
>> We show out

Re: [blink-dev] Intent to Ship: WebTransport

[Emily Stark]

I want to note that there are some pretty big open questions in
https://github.com/w3c/webtransport/issues/349. I think we might want to
have more restrictions on the allowed types of certificates than the spec
currently outlines, and introducing those restrictions after shipping the
feature would carry compatibility risks.

On Sun, Sep 26, 2021 at 9:55 PM Yutaka Hirano  wrote:

> Contact emails
>
> yhir...@chromium.org, vasi...@chromium.org
>
> Explainer
>
> https://github.com/w3c/webtransport/blob/main/explainer.md
>
> Specification
>
> https://w3c.github.io/webtransport
>
> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>
> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>
> Design docs
>
> https://web.dev/webtransport/
>
>
> https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit
>
> Summary
>
> WebTransport is an interface representing a set of reliable/unreliable
> streams to a server. The interface potentially supports multiple protocols,
> but based on discussions on the IETF webtrans working group, we are
> developing WebTransport over HTTP/3 which uses HTTP3 as the underlying
> protocol.
>
> This time, we want to ship the core part. The following features are
> excluded:
>
>-
>
>Connection sharing
>-
>
>Stream Prioritization
>-
>
>Statistics
>-
>
>WebTransport over HTTP/2
>
>
> Blink component
>
> Blink>Network>WebTransport
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/669
>
> TAG review status
>
> Pending
>
> Risks
>
> Interoperability and Compatibility
>
> This is a new API and doesn’t change any existing behaviors.
>
> Gecko: Worth Prototyping
> . They are
> actively involved in the specification effort.
>
> WebKit: No signal
> 
> .
>
> Web developers: Positive
>
> Twitch
>
> https://twitch.tv
>
>
>
> Twitch is using WebTransport to serve live video to our users with lower
> latency and higher quality. We plan on rolling out our new playback
> experience once it's fully available given our positive results.
>
>
>
> WebTransport offers all of the benefits of QUIC, but in a browser
> environment and without the constraints of HTTP semantics. Most notably we
> can push data over multiple streams, eliminating head-of-line blocking and
> enabling new functionality during congestion. This is not possible with
> existing browser standards such as WebSockets and WebRTC data channels.
>
> Google Stadia
>
> https://stadia.google.com/
>
> “Google Stadia is using the WebTransport API in conjunction with the
> WebCodecs API for several use cases, both internally and with partners. The
> underlying WebTransport protocol, QUIC, has far greater throughput and
> resiliency characteristics than other mechanisms available, which enables
> use cases like webcams, and transmission of results of browser-based
> processing to applications and games in the cloud. The capability to
> transmit datagrams to cloud endpoints enables many new use cases for Stadia
> including communication with custom hardware endpoints. In the future we
> hope to explore using this API for other use cases.”
>
> Ergonomics
>
> The API is built around ReadableStream/WritableStream interfaces, which
> means that its core I/O principles would be familiar to the developers who
> had already used Streams via Fetch and other APIs.
>
> The API does not use cookies, HTTP authentication or socket pooling.  This
> would help us avoid unexpected interactions with the other elements of the
> network stack.
>
> Activation
>
> Since UDP is often blocked on the network, the developers have to assume
> that the API often would not work even in the situations when it is
> implemented in the browser.
>
> Security
>
> See  for more
> info.
>
>
>
> We allow web developers to use an alternative certification verification
> method than the usual HTTPS way. We allow a web developer to connect to a
> WebTransport over HTTP/3 server when its certificate’s fingerprint matches
> with the developer provided fingerprint. This is discussed at
> https://github.com/w3c/webtransport/issues/349 and we will update the
> spec shortly.
>
> Debuggability
>
> Printing an error message with the reason when the opening handshake fails.
>
> We show outgoing WebTransport sessions in the “Network” section of
> DevTools, the same place where WebSocket connections are shown.  Unlike
> WebSockets, we do not intend to show the actual contents of the
> WebTransport sessions, thus avoiding the performance decrease that would
> cause.
>
> Just like with regular HTTP/3-based QUIC traffic, detailed information
> about the connection can be obtained via chrome://net-export interface.
>
> Is this feature fully tested by web-platform-tests?
>
> Yes
>
> We are writing WPTs (/webtransport
> 

[blink-dev] Intent to Ship: WebTransport

[Yutaka Hirano]

Contact emails

yhir...@chromium.org, vasi...@chromium.org

Explainer

https://github.com/w3c/webtransport/blob/main/explainer.md

Specification

https://w3c.github.io/webtransport

https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/

https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/

Design docs

https://web.dev/webtransport/

https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit

Summary

WebTransport is an interface representing a set of reliable/unreliable
streams to a server. The interface potentially supports multiple protocols,
but based on discussions on the IETF webtrans working group, we are
developing WebTransport over HTTP/3 which uses HTTP3 as the underlying
protocol.

This time, we want to ship the core part. The following features are
excluded:

   -

   Connection sharing
   -

   Stream Prioritization
   -

   Statistics
   -

   WebTransport over HTTP/2


Blink component

Blink>Network>WebTransport

TAG review

https://github.com/w3ctag/design-reviews/issues/669

TAG review status

Pending

Risks

Interoperability and Compatibility

This is a new API and doesn’t change any existing behaviors.

Gecko: Worth Prototyping
. They are
actively involved in the specification effort.

WebKit: No signal
.

Web developers: Positive

Twitch

https://twitch.tv



Twitch is using WebTransport to serve live video to our users with lower
latency and higher quality. We plan on rolling out our new playback
experience once it's fully available given our positive results.



WebTransport offers all of the benefits of QUIC, but in a browser
environment and without the constraints of HTTP semantics. Most notably we
can push data over multiple streams, eliminating head-of-line blocking and
enabling new functionality during congestion. This is not possible with
existing browser standards such as WebSockets and WebRTC data channels.

Google Stadia

https://stadia.google.com/

“Google Stadia is using the WebTransport API in conjunction with the
WebCodecs API for several use cases, both internally and with partners. The
underlying WebTransport protocol, QUIC, has far greater throughput and
resiliency characteristics than other mechanisms available, which enables
use cases like webcams, and transmission of results of browser-based
processing to applications and games in the cloud. The capability to
transmit datagrams to cloud endpoints enables many new use cases for Stadia
including communication with custom hardware endpoints. In the future we
hope to explore using this API for other use cases.”

Ergonomics

The API is built around ReadableStream/WritableStream interfaces, which
means that its core I/O principles would be familiar to the developers who
had already used Streams via Fetch and other APIs.

The API does not use cookies, HTTP authentication or socket pooling.  This
would help us avoid unexpected interactions with the other elements of the
network stack.

Activation

Since UDP is often blocked on the network, the developers have to assume
that the API often would not work even in the situations when it is
implemented in the browser.

Security

See  for more info.



We allow web developers to use an alternative certification verification
method than the usual HTTPS way. We allow a web developer to connect to a
WebTransport over HTTP/3 server when its certificate’s fingerprint matches
with the developer provided fingerprint. This is discussed at
https://github.com/w3c/webtransport/issues/349 and we will update the spec
shortly.

Debuggability

Printing an error message with the reason when the opening handshake fails.

We show outgoing WebTransport sessions in the “Network” section of
DevTools, the same place where WebSocket connections are shown.  Unlike
WebSockets, we do not intend to show the actual contents of the
WebTransport sessions, thus avoiding the performance decrease that would
cause.

Just like with regular HTTP/3-based QUIC traffic, detailed information
about the connection can be obtained via chrome://net-export interface.

Is this feature fully tested by web-platform-tests?

Yes

We are writing WPTs (/webtransport
).
We expect the task to be completed by the branch point. The WebTransport
over HTTP/3 server for testing

is running locally, but we need more time to run it on wpt.live or Chromium
CI.

Requires code in //chrome?

False

Tracking bug

https://crbug.com/10111392

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4854144902889472

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group an