Re: [quicwg/base-drafts] Send complete SETTINGS (#2972)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> @@ -1396,22 +1396,25 @@ servers, the initial value of each client setting is the default value.
 For clients using a 1-RTT QUIC connection, the initial value of each server
 setting is the default value. When a 0-RTT QUIC connection is being used, the
 initial value of each server setting is the value used in the previous session.
-Clients MUST store the settings the server provided in the session being resumed
-and MUST comply with stored settings until the current server settings are
-received.  A client can use these initial values to send requests before the
+Clients SHOULD store the settings the server provided in the session being
+resumed and MUST comply with stored settings until the current server settings

Yeah, this complicates the text somewhat.  If the intent is to have clients comply with either defaults or whatever they remember, then maybe:

Clients SHOULD store the settings the server provided in the connection where resumption information was provided.  A client MUST comply with either stored settings - or default values if no values are stored - when attempting 0-RTT.  Once a server has provided new settings, clients MUST comply with those values.

> @@ -1396,22 +1396,25 @@ servers, the initial value of each client setting is the default value.
 For clients using a 1-RTT QUIC connection, the initial value of each server
 setting is the default value. When a 0-RTT QUIC connection is being used, the
 initial value of each server setting is the value used in the previous session.
-Clients MUST store the settings the server provided in the session being resumed
-and MUST comply with stored settings until the current server settings are
-received.  A client can use these initial values to send requests before the
+Clients SHOULD store the settings the server provided in the session being
+resumed and MUST comply with stored settings until the current server settings
+are received.  If the client did not store, or did not receive, server settings
+from the previous session, the initial value of each setting is the default
+value.  A client can use these initial values to send requests before the

This business about defaults can be split into a new paragraph, ideally one preceding this more complicated part.

> Settings assume default values prior to receiving a SETTINGS frame, or if the SETTINGS frame does not include a value for the setting.  Endpoints can use these default values to send requests before receiving the a SETTINGS frame.

>  server's SETTINGS frame has arrived.  This removes the need for a client to wait
 for the SETTINGS frame before sending requests.
 
 A server can remember the settings that it advertised, or store an
 integrity-protected copy of the values in the ticket and recover the information
 when accepting 0-RTT data. A server uses the HTTP/3 settings values in
-determining whether to accept 0-RTT data.
+determining whether to accept 0-RTT data.  If the server cannot recover the
+settings from a session being resumed, it MUST NOT accept 0-RTT data.

I don't think that we're mandating the use of session tickets, even if that is the most common method of implementing these.

I think that "recover" is probably still right, though it might be clearer here if we say "If a server cannot determine that the settings remembered by a client are compatible with its current settings, it MUST reject 0-RTT."

Then we need to define what "compatible" means.

>  
 A server MAY accept 0-RTT and subsequently provide different settings in its
 SETTINGS frame. If 0-RTT data is accepted by the server, its SETTINGS frame MUST
 NOT reduce any limits or alter any values that might be violated by the client
-with its 0-RTT data.  The server MAY omit settings from its SETTINGS frame which
-are unchanged from the initial value.
+with its 0-RTT data.  The server MUST include all settings which differ from
+their default values, even if the value is unchanged from the previous session.

I might drop the bit from the comma onwards.  The only case we have two values is in 0-RTT (not resumption, as this implies) and that text is now very clear that the remembered values only apply until SETTINGS arrives.

-- 
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/pull/2972#pullrequestreview-276307666