Re: Clarification on HPACK dynamic table size increases?

Martin Thomson <martin.thomson@gmail.com> Tue, 17 March 2015 16:46 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88591A879D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 17 Mar 2015 09:46:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.712
X-Spam-Level:
X-Spam-Status: No, score=-6.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUTr3NWk9gSy for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 17 Mar 2015 09:46:53 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BFE31A8799 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 17 Mar 2015 09:46:53 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YXubL-0004l5-MS for ietf-http-wg-dist@listhub.w3.org; Tue, 17 Mar 2015 16:44:19 +0000
Resent-Date: Tue, 17 Mar 2015 16:44:19 +0000
Resent-Message-Id: <E1YXubL-0004l5-MS@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <martin.thomson@gmail.com>) id 1YXubF-0004kO-HZ for ietf-http-wg@listhub.w3.org; Tue, 17 Mar 2015 16:44:13 +0000
Received: from mail-ob0-f177.google.com ([209.85.214.177]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1YXubE-0002Lx-La for ietf-http-wg@w3.org; Tue, 17 Mar 2015 16:44:13 +0000
Received: by obdfc2 with SMTP id fc2so11828227obd.3 for <ietf-http-wg@w3.org>; Tue, 17 Mar 2015 09:43:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UXQ05R/EqJ7wbxltSLOFERSC0p2VJt1GFDAurW6+Z6I=; b=sWoWtpejxl5h6Y/8E94gvWi0ZRt6Yzeqjiw/mLYpuyOTeWm4k1rb/U2Boz5yYOGjoH FY6lgD1ZZUX9Lr69cTmzV87oRF5su4eHgfSsrf6MnSINpuwrkPJftQKQUUSssWPGOOVb G1yqz4d+L6y6Du0CPd6zf05BGEG/NDLfKzdSxRlcjB9IbL3X1xDnpk0FLH0txg+iKn1m +dJFi4NFwpqGTaXe4swKZSpUZLTUy3vChI+4KRChNF4auXkix8Gzk4HYt3yOjsOucmEG G1GvnziSgcUU24Gx2W5Wb+m/VfaGaRyAsRt7fz8WhJFGvbinnfr9kOXhdEXsaVQFPz16 565Q==
MIME-Version: 1.0
X-Received: by 10.202.169.198 with SMTP id s189mr11922213oie.21.1426610626902; Tue, 17 Mar 2015 09:43:46 -0700 (PDT)
Received: by 10.202.48.151 with HTTP; Tue, 17 Mar 2015 09:43:46 -0700 (PDT)
In-Reply-To: <55083AA6.8010507@crf.canon.fr>
References: <CAEnbY+fx3YSvpsEefP9u9=KXh2QaF=m+QdTXVzB8KKK91nacGA@mail.gmail.com> <BL2PR03MB13254980CFB31A76C197F9C87060@BL2PR03MB132.namprd03.prod.outlook.com> <55083AA6.8010507@crf.canon.fr>
Date: Tue, 17 Mar 2015 09:43:46 -0700
Message-ID: <CABkgnnV0v4UQb7Tc+K3m2pcXw8+gF=iD93hunABya-N5LivHuA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Hervé Ruellan <herve.ruellan@crf.canon.fr>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.214.177; envelope-from=martin.thomson@gmail.com; helo=mail-ob0-f177.google.com
X-W3C-Hub-Spam-Status: No, score=-5.9
X-W3C-Hub-Spam-Report: AWL=-0.101, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-2, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1YXubE-0002Lx-La a74b9dbaf4527c442f192f6a6543fe1c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Clarification on HPACK dynamic table size increases?
Archived-At: <http://www.w3.org/mid/CABkgnnV0v4UQb7Tc+K3m2pcXw8+gF=iD93hunABya-N5LivHuA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/28985
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On 17 March 2015 at 07:31, Hervé Ruellan <herve.ruellan@crf.canon.fr> wrote:
>
>
> On 03/13/2015 12:49 AM, Mike Bishop wrote:
>>
>> 6.3 isn't saying that the value can only be reduced.  There is a maximum
>> that the decompressor has said it's willing to allow the compressor, and the
>> compressor is allowed to choose any value <= what the decompressor allows
>> it.  The wording there could be cleaner, since there's a maximum table size,
>> and a maximum value *for* the maximum table size.  :-(
>>
>> -----Original Message-----
>> From: Daurnimator [mailto:quae@daurnimator.com]
>> Sent: Thursday, March 12, 2015 3:53 PM
>> To: ietf-http-wg@w3.org
>> Subject: Clarification on HPACK dynamic table size increases?
>>
>> I'm working on implementing HPACK, wanted clarification on whether the
>> dynamic table can grow:
>>
>>> From 4.2
>>> This mechanism can be used to completely clear entries from the dynamic
>>> table by setting a maximum size of 0, which can subsequently be restored.
>>
>>
>> However, 6.3 has a MUST that the table may only be reduced in size:
>>>
>>> The new maximum size MUST be lower than or equal to the last value of the
>>> maximum size of the dynamic table.
>>
>>
>>
>> Regards,
>> Daurn.
>>
>
> I agree that 4.2 isn't very clear, and that 6.3 is misleading. I just
> created a pull request for correcting 6.3:
> https://github.com/http2/http2-spec/pull/729


Note that pull requests won't reach the spec.  We'll have to let the
RFC editor know what changes to make.  (And we need to be extra
careful to avoid breaking changes).