Re: [quicwg/base-drafts] Refine Discussion of 0-RTT Transport Parameters (#2467)

[Mike Bishop <[e-mail]>]

MikeBishop approved this pull request.

Looks reasonable to me.  I'm not opposed to @ianswett's suggestion that lets future transport parameters decide whether they need to be remembered or not, either.

> -A server MAY accept 0-RTT and subsequently provide different values for
-transport parameters for use in the new connection.  If 0-RTT data is accepted
-by the server, the server MUST NOT reduce any limits or alter any values that
-might be violated by the client with its 0-RTT data.  In particular, a server
-that accepts 0-RTT data MUST NOT set values for the following parameters
-({{transport-parameter-definitions}}) that are smaller
-than the remembered value of those parameters.
+The value of the server's previous original_connection_id, preferred_address,
+stateless_reset_token, and ack_delay_exponent MUST NOT be used when
+establishing a new connection; rather, the client should wait to observe the
+server's new values in the handshake.
+
+The client MAY store the server's original max_ack_delay and max_packet_size
+transport parameters. The server MAY accept 0-RTT and subsequently provide
+different values for these transport parameters for use in the new connection.
+The client MUST use these values after acknowledging them. If the server does

```suggestion
The client MUST use these values after the handshake completes. If the server does
```
...modulo any rewrapping needed from line-length changes.

> +establishing a new connection; rather, the client should wait to observe the
+server's new values in the handshake.
+
+The client MAY store the server's original max_ack_delay and max_packet_size
+transport parameters. The server MAY accept 0-RTT and subsequently provide
+different values for these transport parameters for use in the new connection.
+The client MUST use these values after acknowledging them. If the server does
+not provide a new value, the client MUST use the default value.
+
+A client that attempts to send 0-RTT data MUST remember all other transport
+parameters used by the server, including new transport parameters
+({{new-transport-parameters}}) that it is able to process. The server can
+remember these transport parameters, 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 transport parameters in determining whether to accept
+0-RTT data.

I think this comment about the server remembering needs to be paired with the prohibition on the server reducing values.  Since you've split out the "in particular" ones already, it might be reasonable to say that the server must not reduce limits / alter values in the transport parameters the client is required to remember.

This is especially true if we go with Ian's suggestion to require future transport parameter definitions to specify which remembering category they fall in.

>  A server MUST either reject 0-RTT data or abort a handshake if the implied
 values for transport parameters cannot be supported.
 
-
-### New Transport Parameters
+### New Transport Parameters {#new-transport-parameters}

Technically unnecessary, since that's the auto-generated anchor anyway.  But it doesn't hurt anything.

-- 
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/2467#pullrequestreview-204018138