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 <https://github.com/w3c/webtransport/issues/349>. Thanks, On Tue, Oct 5, 2021 at 10: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. > > >> >> 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. > > >> 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 <jmed...@google.com> 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/CABihn6EivErgcO8LXEQi3niCLY1fJ43M%3D7Sw0vfdBP1uq52-oQ%40mail.gmail.com.
