Code change:
3.3. <del> A QUIC stream MAY be canceled at any point with an error code.  The producer does this via a "RESET_STREAM" frame while the consumer requests cancellation with a "STOP_SENDING" frame. When using "order", lower priority streams will be starved during congestion, perhaps indefinitely.  These streams will consume resources and flow control until they are canceled.  When nearing resource limits, an endpoint SHOULD cancel the lowest priority stream with error code 0. The sender MAY cancel streams in response to congestion.  This can be useful when the sender does not support stream prioritization. TODO: this section actually describes stream cancellation, not session cancellation.  Is this section required, or can it be deleted, or added to a new "workflow" section. </del> <ins> QUIC streams aside from the control stream MAY be canceled due to congestion or other reasons by either the sender or receiver.  Early termination of a QUIC stream does not affect the MoQ application state, and therefore has no effect on outstanding subscriptions. </ins> 3.4.

Related discussion:
text: Section 3.3 currently says: "3.3. Cancellation A QUIC stream MAY be canceled at any point with an error code. The producer does this via a RESETSTREAM frame while the consumer requests cancellation with a STOPSENDING frame. When using order, lower priority streams will be starved during congestion, perhaps indefinitely. These streams will consume resources and flow control until they are canceled. When nearing resource limits, an endpoint SHOULD cancel the lowest priority stream with error code 0. The sender MAY cancel streams in response to congestion. This can be useful when the sender does not support stream prioritization. TODO: this section actually describes stream cancellation, not session cancellation. Is this section required, or can it be deleted, or added to a new "workflow" section." [BA] While the meaning of STOPSENDING is clear for frame/stream transport (e.g. stop sending the frame whose transmission is currently in progress), it is less clear when multiple frames are transported on the same QUIC stream. In the case where multiple frames are being transmitted on a stream, the problem is that STOPSENDING does not indicate which frame the receiver has given up on. So how is the sender to interpret it? For example, after resetting the stream, does the sender open a new stream? If so, what frame(s) are to be transmitted on that new stream? To address this ambiguity, an application-layer message(s) could be defined, indicating exactly what the receiver wants the sender to do: Stop (re-)transmission of a particular (named) frame. The existing stream is reset and a new stream is opened for transmission of subsequent frames. Stop transmission of layer(s). The receiver wishes to the sender to adjust the operating point, by stopping the transmission of one or more temporal or spatial layers. Only the layers that remain will be transmitted on new stream(s). Mailing list thread: URL
I think subscribe hints solves the problem of what to start on by saying which object to start the new subscription on. It seems like the solutions to layers would be to put different layers on differenent streams. I would expect different layers to have different priorities which will then mean different streams.
Attendees think there may be valid use cases of STOPSENDING and RESET and it should not be disallowed.