Change:
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.

Discussion:
value for the subsequent ACK Range using the following formula: If any computed packet number is negative, an endpoint MUST generate <del> a connection error of type FRAME_ENCODING_ERROR indicating an error in an ACK frame. </del> <ins> a connection error of type FRAME_ENCODING_ERROR. </ins> 19.3.2.

implies that each encryption level is treated as a separate CRYPTO stream of data. <ins> The largest offset delivered on a stream - the sum of the offset and data length - cannot exceed 2^62-1.  Receipt of a frame that exceeds this limit MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </ins> Unlike STREAM frames, which include a Stream ID indicating to which stream the data belongs, the CRYPTO frame carries data for a single stream per encryption level.  The stream does not have an explicit

delivered on a stream - the sum of the offset and data length - cannot exceed 2^62-1, as it is not possible to provide flow control credit for that data.  Receipt of a frame that exceeds this limit <del> will be treated as a connection error of type FLOW_CONTROL_ERROR. </del> <ins> MUST be treated as a connection error of type FRAME_ENCODING_ERROR or FLOW_CONTROL_ERROR. </ins> 19.9.

A count of the cumulative number of streams of the corresponding type that can be opened over the lifetime of the connection. <ins> Stream IDs cannot exceed 2^62-1, as it is not possible to encode stream IDs larger than this value.  Receipt of a frame that permits opening of a stream larger than this limit MUST be treated as a FRAME_ENCODING_ERROR. </ins> Loss or reordering can cause a MAX_STREAMS frame to be received which states a lower stream limit than an endpoint has previously received.

STREAMS_BLOCKED frames contain the following fields: A variable-length integer indicating the stream limit at the time <del> the frame was sent. </del> <ins> the frame was sent.  Stream IDs cannot exceed 2^62-1, as it is not possible to encode stream IDs larger than this value.  Receipt of a frame that encodes a larger stream ID MUST be treated as a STREAM_LIMIT_ERROR or a FRAME_ENCODING_ERROR. </ins> 19.15.

An 8-bit unsigned integer containing the length of the connection ID.  Values less than 1 and greater than 20 are invalid and MUST <del> be treated as a connection error of type PROTOCOL_VIOLATION. </del> <ins> be treated as a connection error of type FRAME_ENCODING_ERROR. </ins> A connection ID of the specified length.

The Retire Prior To field MUST be less than or equal to the Sequence Number field.  Receiving a value greater than the Sequence Number <del> MUST be treated as a connection error of type PROTOCOL_VIOLATION. </del> <ins> MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </ins> Once a sender indicates a Retire Prior To value, smaller values sent in subsequent NEW_CONNECTION_ID frames have no effect.  A receiver

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-