Draft: draft-ietf-webtrans-http2

Commentary: Thanks for the review  . I suppose the higher fidelity version of STOPSENDING would not change the state of the stream at all , but induce the peer to send a RSTSTREAM as QUIC does . Maybe that is better . 
 Actually , there is worse : when I send STOP_SENDING , I no longer know when the peer has received and acted on that without an explicit stream termination signal , so I ca n't transition the stream to a closed state . 
 Wait , how is this different than QUIC ? You ca n't close a bidirectional stream until the peer sends you a  or RST . 
 Right ; I was reading your description of STOPSENDING as changing stream state , either at the point that it was sent or received . In that case , if a stream is " open " , the sender of STOPSENDING might believe that all it needs to do is send RESETSTREAM to close the stream completely . If it does so , the peer will receive those frames and then both peers will believe the stream to be closed . But the sender of STOPSENDING has no way to distinguish between that set of circumstances and one where the peer takes an arbitrary amount of time to process the frames . The receiver of STOP_SENDING might just keep sending data indefinitely . How does the receiver of those frames know when the other side has truly stopped ? You might say " too bad " . After all , the only thing you need to do is keep counting against connection - level flow control , but it makes the " closed " state that much harder to manage . 
 As written , STOPSENDING does change stream state , which would allow the sender to move to closed unilaterally ( for example , send  and WTSTOPSENDING together ) . DATA frames may trickle in after that for the closed stream , you just keep handling them for connection flow control -- this is the same as RSTSTREAM in vanilla H2 . If we make it like QUIC instead , where STOPSENDING does not affect state , the sender of the STOPSENDING has to wait for  or a FIN to move to closed . So I think either model is fine and I do n't have a stylistic preference . I 'm wondering if it has an effect on the stream limit accounting , but I do n't think it does ? The H2 model frees the streams 1/2 RTT faster . 
 Ugh , I should know this stuff better , I only recently rewrote the closing bit in h2 to deal with this problem . Of course . It 's bad , but no worse than status quo . Thanks for correcting me . ( Full transparency : I think that the QUIC stream model is so much better than h2 that I can no longer stomach these minor infidelities in h2 . This PR does manage to balance the need to provide API consistency across versions without fixing / changing h2 's problems . I 'm sure I 'll manage to swallow my distaste eventually if we go this way . ) 
 Heh . Since this is merging an H3 feature into H2 I feel like we could pick either model and still claim to be consistent . For now , I 'll leave this H2 style . 
 QUIC and HTTP/3 support resetting only half of a bidirectional stream . If WebTransport requires this functionality , then this draft would need additional frames to convey those signals ( WTRESETSTREAM and WTSTOPSENDING ) . 
 Fixed by 
 Thanks for writing this up  . This works . Though I 'm not sure about the STOPSENDING analogue ; QUIC permits the sender to choose the ultimate code for RESETSTREAM , even if it is generally copied from STOPSENDING . I know that we mostly do n't need to include RESETSTREAM here as the stream size accounting is n't as critical , so maybe perfect fidelity is n't needed . Thanks
The RST_STREAM frame defined in HTTP/2 moves a stream to the "closed"
state, but WebTransport streams can be reset unidirectionally, as in
QUIC and HTTP/3.  A new HTTP/2 frame called WT_RST_STREAM is
introduced for an endpoint to unidirectionally reset a stream for
writing.  WT_RST_STREAM frames can be sent on a stream in the "open",
or "half-closed (remote)" state.
The WT_RST_STREAM frame contains a single unsigned, 32-bit integer
identifying the error code.  The error code indicates why the stream
is being abruptly terminated for writing.
The WT_RST_STREAM frame does not define any flags.
The WT_RST_STREAM frame half-closes the referenced stream and effects
the same state machine transitions as sending or receiving the
END_STREAM flag.  If the sender is in the "open" state, it
transitions to "half-closed (local)".  If the sender is in the "half-
closed (remote)" state, it transitions to "closed".  If the receiver
is in the "open" state, it transitions to "half-closed (remote)".  If
the receiver is in the "half-closed (local)" state, it transitions to
"closed".
After sending a WT_RST_STREAM on a stream, the sender MUST NOT send
additional DATA frames for that stream.  If another frame is received
on a stream after receiving a WT_RST_STREAM, the recipient MUST treat
this as a connection error of type PROTOCOL_ERROR.
WT_RST_STREAM frames MUST be associated with a WebTransport stream.
If a WT_RST_STREAM frame is received with a stream identifier of 0x0,
or a request or push stream, the recipient MUST treat this as a
connection error of type PROTOCOL_ERROR.
WT_RST_STREAM frames MUST NOT be sent for a stream in any state other
than "open" or "half-closed (remote)".  If a WT_RST_STREAM frame
identifying a stream in the "idle", "reserved (local)", "reserved
(remote)" state is received, the recipient MUST treat this as a
connection error (Section 5.4.1) of type PROTOCOL_ERROR.  Because of
race conditions with WT_STOP_SENDING, it is possible to receive a
WT_RST_STREAM in the "half-closed (remote)" or "closed" state.  The
recipient should ignore the frame in this case.
A WT_RST_STREAM frame with a length other than 4 octets MUST be
treated as a connection error (Section 5.4.1) of type
FRAME_SIZE_ERROR.
The RST_STREAM frame defined in HTTP/2 moves a stream to the "closed"
state, but WebTransport streams can be reset unidirectionally, as in
QUIC and HTTP/3.  A new HTTP/2 frame called WT_STOP_SENDING is
introduced for an endpoint to unidirectionally reset a stream for
reading.  WT_STOP_SENDING frames can be sent on a stream in the
"open", or "half-closed (local)" state.
The WT_STOP_SENDING frame contains a single unsigned, 32-bit integer
identifying the error code.  The error code indicates why the reading
the stream is being abandoned.
The WT_STOP_SENDING frame does not define any flags.
The WT_STOP_SENDING frame half-closes the referenced stream and
effects the same state machine transitions as sending or receiving
the END_STREAM flag.  If the sender is in the open state, it
transitions to "half-closed (remote)".  If the sender is in the
"half-closed (local)" state, it transitions to "closed".  If the
receiver is in the "open" state, it transitions to "half-closed
(local)".  If the receiver is in the "half-closed (remote)" state, it
transitions to "closed".
After receiving a WT_STOP_SENDING on a stream, the sender MUST NOT
send additional frames for that stream.  After sending the
WT_STOP_SENDING, the sending endpoint MUST be prepared to receive and
handle additional frames sent on the stream that might have been sent
by the peer prior to the arrival of the WT_STOP_SENDING.
WT_STOP_SENDING frames MUST be associated with a WebTransport stream.
If a WT_STOP_SENDING frame is received with a stream identifier of
0x0, or a request or push stream, the recipient MUST treat this as a
connection error of type PROTOCOL_ERROR.
WT_STOP_SENDING frames MUST NOT be sent for a stream in any state
other than "open" or "half-closed (local)".  It is possible to
receive a WT_STOP_SENDING in another state however, because the
sender might have closed or reset the stream while the
WT_STOP_SENDING was in flight.  If a WT_STOP_SENDING frame
identifying a stream that is already "closed" or "half-closed
(local)", the recipient SHOULD ignore the frame.
It is also possible to receive DATA frames on a WebTransport stream
in the "half-closed (remote)" or "closed" states if the stream
transitioned there via WT_STOP_SENDING.  If a DATA frame is received
on a WebTransport stream in one of these states, the recipient MUST
account for its contribution against the connection flow-control
window and MUST NOT treat it as an error.
A WT_STOP_SENDING frame with a length other than 4 octets MUST be
treated as a connection error (Section 5.4.1) of type
FRAME_SIZE_ERROR.