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

Kazuho Oku <> Wed, 18 September 2019 07:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41D281208F9 for <>; Wed, 18 Sep 2019 00:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.739
X-Spam-Status: No, score=-2.739 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, GB_SUMOF=5, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, 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 IArXJy6t955F for <>; Wed, 18 Sep 2019 00:25:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C562120125 for <>; Wed, 18 Sep 2019 00:25:57 -0700 (PDT)
Date: Wed, 18 Sep 2019 00:25:56 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1568791556; bh=u2QQCUxfObp2ICb36Ktz3cJImUAIc8/Lp/0rk08zlDY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=h7q3t0K58xxDy1yfgm6gPZydWxIZBSaVbbWeR3luImbpbYMH0mkxnhuugE4OQaZ2Q rSB04JPMpJtUB7jV9uvrVaGqD2EmK/rzeJc3Sp/lLPqgkEMZBPIpFbtpFEB4XcdxDR Z7wjN/FalflchLXMs1WCtJoqDAopbhA3pcJrqYkw=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3042/review/>
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_5d81dc0456ea8_38c03fbdef2cd96c987f9"; 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: Wed, 18 Sep 2019 07:25:59 -0000

kazuho commented on this pull request.

> @@ -5060,8 +5059,8 @@ the offset of the next byte that would be sent.
 The first byte in the stream has an offset of 0.  The largest offset 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 will be treated as a connection error of type
+frame that exceeds this limit MUST be treated as a connection error of type

My point is that if we are going to permit the use of FRAME_ENCODING_ERROR when the STREAM frame exceeds the 2<sup>62</sup> boundary, then we should also permit the use of FRAME_ENCODING_ERROR for MAX_STREAMS frame carrying a count exceeding 2<sup>60</sup>.

My weak preference is to not do either of the two, as we'd be losing a clear signal. IMO, this discussion is about the error code to be used when integrity check for certain frames fail. We can argue that integrity check is not part of frame decoding. Then, it would be natural to use the more specific error codes.

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