Mapping lifetime and stream states

[LPardue]

The spec says:

A client that no longer wants a given Connection ID to be forwarded by the proxy, for either direction, MUST reset the stream.

While https://tools.ietf.org/html/draft-ietf-quic-transport-31#section-2.4 says:

On the sending part of a stream, an application protocol can:

   *  write data, understanding when stream flow control credit
      (Section 4.1) has successfully been reserved to send the written
      data;

   *  end the stream (clean termination), resulting in a STREAM frame
      (Section 19.8) with the FIN bit set; and

   *  reset the stream (abrupt termination), resulting in a RESET_STREAM
      frame (Section 19.4) if the stream was not already in a terminal
      state.

   On the receiving part of a stream, an application protocol can:

   *  read data; and

   *  abort reading of the stream and request closure, possibly
      resulting in a STOP_SENDING frame (Section 19.5).

HTTP/3 approaches this by saying

   Implementations SHOULD cancel requests by abruptly terminating any
   directions of a stream that are still open.  This means resetting the
   sending parts of streams and aborting reading on receiving parts of
   streams; see Section 2.4 of [QUIC-TRANSPORT].

Would it be clearer to lean on HTTP/3 for the CONNECT-UDP client behavior, or is something specific intended with the current text?

[tfpauly]

Yeah, let's just say it cancels the HTTP/3 request.