Re: [quicwg/base-drafts] QPACK: Clarify how maximum dynamic table capacity can be set (#2330)

afrind <> Mon, 14 January 2019 17:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5BD212896A for <>; Mon, 14 Jan 2019 09:51:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -12.552
X-Spam-Status: No, score=-12.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 E-z_w5p5XJbv for <>; Mon, 14 Jan 2019 09:51:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55BAF1286E7 for <>; Mon, 14 Jan 2019 09:51:43 -0800 (PST)
Date: Mon, 14 Jan 2019 09:51:41 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1547488301; bh=kxIxDu4EWhsrBt2cg1oEbF4YdP2omP371A5gDxEaXEA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=zu+f1lW6H5UdSPyzCr45GnYhyMURVnOe5jYN0NzMC96CK2NsNJqEDY1U8G0E3qO64 S+WDeS8qkYwhYik47ROOrRwEiU+GwDfng69+sFDu40Aw8DWKfnvy1myEwJFNnob0CU mMaWhhVzBTP6/JdnXiQDpHctV/WcZ1QTFy8YoWeI=
From: afrind <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2330/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] QPACK: Clarify how maximum dynamic table capacity can be set (#2330)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c3ccc2de9158_57a43fd45d4d45c4101769"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: afrind
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, 14 Jan 2019 17:51:45 -0000

Sending a MAX in SETTINGS never changes the table capacity.  Sending a set capacity instruction is required if the encoder wants to change capacity.

I agree the 0 -> >0 transition could be handled by reject 0-RTT when an implementation enables the dynamic table after running for some period with it off.  Such cases are probably as rare as the server changing the max capacity it supports.  The argument I have for allowing it is that it's the same case as 1-RTT (client starts at 0, enable dynamic table later), so I don't think the implementation needs to be any more complex to handle it.  But I can live without it also.

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