Re: ENABLE ⇒ PROVIDE | Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to disable HTTP/2 Priorities

Matthew Kerwin <matthew@kerwin.net.au> Wed, 31 July 2019 23:07 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98BE120074 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 31 Jul 2019 16:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 k9HBZuyfUFBm for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 31 Jul 2019 16:07:02 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60852120073 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 31 Jul 2019 16:07:02 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hsxek-0004oP-BZ for ietf-http-wg-dist@listhub.w3.org; Wed, 31 Jul 2019 23:05:14 +0000
Resent-Date: Wed, 31 Jul 2019 23:05:14 +0000
Resent-Message-Id: <E1hsxek-0004oP-BZ@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <phluid61@gmail.com>) id 1hsxeh-0004nZ-NV for ietf-http-wg@listhub.w3.org; Wed, 31 Jul 2019 23:05:11 +0000
Received: from mail-io1-f48.google.com ([209.85.166.48]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <phluid61@gmail.com>) id 1hsxef-0005mP-2H for ietf-http-wg@w3.org; Wed, 31 Jul 2019 23:05:11 +0000
Received: by mail-io1-f48.google.com with SMTP id g20so140065303ioc.12 for <ietf-http-wg@w3.org>; Wed, 31 Jul 2019 16:04:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nClqwpkMivvEInZEdXxqB1fPlrOgg/b+lDr+SxufTIo=; b=d6Cf24CzpUzYZZsAtD6N2dCejr0yGh2LpuU3/bslYuQ3tBFY3lsbzPytqy4tSLRnxP +vs4LdyWziNyFax5idSBAHnhgxxUBjO50fTZy5jGPcHmC3x1f3vk22Skc8riJlgoCpq2 mzaXqnV11md5fpFxpTrPmhF09h5oNKcwkVaZN7nVz89zjpF4EgGwZbAdKNjw9dhjSLwm 2K3L3B1HTDHCsDwSIe+m+ktWrqdz6B6U93OYhOGN/uDbq2OkmcpMHRPrrmSe+jyTP/VC LR2B3qaZdpWi4c6Ex+azDxt8QuskzsTG5CnZbahDObzM1YbtTZCmqh3Wc+kwXJLL0WoN 0oNg==
X-Gm-Message-State: APjAAAXHROmvi9XSYA2vQWC5NIs2R/4wgxCrdBkOhCpSn7OyGs/Nhu1F kDT7rZi3Fysp2NG33+w1fEejrZ3GSIO7HDSc3XE=
X-Google-Smtp-Source: APXvYqx53rfXREozDa+C+XbaMna+q/7OzDHSKSKFuN8bMePnqrqpU3MwlDzNeFqkvZtWfrkTjtFK43DgUt5Owzn8Jdw=
X-Received: by 2002:a02:4484:: with SMTP id o126mr129508316jaa.34.1564614287580; Wed, 31 Jul 2019 16:04:47 -0700 (PDT)
MIME-Version: 1.0
References: <20190725191746.GB12596@ubuntu-dmitri> <20190730154809.BBE3412178@welho-filter1.welho.com> <CALGR9oZnKo1JXnxLiKp+04kJeT5Uek3BiCPq=XSq4dG4B3AUBA@mail.gmail.com> <CACweHNDChKtVBTzQGctxAFdgZydrOKt8a9oAKrYbbq1JKLFPNg@mail.gmail.com> <20190731180108.D385BC3F0A@welho-filter2.welho.com>
In-Reply-To: <20190731180108.D385BC3F0A@welho-filter2.welho.com>
From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Thu, 1 Aug 2019 09:04:38 +1000
Message-ID: <CACweHNCMr5WVOudrQnWBmPQUWg-NoacrCJLDcwbFA_6MiXs4=A@mail.gmail.com>
To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Lucas Pardue <lucaspardue.24.7@gmail.com>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>, Brad Lassey <lassey@chromium.org>, Kari Hurtta <khurtta@welho.com>
Content-Type: multipart/alternative; boundary="000000000000d26544058f0226a4"
Received-SPF: pass client-ip=209.85.166.48; envelope-from=phluid61@gmail.com; helo=mail-io1-f48.google.com
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Hub-Spam-Report: AWL=-1.128, BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.201, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1hsxef-0005mP-2H 823256c562564296d8e0ccdf221a98aa
X-Original-To: ietf-http-wg@w3.org
Subject: =?UTF-8?Q?Re=3A_ENABLE_=E2=87=92_PROVIDE_=7C_Re=3A_SETTINGS=5FPRIORITY=5FSCHEM?= =?UTF-8?Q?E_=7C_Re=3A_Setting_to_disable_HTTP=2F2_Priorities?=
Archived-At: <https://www.w3.org/mid/CACweHNCMr5WVOudrQnWBmPQUWg-NoacrCJLDcwbFA_6MiXs4=A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36894
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: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Thu, 1 Aug 2019 at 04:10, Kari Hurtta <hurtta-ietf@elmme-mailer.org>;
wrote:

> > On Wed., 31 Jul. 2019, 02:56 Lucas Pardue, <lucaspardue.24.7@gmail.com>;
> > wrote:
> >
> > > Hi Kari,
> > >
> > > On Tue, Jul 30, 2019 at 4:52 PM Kari Hurtta <
> hurtta-ietf@elmme-mailer.org>;
> > > wrote:
> > >
> > >> Why boolean ("ENABLE") ?
> > >
> > >
>
> >
> > At the risk of bike-shedding, I think calling it "enable" is a bit of an
> > issue. The setting, as an advertisement of the sender's capability,
> should
> > say something like "will ignore" (for disabling 7540 priorities) or "can
> > understand" (for enabling some other scheme).
> >
> > Unless we also feel the need to advertise "will not send"?
> >
> > Cheers
> > --
> > Matthew Kerwin
>
> Yes,
>
>
> SETTINGS_ENABLE_* typically changes how HTTP/2 connection is
> prosessed or allows some usages which otherwise produce
> protocol error (example: SETTINGS_ENABLE_CONNECT_PROTOCOL).
>
> Therefore these these typically allows only 0 ⇒ 1 transitions.
> Feature which is enabled, is not allowed to be turned off because
> it may effect handling of frames which are already sent by
> other peer.
>
>
"Typically"?  In the old testament there is only one 'ENABLE' type setting,
and its initial value is 1.  The extended canon introduces a single new
setting that works the other way.

Also remember: the initial handshake includes settings, so these can be
disabled from the beginning; and: settings have an ACK, so you have a
definite epoch where "already sent" no longer applies.

But yeah. what's significant about them is, 1 or 0, what they say is: "the
recipient of this setting must/must not send a frame of this type".  I.e.
the sender of the setting says, "I will/won't understand these frames".
It's not "I will/won't *send* them myself."  I think that means we're
agreeing that 'ENABLE' isn't the right word.



> Therefore I think that
>
>     SETTINGS_PROVIDE_HTTP2_PRIORITIES
>
> is better name than
>
>     SETTINGS_ENABLE_HTTP2_PRIORITIES
>
>
> In other words this does not chahneg parsing of HTTP/2
> frames. Even when this is set to 0, sending priorities
> does not cause protocol error.
>
> In SETTINGS_PROVIDE_HTTP2_PRIORITIES server asks
> client to provide (or not provide) http/2 tree
> priorities.
>
>
> ( Another possible name is
>
>   SETTINGS_PROVIDE_TREE_PRIORITIES
>
> )
>
> / Kari Hurtta
>

Cheers
-- 
  Matthew Kerwin
  https://matthew.kerwin.net.au/