Re: [TLS] Application-Layer Protocol Settings

I guess you could have protocol-specific numbers and protocol-independent
syntax? Or you could allocate numbers in yet another number space for all
the existing settings. The latter seems like a lot of fuss, and the former
is kinda weird. At that point you may as well get a protocol-specific blob
(as in the draft) so the protocol library can reuse their preferred parsing
routines.

On Tue, Jul 21, 2020 at 4:22 PM Victor Vasiliev <vasilvv@google.com> wrote:

> 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
>>
>