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/CABihn6GV9G7QbjC3FWwkOcCGbPbK-WLrv%3D2B1Rmr%2BR%3DM3QP42w%40mail.gmail.com.
