Youenn: how would 'dropping' data happen?

Victor_??_Google: currently no way to ignore, UDP sockets allow ignoring by not reading from buffer (overflow)

Peter_Thatcher_Google: one of the goals is to apply back-pressure

Youenn: want to send datagram above max size, what would happen?

Victor: exception. API call will give you max size.
... closing stream semantics can help. there are a lot of higher level apis you can provide to deal with larger messages.

Peter: example in explainer shows message of arbitrary size

???: is protocol name set in constructor?

Victor: it's done using interface mixin. constructors may vary, but object must support WebTransport interface

Alex_Apple: WebSocket has handshake to prevent misuse. does this have a similar mechanism

Victor: Quic transport uses ALPN to match a specific value, without a valid value it won't work and fail the connection. Browser verifies list of domains can talk to before sending data

Jan-Ivar Mozilla: does getWriter get a different writer every time?

ricea: once stream is closed it will never be used again.

<ricea> That was me

full name would help :)

<ricea> Adam Rice

Jan Ivar: calling send datagram twice gets two streams, how do they interact (multiplex, etc.)

Victor: should only be one stream in datagrams. they should be either sent or not sent (UDP semantics)
... Goal is to use UDP semantics with flow/congestion control

????: timing data was missed with WebSockets. can metrics/stats be added to API?

Victor: some stats are there, need users to provide feedback on which stats are interesting/needed.

?????: ...fallback when you don't have UDP?

Emad_Omara_Google: will it support 0-RTT?

Victor: no support for 0-RTT. API design is hard, more complex state machine, etc.

Youenn: will WebRTC stats be reused (applicable ones)?

Victor: added the ones that we know are already useful

Steve_Anton_Google: WebRTC has a lot of stats because you are not on the data layer, this should be different because you are using the networking layer

??: how will debugging work? what about dev tools?

Victor: dev tools is planned to be supported.

Amit_Hilbuch_Google: how will this interact with p2p scenario

Peter: currently focused on Server-Client but planned

Jan Ivar: is congestion control required?

Victor: yes all streams are required to use congestion control.

??: Implemented in quic using datagram frame, data will be blocked if window is full (adding more data will cause it to be dropped)

Mark Foltz_Google: will Keep-Alive behavior be part of the transport?

Victor: connection will be kept open as long as it isn't explicitly closed (or garbage collected)

David_Google: Quic has a keep-alive mechanism.

Victor: ... multiplexing mechanism is not yet clear. this is a learning from WebSockets on url leading to http assumption.

AdrianHB: it should be easy for Http3

Victor: for http it is easy, but for quic transport it's not as clear

David: next steps for this work - do people have opinions on the best plan forward?

Jan Ivar: considered forming a WG?

Victor: eventually it will hit a WG, but it's not ready for that state yet (no real dev feedback yet)

Jan-Ivar: mozilla would support a working group

Youenn: would node js or similar frameworks use the same pattern?

Victor: have not reached out about that yet

Youenn: node js can be used for both client and server

Peter: any feedback for technical discussions? CC or BWE?

??: what happens during connection?

Victor: we need to define how it interacts with extensions

??: is the expectation that the connection initiation will carry cookies?

Victor: explicitly no, considered exposing channel bindings

??: is there expectation that a user gesture is required to initiate a connection?

Victor: currently not.

Jan Ivar: thoughts on putting this in service worker?

Victor: should be supported in service workers.

?????: is this meant to be protocol-agnostic?

Victor: there is a websocket based fallback

?: how does this interact with prioritization (multiplexing scenario)

Victor: prioritization is a hard topic in http. with http3 it behaves similar to regular http streams (scheduler provides fairness). dos + fairness are concerns

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/??/ricea/
Succeeded: s/???/Mark Foltz_Google/
Succeeded: s/????/AdrianHB/

WARNING: No "Present: ... " found!
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy
        <amy> Present+

No ScribeNick specified.  Guessing ScribeNick: JRR_Tolkien
Inferring Scribes: JRR_Tolkien

WARNING: No "Topic:" lines found.


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)