Change:
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.

Discussion:
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.