Re: [TLS] Application-Layer Protocol Settings

How would this work with regular SETTINGS?  HTTP/2 and HTTP/3 have disjoint
setting number spaces, and it's unclear to me whether there's any
significant overlap between those.

On Tue, Jul 21, 2020 at 11:49 AM David Benjamin <davidben@chromium.org>
wrote:

> On Tue, Jul 21, 2020 at 8:22 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
> wrote:
>
>>
>> On Mon, Jul 20, 2020 at 10:42 PM David Benjamin <davidben@chromium.org>
>> wrote:
>>
>>> On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue <
>>> lucaspardue..24.7@gmail.com <lucaspardue.24.7@gmail.com>> 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
>>
>
> Ah, gotcha. The thinking was the settings were ALPN-specific anyway, so we
> may as well define them however is more idiomatic for the protocol. This
> means we automatically can make existing H2 and H3 settings more reliable.
> Settings values can also be updated over the course of the connection, so
> using frames keeps continuity there. But, yeah, a separate key/value syntax
> would work too.
>
> (A small correction, the current Client Hint Reliability proposal allows
> ACCEPT_CH to be sent in application data too. Maybe the frontend realizes
> the origin's ACCEPT_CH preferences have changed and wants to notify
> existing connections. Though I don't consider this feature important. I
> doubt most folks, if anyone, will bother with this. Mostly that's how a
> SETTINGS or EXTENDED_SETTINGS value already would have worked, so I figured
> the semantics ought to be compatible in case EXTENDED_SETTINGS is revived.)
>
> David
>