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

Mike Bishop <> Tue, 09 June 2020 13:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C2163A092B for <>; Tue, 9 Jun 2020 06:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.517
X-Spam-Level: ***
X-Spam-Status: No, score=3.517 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, 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 YRPdG1z3CKXA for <>; Tue, 9 Jun 2020 06:29:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 331D63A0929 for <>; Tue, 9 Jun 2020 06:29:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4DECF520DBB for <>; Tue, 9 Jun 2020 06:29:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1591709360; bh=FjMj3zig/+0vdnHqvRBlHQRY8O93XLcyHXt/6E2YnIQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=AR6e28BjVGoclJM0F2APpA72VRA8QQlbTVMZGMpvuGILvPk0GJkxn6w42kAQmcY1k 3Hi4KO9optSejW4YJ7grbIKwxxyPp3zMdr1Lo31mI7FmkI8pAFN8nei+W67wjMKPig 3qe5elzdw9hYjWWyp09nGlP+ONEoMSnE+BC8CoME=
Date: Tue, 09 Jun 2020 06:29:20 -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_5edf8eb03e8d4_26f73f94824cd9601314e7"; 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: Tue, 09 Jun 2020 13:29:23 -0000

@MikeBishop commented on this pull request.

> +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 these fields might be implicit.  Alternatively, the Final Size field
+of a RESET_STREAM frame carries this value.  This ensures that all ways that a
+stream can be closed result in the number of bytes on the stream being reliably

Both the Offset and Length fields can be implicit.  As discussed above, it would be unusual (at least with HTTP/3 for both to be implicit, but it's certainly allowed.  I think if the fields specifically get mentioned, the aside that they might be implicit needs to remain.  If we switch to pointing to the values, we could drop that, but it might be confusing to some people.

FIN isn't a field, and isn't contemplated by the aside about implicit fields.

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