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

Kazuho Oku <> Mon, 08 June 2020 14:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F34C23A0B57 for <>; Mon, 8 Jun 2020 07:42:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.303
X-Spam-Level: ***
X-Spam-Status: No, score=3.303 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_28=1.404, 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 frJyg9Rn8wGD for <>; Mon, 8 Jun 2020 07:42:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A94663A0B56 for <>; Mon, 8 Jun 2020 07:42:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E4506520C51 for <>; Mon, 8 Jun 2020 07:42:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1591627374; bh=WN9oQdaZP7Fi8UjHKsi3czt0x9yT+5oqP4NAOt9kOzc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ypK39m0YDSjEu3LZewH8W19JmvT4P+qk3QYPI3lu2YxHsQxVurcpywT3/yvwfWva6 eX1adnAVMYj+CligEGfVborWJMHZFyeY2mbpbivzBKqA8yGO9t4JEzaEV0+yQSF43E U9V9UcncRcproDgUKXFoUQ4qrxFAsVWSzVJr3Fho=
Date: Mon, 08 Jun 2020 07:42:54 -0700
From: Kazuho Oku <>
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_5ede4e6ed526a_72853f7f784cd95c141118"; 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, 08 Jun 2020 14:42:57 -0000

@kazuho commented on this pull request.

:+1: LGTM modulo a nitpick.

> @@ -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

Maybe "noting that the offset and the length might be implicit"?

This is an editorial nitpick purely from the viewpoint of consistency, but it is a bit surprising to see only one of the two fields called out as might be implicit, even though both of the fields can be omitted.

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