Change:
but there are some value judgments here. I believe the new layout is much clearer for implementers. I made maxpacketsize optional for reasons that I think are self-evident. I thought saving maxackdelay might be useful for clients setting loss timers on their 0-RTT stuff. Everything else is required or forbidden. Per NAME suggestion, I put all the new TPs in the required category. I also specified behavior when the EE msg omits a TP. I thought it would be simpler for servers that spit out a standard set of TPs to do things that way.
NAME : Are you planning to incorporate feedback into the PR?
Yes, sorry for the delay.
Thanks for doing this Martin. I will raise this on the list so that people are clear about this. Technically, there isn't a change here, but it certainly looks like it if you don't understand what is going on.
Sec 7.3.1 of quic-transport says: A client that attempts to send 0-RTT data MUST remember the transport parameters used by the server. The transport parameters that the server advertises during connection establishment apply to all connections that are resumed using the keying material established during that handshake. Remembered transport parameters apply to the new connection until the handshake completes and new transport parameters from the server can be provided. Later on, the section makes it clear that this is really about the flow control parameters, which makes a lot of sense, but here I am storing all this data to be compliant. I propose that we change the MUST above to refer to only the 6 FC parameters. This reduces the stuff that clients have to store. going through each: originalconnectionid: clearly useless idletimeout: useless in handshake statelessresettoken: clearly useless maxpacketsize: could be useful, but meh ackdelayexponent: not useful before we get the server Handshake maxackdelay: same disablemigration: same preferred_address: same
It's not just the flow control parameters -- it's also support for extensions in TPs yet-to-be-defined. So while I would be amenable to reorienting this issue to create an exception for the ones you've marked as useless, I think this is the correct default rule.
good point. I'm happy to write a PR as you describe if others agree.
I agree that a good number of those are useless. Possibly we should explicitly state which params need to be stored and extensions should be required to state whether they need to be stored when they're defined?
How is anyone going to know if you don't remember these values? Just remember the ones you know you need to remember.
A conformance test that deliberately lowers them after accepting 0-RTT and checks whether the client chokes.
You can't lower preferred addresses, disable migration, etc.. Basically, we should allow all those that NAME points out make no sense to remember to change. That's the real fix here.
This makes sense, and the list is good.
Editors: please don't close the issue before consensus is declared.
For context, the PR was marked editorial but the issue it auto-closed was marked design. Comment from the PR discussion: The PR changes the text from "MUST remember everything" to "MUST NOT remember the things that don't make sense to remember and you weren't actually remembering anyway, but MUST remember everything else". That is, there's no functional change to real implementations, but the normative requirements in the text didn't match what was actually possible to implement. Martin's right -- this is really an editorial change, despite touching normative text.
A few suggestions, but I like this. Maybe I will do the tabulation thing later.One editorial suggestion.Looks reasonable to me. I'm not opposed to NAME suggestion that lets future transport parameters decide whether they need to be remembered or not, either.

Discussion:
7.3.1. <del> A client that attempts to send 0-RTT data MUST remember the transport parameters used by the server.  The transport parameters that the server advertises during connection establishment apply to all connections that are resumed using the keying material established during that handshake.  Remembered transport parameters apply to the new connection until the handshake completes and new transport parameters from the server can be provided. A server can remember the transport parameters 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 transport parameters in determining whether to accept 0-RTT data. 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. </del> <ins> Both endpoints store the value of the server transport parameters from a connection and apply them to any 0-RTT packets that are sent in subsequent connections to that peer, except for transport parameters that are explicitly excluded.  Remembered transport parameters apply to the new connection until the handshake completes and the client starts sending 1-RTT packets.  Once the handshake completes, the client uses the transport parameters established in the handshake. The definition of new transport parameters (new-transport-parameters) MUST specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. A client need not store a transport parameter it cannot process. A client MUST NOT use remembered values for the following parameters: original_connection_id, preferred_address, stateless_reset_token, and ack_delay_exponent.  The client MUST use the server's new values in the handshake instead, and absent new values from the server, the default value. A client that attempts to send 0-RTT data MUST remember all other transport parameters used by the server.  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. 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 the parameters. </ins> initial_max_data

initial_max_stream_data_bidi_remote, or initial_max_streams_uni and initial_max_stream_data_uni. <del> The value of the server's previous preferred_address MUST NOT be used when establishing a new connection; rather, the client should wait to observe the server's new preferred_address value in the handshake. </del> A server MUST either reject 0-RTT data or abort a handshake if the implied values for transport parameters cannot be supported.