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> > 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
Received on Tuesday, 21 July 2020 12:22:27 UTC