Re: [TLS] Application-Layer Protocol Settings

[Lucas Pardue <[e-mail]>]

On Mon, Jul 20, 2020 at 10:42 PM David Benjamin <[e-mail]>
wrote:

> On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue <[e-mail]>
> 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] -
https://tools.ietf.org/html/draft-bishop-httpbis-extended-settings-01#section-3.1.1