Change:
As NAME pointed out in URL, I missed that there's a CRYPTOBUFFEREXCEEDED that would equally valid to send when a CRYPTO frame exceeds the 2^62-1 limit.
I can see how this can simplify some decoding logic, but I am not sure we should consider such a value valid in the first place. If the value is invalid it is meaningless to discuss length and then there is only a frame error left. Otherwise we could probably revisit a gazillion other places where this principle could also apply.
NAME yes this is largely what I meant. The PR introduces a new principle.
NAME : I'm confused too. For consistency, I would keep it at FRAMEENCODINGERROR, since that's what we do for the flow control error too.
NAME NAME I am with NAME Let me explain why. There are two reasons we decided to allow use of FLOWCONTROLERROR for STREAM frames: The overflow can be detected by the flow control logic. Then, there is not need to have a logic to detect the error in the frame decoder. The flow control logic might be capable of returning only one error. FLOWCONTROLERROR is more specific than FRAMEENCODINGERROR. These reasons equally hold for CRYPTO streams sending CRYPTOBUFFEREXCEEDED, as CRYPTOBUFFEREXCEEDED is the error code used to indicate flow control error with CRYPTO streams. To paraphrase this PR applies the principles that we agreed for STREAM frame to CRYPTO frames.
Thanks for clarifying, NAME This LGTM.
From the original issue, the proposed principle was: "If you can detect an error while parsing the frame, and without consulting any connection state, it should be a FRAMEENCODINGERROR." It seems clear you can do that in this case, but maybe we changed the principle?
NAME That would also apply to the STREAM frame then. I'd be fine just using the FRAMEENCODINGERROR in all these cases, but people pushed back against that.
NAME Yeah I think I should have said that the exceptional rule within the principles. Specifically, I mean the discussion starting from URL, that talks if we should allow FLOWCONTROLERROR and why.
NAME I thought that might have been the relevant discussion. In general, I'd prefer to have principles decided on issues, but I understand these things happen. I don't think this is the end of the world, but I prefer the original principle because I think it's easy to reason about. If we've decided against that principle, I'd suggest we state a new principle.
NAME I don't think we ever actually discussed this in the working group. If I remember correctly, using two error codes was a suggestion that came up on my original PR, and then the editors decided in Cupertino that I should update the PR accordingly. Actually, I'd prefer to take the principled approach, and just use FRAMEENCODINGERROR wherever possible.
NAME I think we did discuss at the interim. URL
To be precise, we discussed that two error codes were OK at the interim, then declared that as a consensus in the call started on Oct 22 URL I do not think we should be revisiting the discussion.
I think we should either: 1) Espouse a new principle that fits the existing text and this PR and use that going forward 2) Stick with the original principle and remove the OR FLOWCONTROLERROR from the text. If we don't have a principle that matches the text, we're prone to having this discussion a few more times.
NAME kindly shared our principles, and this PR aligns with that. URL
Chairs and editors, I think we agree that this is an amendment to that has been shipped as part of -24. Does that mean that this would be merged as an editorial correction? Or if not, do we need an issue?
I think we can merge it because it agrees with the stated principles. But its NAME call
Let's open an issue. At this stage, I want to be very particular about this sort of change, even if it is quite clearly within the bounds of established principles.
NAME did as .
When discussing at Cupertino, we agreed that either of the following two errors can be sent when the payload of the STREAM frame exceeds 2^62 bytes: FRAMEENCODINGERROR FLOWCONTROLERROR And we've merged PR that made that change, along with other changes. However, in that PR, we failed to apply the rule that we agreed for SRTEAM frame to CRYPTO frame. Editors' draft now allows use of FRAMEENCODINGERROR for CRYPTO frames, but not CRYPTOBUFFEREXCEEDED. As CRYPTOBUFFEREXCEEDED is the flow control error for CRYPTO streams, that should be permitted too. To be fixed by PR .
Thanks for doing all of this Kazuho.
fixed this one.
Thank you! LGTM. The following issues have proposals for resolution, and discussion so far seems to support consensus to accept them. If you object, please do so on the issue or in response to this message (changing the Subject appropriately!). Absent any pushback, we'll direct the editors to incorporate them next week. See for the current state of issues in the Late Stage process, itself defined at . : Is CONNECTIONCLOSE ACK-eliciting? The proposal is : Stateless reset detection should be datagram-based The proposal is : Label for key updates The proposal is : Handling of Retire Prior To field The proposal is : Require peers to check if RETIRECONNECTION_ID sequence number is valid The proposal is : Codes for frame encoding errors The proposal is : Layout of PreferredAddress The proposal is to close with no action. : Lift single-packet ClientHello requirement? The proposal is : unrecoverable loss pattern leads to deadlock The proposal is : Do Initial secrets change after Retry packet? The proposal is : Re-visit initial keys discard The proposal is to close with no action. : Why does stateless reset have to be checked after MAC failure The proposal is Mark Nottingham URL

Discussion:
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 <del> FRAME_ENCODING_ERROR. </del> <ins> FRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED. </ins> Unlike STREAM frames, which include a Stream ID indicating to which stream the data belongs, the CRYPTO frame carries data for a single