Re: new type number versus repurpose of existing field | Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to disable HTTP/2 Priorities

Matthew Kerwin <matthew@kerwin.net.au> Thu, 08 August 2019 22:19 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 BEF6612003F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 8 Aug 2019 15:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 US9oSm0h2eQu for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 8 Aug 2019 15:19:36 -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 897AF12002F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 8 Aug 2019 15:19:36 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hvqiB-0005OW-VA for ietf-http-wg-dist@listhub.w3.org; Thu, 08 Aug 2019 22:16:43 +0000
Resent-Date: Thu, 08 Aug 2019 22:16:43 +0000
Resent-Message-Id: <E1hvqiB-0005OW-VA@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 1hvqi7-0005Ng-Fk for ietf-http-wg@listhub.w3.org; Thu, 08 Aug 2019 22:16:39 +0000
Received: from mail-ot1-f47.google.com ([209.85.210.47]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <phluid61@gmail.com>) id 1hvqi5-0001qI-5W for ietf-http-wg@w3.org; Thu, 08 Aug 2019 22:16:39 +0000
Received: by mail-ot1-f47.google.com with SMTP id j11so24613360otp.10 for <ietf-http-wg@w3.org>; Thu, 08 Aug 2019 15:16:16 -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=Zmz1dLc7uCceAh7vdlwnCXt6s9Xf9hk+gAMh0aw/mek=; b=E9awU5wn3T9Oe2MsR+rW513XjuUfTbKNFPfWbqQ4VVgJHfa7LbxgpLx13eZJd3MAW/ Wn+Zl6G1OOfMmkHXyZLBSvdTt2DVZ3QQNTGknG281PQUei10XfbqaLzt0RMszZ5AKNh4 RQknpLrqhc4s8Z4hu3WwYCXvUALupQf/PVW8vAkPpzOgyCjioS5oIW38ae8/Nhw5grF+ RRWuGdme+bMhpjAF8NVH5y2RkL6LUJ4SIZkd/axEmO876pJE+N0yWpgF3/tC3IJEpfmx iH3UVGkioAJDVyfQ2bi5XJTXN47vmX7puypkUegkxBdbFMMva8Qnk8wo2haZdRjRKmmg WE7g==
X-Gm-Message-State: APjAAAWOZvniyVq8rreYBjHKzxA8t21nriNSUbqmum3kDP7hLSHRks3p rd6cLfIvoHcXNNClmoL3ZaWfU7A4EW99y6M7OMI=
X-Google-Smtp-Source: APXvYqyTba1F+bUlnaJtDzsSD6+lsdAX2U+v8UBLxLvrGHEd8EBskjdk2WYgLUGjYVa1e5z+GwLNHkZ6P8cYDMEZJ0U=
X-Received: by 2002:a5d:915a:: with SMTP id y26mr17490520ioq.207.1565302575394; Thu, 08 Aug 2019 15:16:15 -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> <CALGR9oaM2JaAnFJt+e6B87jNYgGd42_fRbycSrqU31tEgR=AEg@mail.gmail.com> <CACweHNBdvqCvDMmgr+=5z9TkQyFYHnE6BMbdUcMG8AJoCDrf3g@mail.gmail.com> <20190808173909.F07B645B6B@welho-filter4.welho.com> <CALGR9oYu9dm0114e7-CY7ENyx1mb5kdeJQc7nyvQeQY97=Bz=A@mail.gmail.com>
In-Reply-To: <CALGR9oYu9dm0114e7-CY7ENyx1mb5kdeJQc7nyvQeQY97=Bz=A@mail.gmail.com>
From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Fri, 9 Aug 2019 08:16:06 +1000
Message-ID: <CACweHNCfHfbFzSe2EWvd28FMGwchijSuCkrLn+eSmtYvU=tYvw@mail.gmail.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP Working Group <ietf-http-wg@w3.org>, Brad Lassey <lassey@chromium.org>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>
Content-Type: multipart/alternative; boundary="000000000000f8f404058fa267d5"
Received-SPF: pass client-ip=209.85.210.47; envelope-from=phluid61@gmail.com; helo=mail-ot1-f47.google.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.252, BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1hvqi5-0001qI-5W 6b4f627e0d01bb8598629ecc68a93667
X-Original-To: ietf-http-wg@w3.org
Subject: Re: new type number versus repurpose of existing field | Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to disable HTTP/2 Priorities
Archived-At: <https://www.w3.org/mid/CACweHNCfHfbFzSe2EWvd28FMGwchijSuCkrLn+eSmtYvU=tYvw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36952
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 Fri, 9 Aug 2019 at 03:58, Lucas Pardue <lucaspardue.24.7@gmail.com>;
wrote:

> Note that it is not my suggestion to do the experiment this way. However,
> one could theorise that the work required to support generating, sending,
> receiving and processing new non-core frame types is greater than
> implementing some conditional code inside the frame parser.
>

One could also theorise the opposite.  For example: if someone had thought
to construct their core H2 engine in such a way that it offloads extension
values to modular/pluggable handlers.

It doesn't make sense to override an auxiliary frame like that, especially
just to appease implementers -- it's not like PRIORITY is welded to the
heart of the machine, like HEADERS.

Yes frames are cheap, but they also offer an API surface that things get
> sticky to. For example, reporting and metrics based on frame type counts
> etc. That adds more overhead to an ad-hoc short-lived data-gathering
> experiment.
>

Good?  Resist the sticky interface.  (BTW, on metrics: how much easier is
it to report on "unknown frame type 0xD" as opposed to "frame that looks
like 0x2 but actually isn't because of the contents of some settings frames
sent elsewhere on this connection"?)

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