Hi all, sorry for my late reply but I was on holidays. I reviewed the document and have two more issues that might need addressing:
1) 0-RTT handling: Section 3 says: “An endpoint MUST NOT send DATAGRAM frames until it has received the max_datagram_frame_size transport parameter with a non-zero value.” I guess you assume that having received max_datagram_frame_size in a previous connection, when 0-RTT is used, counts but interpreting this MUST strictly, you cannot send datagrams in 0-RTT. Maybe that can be clarified. Also if datagrams are used with 0-RTT but for some reason are not supported by the server anymore, it would actually be useful to have a more specific error message if the connection is closed by the server. 2) datagram size Section 5 says: “DATAGRAM frames cannot be fragmented; therefore, application protocols need to handle cases where the maximum datagram size is limited by other factors.“ However, this section does not say what the transport should do if the application tries to send a too large datagram. Is that datagram just dropped, eventually indicating an error to the application? Would be good to explicitly spell this out. Mirja From: QUIC <[email protected]> on behalf of Lucas Pardue <[email protected]> Date: Monday, 4. October 2021 at 23:53 To: QUIC WG <[email protected]> Cc: QUIC WG Chairs <[email protected]> Subject: Re: WGLC for Datagram Extension On Mon, Oct 4, 2021 at 10:50 PM Lucas Pardue <[email protected]<mailto:[email protected]>> wrote: Hello all, Thank you to everyone that provided feedback. The editors incorporated a few editorial changes to address comments and cut an 05 draft [1]. I noticed a couple of IANA-related nits during my shepherd review writeup [2][3]. We’ll get these fixed up in a new revision and start the ball rolling on progressing the document to the IESG. Whoops, the link to the 05 draft was wrong; it should be the adopted document [1] (not the pre-adoption I-D!). Apologies. [1] - https://datatracker.ietf.org/doc/draft-ietf-quic-datagram/05/
