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. 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 <https://github.com/ietf-wg-webtrans/draft-webtransport-http2>. >>> >> >> 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. > I see, that's unfortunate but makes sense. -- 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/CAARdPYdY0a1nCFem3QtxShUiRNi8fGUZZVZEtuf7n9aAnbj8Qg%40mail.gmail.com.
