diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md
index ae3e9074ca..40755ba33b 100644
--- a/draft-ietf-quic-http.md
+++ b/draft-ietf-quic-http.md
@@ -2355,9 +2355,8 @@ the peers' settings to arrive before responding to other streams.  See
 ## HTTP/2 Error Codes
 
 QUIC has the same concepts of "stream" and "connection" errors that HTTP/2
-provides. However, there is no direct portability of HTTP/2 error codes to
-HTTP/3 error codes; the values are shifted in order to prevent accidental
-or implicit conversion.
+provides. However, the differences between HTTP/2 and HTTP/3 mean that error
+codes are not directly portable between versions.
 
 The HTTP/2 error codes defined in Section 7 of {{?HTTP2}} logically map to
 the HTTP/3 error codes as follows:
@@ -2412,6 +2411,34 @@ H3_1_1_REQUIRED (0xd):
 Error codes need to be defined for HTTP/2 and HTTP/3 separately.  See
 {{iana-error-codes}}.
 
+### Mapping Between HTTP/2 and HTTP/3 Errors
+
+An intermediary that converts between HTTP/2 and HTTP/3 may encounter error
+conditions from either upstream. It is useful to communicate the occurrence of
+error to the downstream but error codes largely reflect connection-local
+problems that generally do not make sense to propagate.
+
+An intermediary that encounters an error from an upstream origin can indicate
+this by sending an HTTP status code such as 502, which is suitable for a broad
+class of errors.
+
+There are some rare cases where it is beneficial to propagate the error by
+mapping it to the closest matching error type to the receiver. For example, an
+intermediary that receives an HTTP/2 stream error of type REFUSED_STREAM from
+the origin has a clear signal that the request was not processed and that the
+request is safe to retry. Propagating this error condition to the client as an
+HTTP/3 stream error of type H3_REQUEST_REJECTED allows the client to take the
+action it deems most appropriate. In the reverse direction the intermediary
+might deem it beneficial to pass on client request cancellations that are
+indicated by terminating a stream with H3_REQUEST_CANCELLED.
+
+Conversion between errors is described in the logical mapping. The error codes
+are defined in non-overlapping spaces in order to protect against accidental
+conversion that could result in the use of inappropriate or unknown error codes
+for the target version. An intermediary is permitted to promote stream errors to
+connection errors but they should be aware of the cost to the connection for
+what might be a temporary or intermittent error.
+
 # Change Log
 
 > **RFC Editor's Note:**  Please remove this section prior to publication of a