Hi Carl, Thanks for the review!
To reply to your two comments: 1) DATAGRAM frames behave much like STREAM frames—they have a form with a length that can be a “middle” frame in the packet, and the have a form without a length that can only be the last frame in a packet, because the frame will extend to the end of the packet. Both forms MAY be coalesced with other frames, since there can be other frames (like a PING, ACK, etc) that go before the DATAGRAM frame. And, DATAGRAM frames that contain the length can always be put before other DATAGRAM frames. 2) I think the notion of rejecting that you refer to is more specific to 0-RTT, and isn’t a general property of transport parameters. The comment in RFC 9001 about ignoring previous transport parameter values when 0-RTT is rejected applies to all future transport parameters, including max_datagram_frame_size (which has a default of 0). Best, Tommy > On Dec 22, 2021, at 10:52 AM, Carl Wallace via Datatracker <[email protected]> > wrote: > > Reviewer: Carl Wallace > Review result: Ready > > This is a well written document. My only comments are likely due to my lack of > familiarity with QUIC. > > 1) Section 5 states "this frame SHOULD be sent as soon as possible, and MAY be > coalesced with other frames." It was not clear to me how this squared with > Section 4's "if this bit is set to 0, the Length field is absent and the > Datagram Data field extends to the end of the packet." Should the MAY be other > packets instead of frames? Or is at most one datagram frame with no length > present permitted in a packet, with it being last? > > 2) Section 3 may benefit from including words a la section 4.6.2 of RFC 9001 > regarding resetting state when max_datagram_frame_size is rejected. On first > read, it was not clear to me why this value did not latch. > >
