Hi Jurgen, thanks for your review! Responses inline. David On Mon, Jan 31, 2022 at 12:00 AM Jürgen Schönwälder via Datatracker < [email protected]> wrote:
> - In the description of the DATAGRAM frame below Figure 1, perhaps > also describe the Type: field explicitly. Yes, the field is > described in the text preceding Figure 1, but it is usually a good > idea to describe all protocol fields separately, this makes it > easier to find and quote the relevant bits and pieces. The text > above the figure can then likely be shortened. (Perhaps there is > also no need to name the LEN bit by just referring to the frame > type, or are there are frame times that have a LEN bit?) > > Type: The DATAGRAM frame type takes values 0x30 or 0x31. If the > frame type is 0x31, the Length field is present. Otherwise, if > the frame type is 0x30, the Length field is absent and the > Datagram Data field extends to the end of the packet. > We've decided that consistency with RFC 9000 was preferable here, as the target audience has already read that document. https://datatracker.ietf.org/doc/html/rfc9000#section-19.8 - Perhaps add some text motivating why having both frame type values > is useful and detailing what implementations should do if things are > inconsistent, e.g., the Length field is larger than Datagram Data. > Similarly, this matches how QUIC STREAM frames work - the length can be omitted to save bytes when it is not necessary. https://datatracker.ietf.org/doc/html/rfc9000#section-19.8
