Change:
The sequence number specified in a RETIRE_CONNECTION_ID frame MUST NOT refer to the Destination Connection ID field of the packet in which the frame is contained.  The peer MAY treat this as a <del> connection error of type PROTOCOL_VIOLATION. </del> <ins> connection error of type FRAME_ENCODING_ERROR. </ins> An endpoint cannot send this frame if it was provided with a zero- length connection ID by its peer.  An endpoint that provides a zero-

Discussion:
Editors discussed this and could do either. This is likely a nuisance topic for a meeting. Editors' preference is for NAME to decide this. NAME can you either back out the "or" on the flow control thing, or add an "or" to the stream limit frame descriptions?
FWIW, I think that the "or" needs to cover the following four frames: CRYPTO, STREAMS, MAXSTREAMS, STREAMSBLOCKED.
NAME did you want to fix the examples listed in URL or shall I?
NAME NAME I added text for CRYPTO, MAXSTREAMS and STREAMSBLOCKED frames, however: for CRYPTO frames, there's no flow control. It would be awkward to use a FLOWCONTROLERROR here, so I opted for just using a FRAMEENCODINGERROR, for MAXSTREAMS frames FRAMEENCODINGERROR is the only applicable error. We do have a STREAMLIMITERROR, but this error is described as "Too many streams opened", and MAXSTREAMS doesn't open any streams by itself.
Those seem like reasonable conclusions to me. I'm happy taking this. Now I just need to ensure that the changelog is updated.
NAME I'm not sure if I follow the logic here. If there is no flow control, then I'd presume that exceeding 262 bytes is totally fine, and therefore that that the receiver should not be required (i.e. MUST) to send an error.
NAME There's no flow control in the sense that you don't advertise a window and you don't update any window.
NAME Are you suggesting that the CRYPTO stream has implicit limit of 262 bytes that can be transferred? I think my question is how you would justify it. My claim is that it's an unnecessary complexity.
NAME That's what's written in the spec. I was not happy with our decision from Tokio to not communicate a limit for the data that can be sent on a CRYPTO stream, and have peers just drop any frames sent on that stream in the future instead. But that's what the working group decided to do.
NAME I think you are conflating two different issues. is an issue about the amount of data buffered, while this issue is about the maximum offset of data an endpoint can ultimately represent.

Let me more practically explain why "MUST respond with a FRAMEENCODINGERROR" for a CRYPTO stream is a problem. The reason we have allowed the use of FLOWCONTROLERROR for STREAM frames is because that is an error that can be caught by the stream-level receive buffer (and it's logic), rather than the frame decoder. Stating that the error code MUST be FRAMEENCODINGERROR for CRYPTO streams in this particular case goes against that agreement. That logic that we used for STREAM frames can be equally applied to CRYPTO streams. The error code can either be CRYPTOBUFFEREXCEEDED or FLOWCONTROLERROR. I don't mind either. But requiring FRAMEENCODINGERROR is different, because it could require the stream-level logic to respond either with a stream-level error code (CRYPTOBUFFEREXCEEDED or FLOWCONTROLERROR) and frame-level error code (FRAMEDECODINGERROR) based on the input. As can be seen, this requirement to distinguish between the two cases is the same as the one we argue for the STREAM frame case.
NAME You're right. I missed that we have a CRYPTOBUFFEREXCEEDED error. I'll prepare a follow-up PR later today. Unfortunately, it looks like it won't make it into -24 any more though.
In the context of deciding what code to use for badly formatted frames: Originally posted by NAME in URL I tend to agree with this. Let's go through and try to apply some sort of consistency. Maybe even try to be principled about it.
How does this principle sound: If you can detect an error while parsing the frame, and without consulting any connection state, it should be a FRAMEENCODINGERROR. For everything that happens after frame parsing, we use the more concrete error types (or PROTOCOL_VIOLATION).
+1. To rephrase, as the name suggests, FRAMEENCODINGERROR indicates a syntactic (i.e., encoding) error. But nothing else.
I'd like to see a PR, but that seems like a good principle.
NAME I prepared a PR, just waiting for to get merged to apply the principle there.
Can we call this editorial?
It changes functional requirements about what error codes to send, so not really.
Discussed in Cupertino. Will be consensus-called.

I agree with NAME that I would prefer FLOWCONTROLERROR since it is a bit more specific. Otherwise looks fine to me.