Original text:
A variable-length integer encoding of the Stream ID of the stream being terminated. <del> A 16-bit application protocol error code (see app-error-codes) which indicates why the stream is being closed. </del>  A variable-length integer indicating the final size of the stream by the RESET_STREAM sender, in unit of bytes. A variable-length integer carrying the Stream ID of the stream being ignored. <del> A 16-bit, application-specified reason the sender is ignoring the stream (see app-error-codes). </del>  19.6. CONNECTION_CLOSE frames contain the following fields: <del> A 16-bit error code which indicates the reason for closing this connection.  A CONNECTION_CLOSE frame of type 0x1c uses codes from the space defined in error-codes.  A CONNECTION_CLOSE frame of type 0x1d uses codes from the application protocol error code space; see </del>  A variable-length integer encoding the type of frame that triggered the error.  A value of 0 (equivalent to the mention of 20. <del> QUIC error codes are 16-bit unsigned integers. </del>  This section lists the defined QUIC transport error codes that may be used in a CONNECTION_CLOSE frame.  These errors apply to the entire 20.1. <del> Application protocol error codes are 16-bit unsigned integers, but </del>  the management of application error codes are left to application protocols.  Application protocol error codes are used for the RESET_STREAM frame (frame-reset-stream), the STOP_SENDING frame IANA [SHALL add/has added] a registry for "QUIC Transport Error Codes" under a "QUIC Protocol" heading. <del> The "QUIC Transport Error Codes" registry governs a 16-bit space. This space is split into two spaces that are governed by different policies.  Values with the first byte in the range 0x00 to 0xfe (in hexadecimal) are assigned via the Specification Required policy RFC8126.  Values with the first byte 0xff are reserved for Private Use RFC8126. </del>  Registrations MUST include the following fields: The numeric value of the assignment (registrations will be between <del> 0x0000 and 0xfeff). </del>  A short mnemonic for the parameter. A reference to a publicly available specification for the value.  The initial contents of this registry are shown in iana-error-table. <del> Values from 0xFF00 to 0xFFFF are reserved for Private Use RFC8126. </del>

Reviewer comments:
Changes CONNECTIONCLOSE, STOPSENDING, and RESET_STREAM to varint error codes. Also fixes an error where the spec said the transport parameter registry is 16 bits, but transport parameters are now varints as well.
For consistency you probably want to update HTTP too, e.g. there are some references to 16-bit error code there too URL
Thanks for pointing that out NAME http updated.
Thanks Mike, I think I fixed all your suggestions.
Currently there are three spots in the QUIC transport spec which used fixed length(16-bit) integers: Connection Close error code Application Protocol Error Code in Reset Stream Application Error Code in Stop Sending This typically makes reset stream and stop sending frames 1 byte larger than they need to be, which could be slightly annoying if one is churning through a huge number of streams. It creates some unnecessary oddness in the HTTP/3 spec, where the HTTPMALFORMEDFRAME(0x01XX) is describing a frame type that's a varint. Admittedly, there would still be a limit of 2^60 being expressible, but it's easy to avoid that. I think all 3 fields would be better as a varint, given our recent decisions to make HTTP/3 all varints.
I would support a move to varints. I've been wanting to support more than 16-bit application error codes, for non-http protocols.
We discussed this in , and closed it because nobody felt strongly either way, if I remember correctly.
I think preferences may have changed, and NAME did have a preference for varints here anyways. Since nobody had a strong preference either way in , it's probably worth having people voice their opinions if they now believe more strongly than they did before.
I'm of the opinion that varint is OK. We can crib text from other varint usages about IANA registries and such, so the change is cheap for the spec perspective. The HTTPMALFORMEDFRAME thing would need a solution. I've never been a big fan of the concept, but anything would do (apart from the 2^60 thing, which would take 1/4 of the entire space for bad frames, which is excessive; I hope that's just an error).
I also think that varint is OK. It gives application protocols to use up to 62-bit space for error codes rather than enforcing them to use 16-bit space. The downside is that the CONNECTIONCLOSE frame could become one byte bigger, but I do not think that is a real cost. Re HTTPMALFORMEDFRAME, my preference goes to either a) recommend endpoints expressing the offending frame type in the reason phrase, or b) change the definition of application-close frame (i.e. CONNECTIONCLOSE with type=0x1d) to carry a blob, and define in the HTTP/3 spec. that the blob would be a tuple of error-code (varint), offending-frame-type (varint), and a reason phrase1. My view is that 2^60 is a dirty hack. It works, but I'd argue that it is a sign that the HTTP draft doing something unexpected by the transport design. Therefore, I'm arguing to do what is expected by the transport, or change the design of the transport to meet the requirement of HTTP. 1: If we are to allow the application-close frame to carry a blob, the HTTP draft can also consider adding max-processed-stream-id to the blob, so that the client can replay the requests that have not yet been processed even in case of a protocol violation - a feature we have had in HTTP/2.
For HTTPMALFORMEDFRAME, I think NAME PR that removes it and replaces it with a small number of specific error codes is like a good way to go instead of the 2^60 hack. NAME Are you happy with that PR? I'm going to write a varint PR with the assumption or something like it is likely to land, so it will be transport-only.
FWIW I just fixed the merge conflict on
NAME works for me. My complaint is that HTTP/3 should not "hack" QUIC. Eliminating HTTPMALFORMEDFRAME is a way of achieving that, and I do not have a strong preference on communicating the malformed frame ID.
Thank you for the work!Thanks for adding the registry text. LGTM.LGTM

Revised text:
A variable-length integer encoding of the Stream ID of the stream being terminated.  <ins> A variable-length integer containing the application protocol error code (see app-error-codes) which indicates why the stream is being closed. </ins> A variable-length integer indicating the final size of the stream by the RESET_STREAM sender, in unit of bytes. A variable-length integer carrying the Stream ID of the stream being ignored.  <ins> A variable-length integer containing the application-specified reason the sender is ignoring the stream (see app-error-codes). </ins> 19.6. CONNECTION_CLOSE frames contain the following fields:  <ins> A variable length integer error code which indicates the reason for closing this connection.  A CONNECTION_CLOSE frame of type 0x1c uses codes from the space defined in error-codes.  A CONNECTION_CLOSE frame of type 0x1d uses codes from the application protocol error code space; see </ins> A variable-length integer encoding the type of frame that triggered the error.  A value of 0 (equivalent to the mention of 20.  <ins> QUIC error codes are 62-bit unsigned integers. </ins> This section lists the defined QUIC transport error codes that may be used in a CONNECTION_CLOSE frame.  These errors apply to the entire 20.1.  <ins> Application protocol error codes are 62-bit unsigned integers, but </ins> the management of application error codes are left to application protocols.  Application protocol error codes are used for the RESET_STREAM frame (frame-reset-stream), the STOP_SENDING frame IANA [SHALL add/has added] a registry for "QUIC Transport Error Codes" under a "QUIC Protocol" heading.  <ins> The "QUIC Transport Error Codes" registry governs a 62-bit space. This space is split into three spaces that are governed by different policies.  Values between 0x00 and 0x3f (in hexadecimal) are assigned via the Standards Action or IESG Review policies RFC8126.  Values from 0x40 to 0x3fff operate on the Specification Required policy RFC8126.  All other values are assigned to Private Use RFC8126. </ins> Registrations MUST include the following fields: The numeric value of the assignment (registrations will be between  <ins> 0x0000 and 0x3fff). </ins> A short mnemonic for the parameter. A reference to a publicly available specification for the value. <ins> The nominated expert(s) verify that a specification exists and is readily accessible.  Expert(s) are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing, or architecturally dubious). </ins> The initial contents of this registry are shown in iana-error-table.