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. > > >>> - 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/CABihn6HywQwKw4e53KPPCKw7gUz12u4aE0y6rs2ViwTxbK7iyw%40mail.gmail.com.
