Original text:
5.1.2. <del> Either client or server can cancel requests by aborting the stream (QUIC RESET_STREAM and/or STOP_SENDING frames, as appropriate) with an error code of HTTP_REQUEST_CANCELLED (http-error-codes).  When the client cancels a response, it indicates that this response is no longer of interest.  Implementations SHOULD cancel requests by aborting both directions of a stream. When the server aborts its response stream using HTTP_REQUEST_CANCELLED, it indicates that no application processing was performed.  In this context, "processed" means that some data from the stream was passed to some higher layer of software that </del>  might have taken some action as a result.  The client can treat <del> requests cancelled by the server as though they had never been sent at all, thereby allowing them to be retried later on a new connection.  Servers MUST NOT use the HTTP_REQUEST_CANCELLED status for requests which were partially or fully processed. </del>  If a stream is cancelled after receiving a complete response, the client MAY ignore the cancellation and use the response.  However, if 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>  Requests on Stream IDs less than the Stream ID in the GOAWAY frame might have been processed; their status cannot be known until they Servers SHOULD send a GOAWAY frame when the closing of a connection is known in advance, even if the advance notice is small, so that the <del> remote peer can know whether a stream has been partially processed or not.  For example, if an HTTP client sends a POST at the same time </del>  that a server closes a QUIC connection, the client cannot know if the server started to process that POST request if the server does not send a GOAWAY frame to indicate what streams it might have acted on. A frame was received which was not permitted in the current state.  Peer violated protocol requirements in a way which doesn't match a more specific error code, or endpoint declines to use the more specific error code.

Reviewer comments:
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....)

Revised text:
5.1.2.  <ins> Clients can cancel requests by aborting the stream (QUIC RESET_STREAM and/or STOP_SENDING frames, as appropriate) with an error code of HTTP_REQUEST_CANCELLED (http-error-codes).  When the client cancels a response, it indicates that this response is no longer of interest. Implementations SHOULD cancel requests by aborting both directions of a stream. When the server rejects a request without performing any application processing, it SHOULD abort its response stream with the error code HTTP_REQUEST_REJECTED.  In this context, "processed" means that some data from the stream was passed to some higher layer of software that </ins> might have taken some action as a result.  The client can treat  <ins> requests rejected by the server as though they had never been sent at all, thereby allowing them to be retried later on a new connection. Servers MUST NOT use the HTTP_REQUEST_REJECTED error code for requests which were partially or fully processed.  When a client sends a STOP_SENDING with HTTP_REQUEST_CANCELLED, a server MAY indicate the error code HTTP_REQUEST_REJECTED in the corresponding RESET_STREAM if no processing was performed.  Clients MUST NOT reset streams with the HTTP_REQUEST_REJECTED error code except in response to a QUIC STOP_SENDING frame. </ins> If a stream is cancelled after receiving a complete response, the client MAY ignore the cancellation and use the response.  However, if 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  <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 Servers SHOULD send a GOAWAY frame when the closing of a connection is known in advance, even if the advance notice is small, so that the  <ins> remote peer can know whether a request has been partially processed or not.  For example, if an HTTP client sends a POST at the same time </ins> that a server closes a QUIC connection, the client cannot know if the server started to process that POST request if the server does not send a GOAWAY frame to indicate what streams it might have acted on. A frame was received which was not permitted in the current state. <ins> A server rejected a request without performing any application processing. </ins> Peer violated protocol requirements in a way which doesn't match a more specific error code, or endpoint declines to use the more specific error code.