target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.2.3"

# 6.2.3.  Speeding up Handshake Completion
#
# When a server receives an Initial packet containing duplicate CRYPTO
# data, it can assume the client did not receive all of the server's
# CRYPTO data sent in Initial packets, or the client's estimated RTT is
# too small.  When a client receives Handshake or 1-RTT packets prior
# to obtaining Handshake keys, it may assume some or all of the
# server's Initial packets were lost.
# 
# To speed up handshake completion under these conditions, an endpoint
# MAY, for a limited number of times per connection, send a packet
# containing unacknowledged CRYPTO data earlier than the PTO expiry,
# subject to the address validation limits in Section 8.1 of
# [QUIC-TRANSPORT].  Doing so at most once for each connection is
# adequate to quickly recover from a single packet loss.  An endpoint
# that always retransmits packets in response to receiving packets that
# it cannot process risks creating an infinite exchange of packets.
# 
# Endpoints can also use coalesced packets (see Section 12.2 of
# [QUIC-TRANSPORT]) to ensure that each datagram elicits at least one
# acknowledgment.  For example, a client can coalesce an Initial packet
# containing PING and PADDING frames with a 0-RTT data packet, and a
# server can coalesce an Initial packet containing a PING frame with
# one or more packets in its first flight.

[[spec]]
level = "MAY"
quote = '''
To speed up handshake completion under these conditions, an endpoint
MAY, for a limited number of times per connection, send a packet
containing unacknowledged CRYPTO data earlier than the PTO expiry,
subject to the address validation limits in Section 8.1 of
[QUIC-TRANSPORT].
'''