Change:
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> <ins> A variable-length integer containing the application-specified reason the sender is ignoring the stream (see app-error-codes). </ins> 19.6.

Discussion:
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