Change:
A QUIC stream provides reliable in-order delivery of bytes, but makes no guarantees about order of delivery with regard to bytes on other <del> streams.  On the wire, the stream data containing HTTP frames is carried by QUIC STREAM frames, but this framing is invisible to the HTTP framing layer.  The transport layer buffers and orders received QUIC STREAM frames, exposing the data contained within as a reliable byte stream to the application.  Although QUIC permits out-of-order delivery within a stream, HTTP/3 does not make use of this feature. </del> <ins> streams.  In version 1 of QUIC, the stream data containing HTTP frames is carried by QUIC STREAM frames, but this framing is invisible to the HTTP framing layer.  The transport layer buffers and orders received stream data, exposing a reliable byte stream to the application.  Although QUIC permits out-of-order delivery within a stream, HTTP/3 does not make use of this feature. </ins> QUIC streams can be either unidirectional, carrying data only from initiator to receiver, or bidirectional.  Streams can be initiated by

Discussion:
I'm okay with the current text, but this talks more squarely about "version 1" and the abstraction, with the framing just being an aside. And technically, QUIC doesn't order the STREAM frames, it assembles the stream data in order, so this is more precise.
NAME said
(as an individual) clarifying that all frames defined in draft-ietf-quic-http3 are sent in QUIC STREAM frames is probably useful. This is couched in the requirement that these H3 frames explicitly depend on reliable and in-order delivery. It might be worth checking we make that clear in the spec. However, the current requirements are not invariant, we don't want to prohibit H3 extensions from utilizing transport extensions like DATAGRAM, partial reliability, or some future STREAM-frame replacement that might emerge.
The draft currently says: guarantees about order of delivery with regard to bytes on other streams. On the wire, data is framed into QUIC STREAM frames, but this framing is invisible to the HTTP framing layer. The transport layer buffers and orders received QUIC STREAM frames, exposing the data contained within as a reliable byte stream to the application. Although QUIC permits out-of-order delivery within a stream, HTTP/3 does not make use of this feature. This seems sufficient to me, though I think there's another open issue about the exact wording of some of this.
The application data abstraction that QUIC offers right now is streams, which is what HTTP/3 uses; the text that NAME pointed to makes that clear. We could change how data is sent in QUIC from STREAM frames to something entirely different, and that should not matter to HTTP/3 as long as the abstraction is the same: reliable, in-order, byte-stream. I'm not worried about this mapping becoming an effective invariant for HTTP/3, since (i) changing this contract (say, for datagram webtransport) requires negotiating that change at both HTTP and QUIC levels; and (ii) if we don't deploy extensions that use other mappings between HTTP data and QUIC frames, I don't think saying that we allow other mappings in the future does much.
It's also worth noting that HTTP/3 as currently defined requires exactly QUIC version 1. Permitting additional QUIC versions will require an update or a follow-on spec which can adapt to any changed abstractions at the same time.

I guess my point is that the text describes what QUIC v1 without extensions provides, not what HTTP/3 on v1 requires. When there is only one option, there is only one natural solution. The reason I suggested to point this out is to allow future HTTP/3 an ability to iterate on this requirement, which could be done in a document that describes a change to the requirement of the frame(s) defined in this spec. That might help to make people aware of when they need to negotiate the extension. To put it another way. If QUIC v1 offered unreliable and reliable streams. We would likely say that all H3 frames must be delivered on the reliable stream and explain why.
Jana convinced me that the risk of ossification is low (thanks for talking through it!). Lucas may be on to something, though, in terms of how we describe what we use and what we need, but that could likely be done in the other issue that Mike noted might exist. I would be okay if we closed this one with no change, but it's not clear that we have fully resolved yet on the latter topic.
Could folks please come to a decision on whether this is "close with no action"?
I can live with no action.
reopening to run it through a call
Closing this now that the IESG have approved the document and it's with the RFC editor.
Yup, this is better.