Original text:
with any other value as a connection error of type PROTOCOL_VIOLATION.  Early data within the TLS connection MUST NOT be used.  As it is for other TLS application data, a server MUST treat receiving early data on the TLS connection as a connection error of type 4.6. <del> A server rejects 0-RTT by rejecting 0-RTT at the TLS layer.  This also prevents QUIC from sending 0-RTT data.  A server will always reject 0-RTT if it sends a TLS HelloRetryRequest. </del>  When 0-RTT is rejected, all connection characteristics that the client assumed might be incorrect.  This includes the choice of and the EncryptedExtensions messages during the handshake.  Endpoints MUST send the quic_transport_parameters extension; endpoints that receive ClientHello or EncryptedExtensions messages without the <del> quic_transport_parameters extension MUST terminate the TLS handshake with a fatal missing_extension alert (an error of 0x16d). </del>  While the transport parameters are technically available prior to the completion of the handshake, they cannot be fully trusted until the Disabling 0-RTT entirely is the most effective defense against replay attack. <del> QUIC extensions MUST describe how replay attacks affects their </del>  operation, or prohibit their use in 0-RTT.  Application protocols MUST either prohibit the use of extensions that carry application semantics in 0-RTT or provide replay mitigation strategies. this could allow a malicious peer to exhaust processing capacity without consequence. <del> QUIC prohibits the sending of empty "STREAM" frames unless they are marked with the FIN bit.  This prevents "STREAM" frames from being sent that only waste effort. </del> While there are legitimate uses for some redundant packets, implementations SHOULD track redundant packets and treat excessive volumes of any non-productive packets as indicative of an attack.

Reviewer comments:
Of the TLS doc says: A server rejects 0-RTT by rejecting 0-RTT at the TLS layer. This also prevents QUIC from sending 0-RTT data. However, this doesn't explicitly say that it prevents QUIC from receiving 0-RTT data. I suspect this is implied, but it might be worth clarifying. I could imagine a server rejecting 0-RTT data, but attempting to ACK the client's 0-RTT packets in order to deliver a congestion signal to the client. I think this would be a rather terrible idea, so it would be nice to explicitly prohibit it.
Throughout transport, there is the idea that you MUST not acknowledge packets you can't fully process, so this should be against the spec. But it may be worth noting explicitly, probably in transport.
Doing it in transport would make sense. Or perhaps in TLS by noting that if 0-RTT is rejected, 0-RTT keys must not be generated.
NAME I just added text about that to my PR that's targeting .
SG NAME If so, can you update the CL description to indicate what issues it closes?
I'm going so recommend that this be triaged as a design issue, even if it might seem trivial. The prohibition in is the right response.
The spec says RFC 8446 says about rejecting 0-RTT: This doesn't really apply to QUIC, since we don't need a connection that requires us to read the bytes in order. The QUIC equivalent would be to drop all packets of packet type 0-RTT.
It is my understanding the existence of early_data extension in the EncryptedExtensions message indicates if the server has accepted 0-RTT (or not). Merely dropping the packets is not sufficient. This is because the parameters of a connection depends on if 0-RTT has been received; for example, in case of HTTP/3, until the client receives a SETTINGS frame, the settings of previous connection is applied when 0-RTT is accepted, whereas the default settings defined by the specification is applied when 0-RTT is rejected.
PS. What I think we need to clarify is that "use and acceptance" of 0-RTT is communicated the same way as TLS 1.3, by using the earlydata extension. That includes earlydata extension sent in ClientHello, EncryptedExtensions, NewSessionTicket.
Thanks NAME That confirms my interpretation of how accepting and rejecting is supposed to work. I’ll prepare a PR later.

Revised text:
with any other value as a connection error of type PROTOCOL_VIOLATION. <ins> A client that wishes to send 0-RTT packets uses the "early_data" extension in the ClientHello message of a subsequent handshake (see Section 4.2.10 of TLS13).  It then sends the application data in 0-RTT packets. </ins> Early data within the TLS connection MUST NOT be used.  As it is for other TLS application data, a server MUST treat receiving early data on the TLS connection as a connection error of type 4.6.  <ins> A server accepts 0-RTT by sending an early_data extension in the EncryptedExtensions (see Section 4.2.10 of TLS13).  The server then processes and acknowledges the 0-RTT packets that it receives. A server rejects 0-RTT by sending the EncryptedExtensions without an early_data extension.  A server will always reject 0-RTT if it sends a TLS HelloRetryRequest.  When rejecting 0-RTT, a server MUST NOT process any 0-RTT packets, even if it could.  When 0-RTT was rejected, a client SHOULD treat receipt of an acknowledgement for a 0-RTT packet as a connection error of type PROTOCOL_VIOLATION, if it is able to detect the condition. </ins> When 0-RTT is rejected, all connection characteristics that the client assumed might be incorrect.  This includes the choice of and the EncryptedExtensions messages during the handshake.  Endpoints MUST send the quic_transport_parameters extension; endpoints that receive ClientHello or EncryptedExtensions messages without the  <ins> quic_transport_parameters extension MUST close the connection with an error of type 0x16d (equivalent to a fatal TLS missing_extension alert, see tls-errors). </ins> While the transport parameters are technically available prior to the completion of the handshake, they cannot be fully trusted until the Disabling 0-RTT entirely is the most effective defense against replay attack.  <ins> QUIC extensions MUST describe how replay attacks affect their </ins> operation, or prohibit their use in 0-RTT.  Application protocols MUST either prohibit the use of extensions that carry application semantics in 0-RTT or provide replay mitigation strategies. this could allow a malicious peer to exhaust processing capacity without consequence.  While there are legitimate uses for some redundant packets, implementations SHOULD track redundant packets and treat excessive volumes of any non-productive packets as indicative of an attack.