Re: [quicwg/base-drafts] Use the FRAME_ENCODING_ERROR for errors in frame encoding (#3042)

Kazuho Oku <> Mon, 04 November 2019 05:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 182CA120125 for <>; Sun, 3 Nov 2019 21:02:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gF7yzNOOgvFZ for <>; Sun, 3 Nov 2019 21:02:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D84A312011A for <>; Sun, 3 Nov 2019 21:02:36 -0800 (PST)
Date: Sun, 03 Nov 2019 21:02:35 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572843755; bh=XQBom1N0BAs454hSr0agsBFxLwNgjK+ZcdfqMjftMZs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=dFKLXVQ/D6KovpuSPijKWkkKE5NzBqX//RaP2F4HPaLK7aaqScM409KtstNDUnzXq Wvcshfk1BHARzWBMrz691n6zWo2QW6uzDxpAWZh0qRkqf74dk6zhKbqvj2iJfv1V13 GCZLUSt7bWPZ4qrN6r5WBISnqVaZdQVEdmWBnl98=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3042/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Use the FRAME_ENCODING_ERROR for errors in frame encoding (#3042)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dbfb0eb7959b_2b023f92dcecd96c2317633"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Nov 2019 05:02:39 -0000

@marten-seemann I think you are conflating two different issues. #2524 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 explain why "MUST respond with a FRAME_ENCODING_ERROR" for a CRYPTO stream is a problem.

The reason we have allowed the use of FLOW_CONTROL_ERROR 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 FRAME_ENCODING_ERROR 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 CRYPTO_BUFFER_EXCEEDED or FLOW_CONTROL_ERROR. I don't mind either. But requiring FRAME_ENCODING_ERROR is different, because it could require the stream-level logic to respond either with a stream-level error code (CRYPTO_BUFFER_EXCEEDED or FLOW_CONTROL_ERROR) and frame-level error code (FRAME_DECODING_ERROR) 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.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: