Re: [quicwg/base-drafts] When to send the SETTINGS frame (#2945)

[Martin Thomson <[e-mail]>]

@kazuho, Are you suggesting an asymmetry?  That is, the client uses a frame and the server uses EncryptedExtensions?  Or do we pack this into transport parameters?

I can see the appeal of that.  As information that relates to the connection, this sort of thing naturally rolls up into the handshake.  And the client is the only one with an acute need to have the associated state persisted beyond the lifetime of the connection.  The server might still suffer head-of-line blocking for client settings, but we've already established that the need is much less severe.

I have something of a dramatic suggestion.  It's one that was thorough poo-pooed when I suggested it the first time.  If Lucas can do the crazy-talk thing, so can I.

We can move the TLS session ticket up two layers and send it in h3.  Then we can bind whatever state we like into it.  And we get nice deterministic ordering if we want.  That's complicated for a bunch of reasons, but if you look at the implementation of tickets, I think that you end up writing most of that complexity into the stack anyway.  I've only implemented the transport-layer interaction with tickets and it's already pretty thorny.

I realize that this opens a lot of awkward questions, but it might be worth the effort to address them.

-- 
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/2945#issuecomment-517519259