Re: [quicwg/base-drafts] Asymmetry in the handling of SETTINGS frame (#1846)

[Mike Bishop <[e-mail]>]

@kazuho, am I right that the general statement for your model is that there are three sets of settings exchanged:
1. Server's initial (SETTINGS frame in 1-RTT, remembered in 0-RTT)
2. Client's initial (SETTINGS frame always)
3. Server's update (not present in 1-RTT, SETTINGS frame in 0-RTT; cannot reduce values, but can increase them)

You'd then say that you must have received the previous item before you can generate the subsequent one?  That would certainly enable consistent offer-select semantics for settings; the limitation is that any option the server adds during (3) isn't actually available until the next connection, when it's part of the implicit (1).  However, that's true of the existing model as well unless there's an explicit change mechanism built in (see QPACK table size).

(BTW, change of compressor / static table doesn't actually require an offer-select negotiation because the two directions are independent.  Each side sends the set that it supports in preference order, then the result is that the other side will receive its most preferred (first in its list) which occurs in the overlap.  That could result in different selections in each direction, but that's not a bad thing in many cases -- separate static tables for clients and servers, for example.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1846#issuecomment-428383163