> 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 <yhir...@chromium.org> wrote: > Thank you! We'll land the shipping CL > <https://chromium-review.googlesource.com/c/chromium/src/+/3208466> after > addressing TAG review comments. > > On Sat, Oct 9, 2021 at 1:07 AM Rick Byers <rby...@chromium.org> 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 <yoavwe...@chromium.org> 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 <mk...@chromium.org> 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 <yhir...@chromium.org> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Oct 7, 2021 at 5:51 PM Yutaka Hirano <yhir...@chromium.org> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Oct 7, 2021 at 5:38 PM Philip Jägenstedt <foo...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> On Thu, Oct 7, 2021 at 10:04 AM Yutaka Hirano <yhir...@chromium.org> >>>>>>> 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 <yhir...@chromium.org> >>>>>>>>> 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 >>>>>>>>>>>> <https://github.com/w3c/webtransport/milestone/1>/closed >>>>>>>>>>>> <https://github.com/w3c/webtransport/milestone/1?closed=1> issues >>>>>>>>>>>> for the initial launch (this intent). I shared our plan >>>>>>>>>>>> <https://docs.google.com/document/d/1X9-a03rtm0FqTW01nG6e7f91NAguGEv37mP964HrJlk/edit#heading=h.v9yxozj8naro> >>>>>>>>>>>> at a WG meeting in May >>>>>>>>>>>> <https://www.w3.org/wiki/WebTransport/Meetings#WebTransport_Bi-weekly_Virtual_Meeting_.2316_late_-_May_25.2C_2021> >>>>>>>>>>>> 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 >>>>>>>>>>> <https://github.com/w3c/webtransport/issues/349>? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *Except for issue #349* we have consensus on discussions. As >>>>>>>>>> Victor commented in this thread, we can ship WebTransport *except >>>>>>>>>> for *customeCertificationHashes >>>>>>>>>> <https://w3c.github.io/webtransport/#dom-webtransportoptions-servercertificatehashes> >>>>>>>>>> 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 >>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/webtransport/web_transport_options.idl>, >>>>>>>> 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 >>>>>>>> <https://github.com/web-platform-tests/wpt/blob/master/webtransport/csp-fail.https.window.js> >>>>>>>> and csp-pass.window.js >>>>>>>> <https://github.com/web-platform-tests/wpt/blob/master/webtransport/csp-pass.https.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. >>>>>> >>>>>> >>>>> >>>>> I made a PR for this: https://github.com/w3c/webtransport/pull/367 >>>>> >>>>> >>>>>> >>>>>>> >>>>>>>>> - 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. >>>>>>>> >>>>>>> >>>>>>> Again, thanks for confirming! >>>>>>> >>>>>>>> -- >>>>> 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/CABihn6HK5uwpsnVpZurqhgtzMOb%3Ddee17Aakf9COanf_E-8ioQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6HK5uwpsnVpZurqhgtzMOb%3Ddee17Aakf9COanf_E-8ioQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to blink-dev+unsubscr...@chromium.org. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdUMf59AFFVnTCYvq4h919xFJf6-9%2BOU%3DT%2B80NyD6a_RQ%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdUMf59AFFVnTCYvq4h919xFJf6-9%2BOU%3DT%2B80NyD6a_RQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to blink-dev+unsubscr...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWXezTr_63-fHJZ4A3YaEui17WxY0Aw-ARRUDmvDqyqKA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWXezTr_63-fHJZ4A3YaEui17WxY0Aw-ARRUDmvDqyqKA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6ECoRHg6GuefcJt3chRgbjmoMkM05JHwXd42JdMPmCe8g%40mail.gmail.com.
