Change:
And explain the difference.
Updated for merge conflicts, merging this now since whatever the capsule discussion outcome, we know we're going to remove final size
This field isn't necessary because of the in-order, reliable delivery of the underlying transport. That said, I'm not opposed to leaving it here for symmetry with QUIC. We could also say - it's unused, or what to do if this value is different from the value computed as the size of sent data on this stream? Originally posted by NAME in URL
I think that we should remove it. The frame format is not identical to QUIC as you have added lengths to all of the frames. This is a good choice, I think, but it means that you don't have an identical parser. As we have QUIC rules for RESET_STREAM and we have in-order delivery, we can guarantee that there is no ambiguity about how much data was consumed from the "session" flow control limit, so the added field is just another thing to check.
Should we make the length be first in every frame so we can strip it and use the same parser?
That is an interesting suggestion. It is even ... Sort of ... Consistent with HTTP/2.
I guess WebTransport frames are explicitly not capsules, but they are the same as capsules, I think? Capsules are explicitly "TLV".
Yeah, I'm expecting we'll have a slide at 112 about the lengths. QUIC has them for the frames where you have something that varies in length, and I put it in every frame here. Seems like the best choices are either (a) decide that was unnecessary and take them out or (b) move them to the front to make it easier. We also need to see if it would be a capsule or not. Seems like for this issue, we need to decide whether or not we're okay keeping "useless" fields solely for the sake of looking like QUIC. If so, moving length to the front and then keeping the rest of the frame identical seems great. If not, then out with the extra and the position of length doesn't matter nearly as much. Will raise at 112 so we can settle on "useless" fields.
Do we think that WT over H2 should be using Capsules? In particular it might seem silly to have two different ways to send a DATAGRAM. If we think that all WT Frames should be capsules, and we want length up front, we need to take that up in MASQUE. Besides Final Offset, are there any other "useless" fields?
Chair notes from IETF 112 meeting: this is on hold pending which is itself on hold pending output of MASQUE HTTP Datagrams design team
Also from 112: No strong desire to keep things exactly aligned with QUIC frames, so fine to have length in any position and to remove final length.
Text is great, just holding while we decide .Of course it's not needed in this context, but the 1:1 mapping is a nice feature because it promotes code re-use with a QUIC parser. Doesn't seem like it's that sharp an edge if we remove it, but I reserve the right to grumble when I implement it.

Discussion:
A variable-length integer containing the application protocol error code that indicates why the stream is being closed. <del> Final Size: A variable-length integer indicating the final size of the stream by the WT_RESET_STREAM sender, in units of bytes.  This is the amount of flow control credit that is consumed by a stream, see Section 4.5 of RFC9000. </del> <ins> Unlike the equivalent QUIC frame, this frame does not include a Final Size field.  In-order delivery of WT_STREAM frames ensures that the amount of session-level flow control consumed by a stream is always known by both endpoints. </ins> 5.3.