Original text:
It is recommended that "initial_max_bidi_streams" be no smaller than 100, so as to not unnecessarily limit parallelism. <del> These streams carry frames related to the request/response (see request-response).  When a stream terminates cleanly, if the last frame on the stream was truncated, this MUST be treated as a connection error (see HTTP_MALFORMED_FRAME in http-error-codes). Streams which terminate abruptly may be reset at any point in the frame. </del> HTTP/3 does not use server-initiated bidirectional streams; clients MUST omit or specify a value of zero for the QUIC transport parameter "initial_max_bidi_streams". the end of the identified fields MUST be treated as a connection error of type HTTP_MALFORMED_FRAME.  7.2. 7.2.1.

Reviewer comments:
Until now, only bidirectional streams were specified to treat a truncated last frame on a cleanly terminated stream as an error. With this pr, the same logic applies to push streams as well. I just slightly reworded the text from the bidirectional streams section and put it into the push stream section. Not sure if this is the best solution but I'm also not sure where to put the text if the text for both the bidirectional streams and push streams had to be combined.
already contains this text: That's intended to cover any stream type with frames. Perhaps we should consolidate the language from both sections into that, possibly leaving behind cross-references.
I hadn't seen that paragraph yet. I'd propose to drop the text in the Bidirectional Streams section. The reasoning is that when searching for what to do when a stream is closed with a truncated frame, I found (or rather was pointed to) the text in the Bidirectional Streams section. After finding a paragraph like that, I didn't expect to find any other text in the rfc related to truncated frames (which led to this pr). Without the text in the Bidirectional Streams section, I might have found the text in the Frame Layout section first which would have immediately answered my question. This would also consolidate errors related to frames in the HTTP Framing Layer section which seems like the first place to go looking for frame related errors. Should I make another pr (if this sounds like a good idea) or update this one with the proposed change?
Fine to just update this one. Thanks!
This is the best I could come up with. I had to relax the text from Frame Layout to allow truncated frames on abruptly closed streams. Maybe abruptly closed stream should be clarified better (I'm not sure if this is done elsewhere already?).
Reworded so as to not change the original text as much. The pr now just moves the truncation section from the streams section to the frames section.

Revised text:
It is recommended that "initial_max_bidi_streams" be no smaller than 100, so as to not unnecessarily limit parallelism.  HTTP/3 does not use server-initiated bidirectional streams; clients MUST omit or specify a value of zero for the QUIC transport parameter "initial_max_bidi_streams". the end of the identified fields MUST be treated as a connection error of type HTTP_MALFORMED_FRAME. <ins> When a stream terminates cleanly, if the last frame on the stream was truncated, this MUST be treated as a connection error (errors) of type HTTP_MALFORMED_FRAME.  Streams which terminate abruptly may be reset at any point in a frame. </ins> 7.2. 7.2.1.