Draft: draft-ietf-webtrans-http2

Commentary: 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 is n'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 in 
 I think that we should remove it . The frame format is not identical to QUIC as you have lengths to all of the frames . This is a good choice , I think , but it means that you do n't have an identical parser . As we have QUIC rules for  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 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 does n'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  ? 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 . Does n't seem like it 's that sharp an edge if we remove it , but I reserve the right to grumble when I implement it .
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.
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.