Re: [TLS] Application-Layer Protocol Settings

Lucas Pardue <> Tue, 21 July 2020 12:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 856E73A0807 for <>; Tue, 21 Jul 2020 05:25:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.018
X-Spam-Status: No, score=-3.018 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.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qzGTUSVlmnQX for <>; Tue, 21 Jul 2020 05:25:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7C243A07F2 for <>; Tue, 21 Jul 2020 05:25:21 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jxrHx-0002Fk-7F for; Tue, 21 Jul 2020 12:22:29 +0000
Resent-Date: Tue, 21 Jul 2020 12:22:29 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jxrHu-0002Eu-PR for; Tue, 21 Jul 2020 12:22:26 +0000
Received: from ([2a00:1450:4864:20::42e]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jxrHs-0003Bk-Vs for; Tue, 21 Jul 2020 12:22:26 +0000
Received: by with SMTP id r12so20902615wrj.13 for <>; Tue, 21 Jul 2020 05:22:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JUlZLoLzmGps33n98Tn7nSydkScfML1Z1ZSixyrR68g=; b=bSzIAaE/vK1gLm/jFMUpX2p+dFfRToBJUrKI+omvXFRp62BpYydsovjSNccAOZKsDR 76XCc8gJQRrX4livZfL1JRuSBineK8MLjzA2NeJYk+hbcDGI4si0D/NJZU2m6DaFrFm8 uFiAcxTBDxJEfXDL2AMx4s+p4vdMP66TeoSFkaHRiERBJGENr6Q1bhTD3kRHy9OXL5tu vaJONNRfud6yq2DuS9RNyi0x1dJ85XMgFcygkk0oWr/hUzieY2rytL8UTbKfhqyaebDV updmENotIl+jua2fYL5KC5lyfyGs8urldpi1HObWSSnEWMtFTlL6d0BSWWitGYqz1GTF QR4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JUlZLoLzmGps33n98Tn7nSydkScfML1Z1ZSixyrR68g=; b=pMqpX3QdnoqMule7+KGpwvVlbgXi4JG8y+twsXTMLFAMVGumvapTNH/Bq/vq9LB8BI y+ulMaQ75GjKqT0s32VNjIOGmDTFdnoFNfQhdADfisgeefzvNgc6fGfL13ODeLUGz8Xw Aj3q7p4+Hgzk/DjBbK4IybuvxChfXZ9s+g+sKduAQBOeX9+PXo9bp4KxJw2gMTg2r49a Y9HdkBQCVKos6HvvWhhC27XS6cvk/G+S0twnfHvBulDeW4W0yD2Ai0hQMbiGmh2razbi W1oezQMe1qhPmzJriyVAP+Jt/NNT0BFihkpNmmOCWBFYP0mrdhdpQE97mIU7QMq4Jp4j 0kBg==
X-Gm-Message-State: AOAM533Gze5Tba+JucZj/a0LycwZIlXfLl0ULT1A/TdRo78B4TiXggpC 7T39RQcH1FxjFubSeChG58evBRyWSm4XAHJR6Ik=
X-Google-Smtp-Source: ABdhPJzwghNQSVsT9MASbFiAgmlSiEa+G7uX4y2WlOBBQ9QwYH6dZ85ZCm4Ghfrc8K2r/yHM/b9yiU7UKaOYtNnOId4=
X-Received: by 2002:adf:dcc9:: with SMTP id x9mr13017986wrm.153.1595334133536; Tue, 21 Jul 2020 05:22:13 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Tue, 21 Jul 2020 13:22:02 +0100
Message-ID: <>
To: David Benjamin <>
Cc: Victor Vasiliev <>, "" <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="00000000000053dd0205aaf2acec"
Received-SPF: pass client-ip=2a00:1450:4864:20::42e;;
X-W3C-Hub-Spam-Status: No, score=-7.8
X-W3C-Scan-Sig: 1jxrHs-0003Bk-Vs 15596aafc86a0f2c3d0d811c3f9a8005
Subject: Re: [TLS] Application-Layer Protocol Settings
Archived-At: <>
X-Mailing-List: <> archive/latest/37898
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Mon, Jul 20, 2020 at 10:42 PM David Benjamin <>

> On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue <>
> wrote:
>> That makes sense but I guess I don't see the point in defining a new
>> thing that contains frames that are never sent on streams. That is, if
>> these are connection settings, just send the payload. Unframed extended
>> settings might get you there, if you can find a way to encapsulate
>> conventional settings inside them, then all the better.
> Could you elaborate on this a bit? I'm probably just failing to parse, but
> I'm not sure which alternative you're suggesting here. (Ah, the wonders of
> email.)
> David

I was trying to accommodate HTTP/2 and HTTP/3 in one breath, which is why
my intent was probably unclear. Basically, if ALPS relies on frames for
per-protocol settings then it has to accommodate the differences in frame
format between HTTP/2 and HTTP/3. In the examples from the ALPS and Client
Reliability proposals, the H2 frame needs to populate the frame header and
it pick stream 0, which doesn't exist until the connection is actually
made, so seems a bit kludgy. In H3, frames don't have the stream ID so you
avoid the problem above.

So my thought was to basically do away with the notion of protocol-specific
frames in ALPS, and instead define the a common payload format that perhaps
looks something like bishop-extended-settings [1], a series of
Type-Length-Value (but without any frame headers). This would allow you to
encode the old and new settings in a single format, rather than needing to
delineate things via frames.

[1] -