Re: [quicwg/base-drafts] Why do we have final size? (#3739)

Mike Bishop <> Mon, 08 June 2020 18:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3C1F3A0EB9 for <>; Mon, 8 Jun 2020 11:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.518
X-Spam-Level: ***
X-Spam-Status: No, score=3.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_SUMOF=5, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P-K_FxZQLbjC for <>; Mon, 8 Jun 2020 11:41:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DEE2E3A106C for <>; Mon, 8 Jun 2020 11:40:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0B97B6E1306 for <>; Mon, 8 Jun 2020 11:40:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1591641643; bh=xrVGRjEMijT722lR1ojGv3RcmEU9xmqltArCG3hE96k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=f8vkhDr+cvSa/fe6aXvWuSKM3Y/kNizJ/XTFb42qApHi+T9m6aX0gN0IKz6YGbT2X F+al04uzD0sfQ36TzsNdeTLlC0QYlQ+M0u5aiRB0FZ3wiOhOc/DTh2u6Q2M/966KwZ uu07gmSTlOoaVlL5DTteTEc/ClTfFAzgH/7MNpsU=
Date: Mon, 08 Jun 2020 11:40:42 -0700
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3739/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Why do we have final size? (#3739)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ede862aef721_39363fd32c2cd96010109f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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, 08 Jun 2020 18:41:21 -0000

@MikeBishop commented on this pull request.

> @@ -908,10 +908,13 @@ final size is the number of bytes sent.  More generally, this is one higher
 than the offset of the byte with the largest offset sent on the stream, or zero
 if no bytes were sent.
-For a stream that is reset, the final size is carried explicitly in a
-RESET_STREAM frame.  Otherwise, the final size is the offset plus the length of
-a STREAM frame marked with a FIN flag, or 0 in the case of incoming
-unidirectional streams.
+The final size of a stream is always signaled to the recipient.  The final size
+is the sum of the Offset and Length fields of a STREAM frame with a FIN flag,
+noting that the length might be implicit.  Alternatively, the Final Size field

True.  That will only be the case when a stream has only one STREAM frame, so it would be _unusual_ for the final STREAM frame to have an implicit Offset, but it's certainly not prohibited.

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