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 <vasi...@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 <david...@chromium.org> > wrote: > >> On Tue, Jul 21, 2020 at 8:22 AM Lucas Pardue <lucaspardue.2...@gmail.com> >> wrote: >> >>> >>> On Mon, Jul 20, 2020 at 10:42 PM David Benjamin <david...@chromium.org> >>> wrote: >>> >>>> On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue < >>>> lucaspardue..2...@gmail.com <lucaspardue.2...@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 >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
