Change:
frame (frame-goaway).  The GOAWAY frame indicates that client- initiated requests on lower stream IDs were or might be processed in this connection, while requests on the indicated stream ID and <del> greater were not accepted.  This enables client and server to agree on which requests were accepted prior to the connection shutdown. This identifier MAY be lower than the stream limit identified by a QUIC MAX_STREAM_ID frame, and MAY be zero if no requests were processed.  Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit after sending a GOAWAY frame. Once GOAWAY is sent, the server MUST cancel requests sent on streams with an identifier higher than the indicated last Stream ID.  Clients MUST NOT send new requests on the connection after receiving GOAWAY, although requests might already be in transit.  A new connection can be established for new requests. If the client has sent requests on streams with a higher Stream ID than indicated in the GOAWAY frame, those requests are considered cancelled (request-cancellation).  Clients SHOULD reset any streams above this ID with the error code HTTP_REQUEST_CANCELLED.  Servers MAY also cancel requests on streams below the indicated ID if these requests were not processed. </del> <ins> greater were rejected.  This enables client and server to agree on which requests were accepted prior to the connection shutdown.  This identifier MAY be lower than the stream limit identified by a QUIC MAX_STREAM_ID frame, and MAY be zero if no requests were processed. Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit after sending a GOAWAY frame. Once GOAWAY is sent, the server MUST reject requests sent on streams with an identifier greater than or equal to the indicated last Stream ID.  Clients MUST NOT send new requests on the connection after receiving GOAWAY, although requests might already be in transit.  A new connection can be established for new requests. If the client has sent requests on streams with a Stream ID greater than or equal to that indicated in the GOAWAY frame, those requests are considered rejected (request-cancellation).  Clients SHOULD cancel any requests on streams above this ID.  Servers MAY also reject requests on streams below the indicated ID if these requests were not processed. </ins> Requests on Stream IDs less than the Stream ID in the GOAWAY frame might have been processed; their status cannot be known until they

Discussion:
This change sounds good to me, but to make sure I understand: is the only purpose of this change to split HTTPREQUESTCANCELLED in two; client to server stays HTTPREQUESTCANCELLED and server to client now becomes HTTPREQUESTREJECTED? And is the goal to add clarity when parsing connection logs later?
NAME basically. In the previous text, CANCELLED had specific semantics when sent server->client. However, with the change to make RESETSTREAM reflect back the error code in STOPSENDING, the client->server STOPSENDING(CANCELLED) would provoke a RESETSTREAM(CANCELLED) in the server->client direction with that error code that didn't necessarily match those semantics. Hence the split -- one code has specific semantics when sent by a server, and clients are instructed to use the other code. (I would prohibit clients from sending it, but if the server sends a STOP_SENDING, the client would reflect it back and violate the prohibition, so....)