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

[Lucas Pardue <[e-mail]>]

This is a good point. I've been operating under an assumption that a QUIC transport acknowledgement is equivalent to a SETTINGS_ACK but I'm now not sure that is true; the application layer may still not have processed the received SETTINGS.

I think the unilateral declaration is ok. For the asymmetric case like headers, the settings are independent and endpoints use the received value. For a new feature that affects the connection equally simple AND logic seems ok (feature is only 'on' if both declare it so). That's how Server Push used to work before the setting was replaced by MAX_PUSH_ID.

I don't know if @kazuho's latch proposal allows more than one type basic negotiation - server advertises multiple integer values (A, B, or C), client selects a value. On another ticket I suggested that a design that uses integer only SETTINGS parameters with an AND-logic approach can be used to enable a more complicated negotiation mechanism i.e. use SETTINGS to inform the peer that you are intending to send a new negotiation FRAME type followed later by the feature FRAME type.

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