Re: Repurpose of protocol elements | Re: Repurpose of priority | ⋯ | Re: Setting to disable HTTP/2 Priorities

Lucas Pardue <lucaspardue.24.7@gmail.com> Tue, 13 August 2019 19:51 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 F361812018B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 13 Aug 2019 12:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 770XW5ZJ3s6y for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 13 Aug 2019 12:51:22 -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 7CBA8120898 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 13 Aug 2019 12:51:22 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hxcnD-0004Tf-Q5 for ietf-http-wg-dist@listhub.w3.org; Tue, 13 Aug 2019 19:49:15 +0000
Resent-Date: Tue, 13 Aug 2019 19:49:15 +0000
Resent-Message-Id: <E1hxcnD-0004Tf-Q5@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 <lucaspardue.24.7@gmail.com>) id 1hxcn9-0004So-A2 for ietf-http-wg@listhub.w3.org; Tue, 13 Aug 2019 19:49:11 +0000
Received: from mail-vs1-xe32.google.com ([2607:f8b0:4864:20::e32]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <lucaspardue.24.7@gmail.com>) id 1hxcn7-00063q-5l for ietf-http-wg@w3.org; Tue, 13 Aug 2019 19:49:10 +0000
Received: by mail-vs1-xe32.google.com with SMTP id 2so72962516vso.8 for <ietf-http-wg@w3.org>; Tue, 13 Aug 2019 12:48:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kPV3AcNHoUA9O0+NjUP+iitqDLimzJNiPjS8toEcz/o=; b=gJlHn3dQqi85ZWWB2gHREd6cpBHUdBGWzyW4JL804Eg9hk9Y6vA8d8rbLn20VbRgyp lvWBlYlsCWYGLGLwbV2sBhDTxKTvtxsoYKXqL3IKatGk+SR/ny9UHhXSBQv2rH0p3al8 3vZ5z+MWXDMBvVlwadBsaPmeXVjj4omVkJI9DqTeo7QPV0gE7E75KZGH0330JUEe4EzO dipuaDdwT2YoNR85QItbRYDU3plGE5Qkap6GzPHdchDe+uDKcvxuUFhiA7FuMI7lW6xh IfA/6zqAFQf9b4jwQW6xwG2pHMh8wuGTWsY+BOvO7LJywD5W/bucN90OiRsCKBOYejAa /xww==
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=kPV3AcNHoUA9O0+NjUP+iitqDLimzJNiPjS8toEcz/o=; b=YiYw2dymDO+a4vZjII0LHKBlStMay7Pzh5MkaDIRfkrWWfKMsHRuYhjt+CiitJPnCS tkrj89+Ct1rgOct1DlT58pd/txj1pPl8bsk9Y9vhgO63yqAnRtMVEmtmFoS6kZzftxXc VQTezM8HAFWai8FENedGIBeKNKED5LTrQM7wN+5aTdfzKH2ea2oViN7gE65VfJ2wRL9R 4amVs3OPlbBCY+u70jlMs4VDyUc+JZglWc1OlGak/pvFTGGH/ZOMiVuwtvXdJjUYWW4u syvHtvYNKa5j60sfvACIhvU0hhLfpFgj1zEA51CBqvT/K2J0ZNTNi83+r+j3goO6I3aL 8tNw==
X-Gm-Message-State: APjAAAXDmZYdfWccCqxhcKKqB+IIVnMNbM7UFOxLH9FtiDrMVEMjoy9F J++M4AYhaz26Oh1okBX8127VYVFiWxbTY9VgpdDiYQ==
X-Google-Smtp-Source: APXvYqzEFvlIJTLOVF2r2kgSrIiAVTXTQRn4QdoRoazpc0u5MtsD3d0Z2TrsPE6tkzVfl6hb4jlUuFGCo71COGbXlAo=
X-Received: by 2002:a67:3141:: with SMTP id x62mr10283329vsx.15.1565725728167; Tue, 13 Aug 2019 12:48:48 -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> <20190801164638.522628CD1@welho-filter3.welho.com> <CALGR9obEjQnFTSnyUjx40vd8EvwHLjuovNxjWaT_3euKcnm1Hg@mail.gmail.com> <20190803080758.2CDEC4552F@welho-filter4.welho.com> <CY4PR22MB0983632F7DCA64E22028D4BEDAD20@CY4PR22MB0983.namprd22.prod.outlook.com>
In-Reply-To: <CY4PR22MB0983632F7DCA64E22028D4BEDAD20@CY4PR22MB0983.namprd22.prod.outlook.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Tue, 13 Aug 2019 20:48:39 +0100
Message-ID: <CALGR9oY8ymGqJDKFsWjkqf2qXVhvkNHo8WUo17F5S-7_CZFNOQ@mail.gmail.com>
To: Mike Bishop <mbishop@evequefou.be>
Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP Working Group <ietf-http-wg@w3.org>, Matthew Kerwin <matthew@kerwin.net.au>, Brad Lassey <lassey@chromium.org>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>
Content-Type: multipart/alternative; boundary="000000000000d7e5cc059004edff"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e32; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-vs1-xe32.google.com
X-W3C-Hub-Spam-Status: No, score=-2.4
X-W3C-Hub-Spam-Report: AWL=1.477, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1hxcn7-00063q-5l 9492c1a42cdf4ec2cfdcfe2b91ac7590
X-Original-To: ietf-http-wg@w3.org
Subject: =?UTF-8?Q?Re=3A_Repurpose_of_protocol_elements_=7C_Re=3A_Repurpose_o?= =?UTF-8?Q?f_priority_=7C_=E2=8B=AF_=7C_Re=3A_Setting_to_disable_HTTP=2F2_Priorities?=
Archived-At: <https://www.w3.org/mid/CALGR9oY8ymGqJDKFsWjkqf2qXVhvkNHo8WUo17F5S-7_CZFNOQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36975
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>

Hi Mike,

On Tue, 13 Aug 2019, 19:48 Mike Bishop, <mbishop@evequefou.be>; wrote:

> This form of negotiation appears to presuppose sending multiple SETTINGS
> frames.  First you advertise that something is available, and only if it's
> available on the other side do you then declare that you're sending it.
>
>
>
> HTTP/3 only permits a single SETTINGS frame in each direction, and for
> latency reasons you really shouldn't wait to see the peer's values before
> sending your own.  Therefore, I think you wind up in one of three postures
> for negotiating something like this:
>
>    - Each side declares their supported schemes.  There is a defined
>    algorithm by which each side, having both declarations, can conclude the
>    most mutually-preferred scheme.  Clients can’t generate PRIORITY frames
>    until they’ve seen the server’s declaration.
>    - The server declares its supported schemes, each of which will use
>    different frame types.  The client SHOULD NOT send more than one scheme
>    simultaneously (but perhaps MAY send all of them until it sees the SETTINGS
>    frame).
>    - Define a separate extension which is used for negotiation separate
>    from SETTINGS.
>
>
>

I agree. If I were to enumerate your points, then for point 1 Brad has some
WIP text that makes our initial proposal more robust in this sense.  And
for point 3 I have a strawman not-yet-shared negotiation mechanism that
uses extension frames in the manner you describe. Though seeing it written
down I'm not convinced it doesn't generate another set of complication.

Lucas

> -----Original Message-----
> From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>;
> Sent: Saturday, August 3, 2019 3:58 AM
> To: Lucas Pardue <lucaspardue.24.7@gmail.com>;; HTTP Working Group <
> ietf-http-wg@w3.org>;
> Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>;; HTTP Working Group <
> ietf-http-wg@w3.org>;; Matthew Kerwin <matthew@kerwin.net.au>;; Brad Lassey
> <lassey@chromium.org>;; Dmitri Tikhonov <dtikhonov@litespeedtech.com>;
> Subject: Repurpose of protocol elements | Re: Repurpose of priority | ⋯ |
> Re: Setting to disable HTTP/2 Priorities
>
>
>
> > Any client that is taking the chance to make a semantic change to the
>
> > frames it is sending would be foolish to not wait on an affirmative
>
> > signal from the server. RFC 7540 Section 5.5. calls specific attention
>
> > to such a
>
> > repurposing:
>
> >
>
> > >    Extensions that could change the semantics of existing protocol
>
> >    components MUST be negotiated before being used.  For example, an
>
> >    extension that changes the layout of the HEADERS frame cannot be used
>
> >    until the peer has given a positive signal that this is acceptable.
>
> >
>
> > Lucas
>
>
>
> Okei,
>
>
>
> Generally repurpose of protocol element requires 3 values (or 2 bits from
> bitmask) for SETTINGS parameter SETTINGS_ENABLE_{feature}.
>
> For example values
>
>
>
> •  0       {feature}_NOT_SUPPORTED,
>
> •  1       {feature}_AVAILABLE
>
> •  3       SENDING_{feature}
>
>
>
>
>
> Recipient of repurposed protocol element sends first SETTINGS parameter
> SETTINGS_ENABLE_{feature} with value
>
> 1 ({feature}_AVAILABLE).
>
>
>
>
>
> Sender of repurposed protocol element sends SETTINGS parameter
> SETTINGS_ENABLE_{feature} with value 3 (SENDING_{feature}) before it starts
> sending repurposed protocol element.
>
>
>
>
>
> Recipient interprets protocol element without {feature}
>
> until it receives SETTINGS parameter SETTINGS_ENABLE_{feature}
>
> with value 3 (SENDING_{feature}).
>
>
>
>
>
> Sending SETTINGS parameter SETTINGS_ENABLE_{feature} with
>
> value 3 (SENDING_{feature}) is protocol violation unless
>
> SETTINGS parameter SETTINGS_ENABLE_{feature} with value
>
> 1 ({feature}_AVAILABLE) or 3 (SENDING_{feature}) is received
>
> first.
>
>
>
> Both directions needs separately send SETTINGS parameter
>
> SETTINGS_ENABLE_{feature} with value 3 (SENDING_{feature})
>
> before repurposed protocol element can be sent.
>
>
>
> SETTINGS parameter SETTINGS_ENABLE_{feature} value 3 (SENDING_{feature})
>
> imply total ordering of frames, so this means HTTP/2. ( Also
>
> HTTP/3 do not allow several SETTINGS frames.)
>
>
>
> SETTINGS frame with parameter SETTINGS_ENABLE_{feature} with
>
> value 3 (SENDING_{feature}) indicates time when change
>
> on purpose of protocol element happens.
>
>
>
> It is not just enough to know that change is acceptable
>
> for recipient. Recipient must know when change happens.
>
>
>
> Introducing of new protocol elements do not require
>
> sending SETTINGS parameter SETTINGS_ENABLE_{feature}
>
> with value 3 (SENDING_{feature}) when frame content
>
> indicates precense of protocol element.
>
>
>
> / Kari Hurtta
>
>
>
>
>