target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.1.2"

# 10.1.2.  Deferring Idle Timeout
#
# An endpoint might need to send ack-eliciting packets to avoid an idle
# timeout if it is expecting response data but does not have or is
# unable to send application data.
# 
# An implementation of QUIC might provide applications with an option
# to defer an idle timeout.  This facility could be used when the
# application wishes to avoid losing state that has been associated
# with an open connection but does not expect to exchange application
# data for some time.  With this option, an endpoint could send a PING
# frame (Section 19.2) periodically, which will cause the peer to
# restart its idle timeout period.  Sending a packet containing a PING
# frame restarts the idle timeout for this endpoint also if this is the
# first ack-eliciting packet sent since receiving a packet.  Sending a
# PING frame causes the peer to respond with an acknowledgment, which
# also restarts the idle timeout for the endpoint.
# 
# Application protocols that use QUIC SHOULD provide guidance on when
# deferring an idle timeout is appropriate.  Unnecessary sending of
# PING frames could have a detrimental effect on performance.
# 
# A connection will time out if no packets are sent or received for a
# period longer than the time negotiated using the max_idle_timeout
# transport parameter; see Section 10.  However, state in middleboxes
# might time out earlier than that.  Though REQ-5 in [RFC4787]
# recommends a 2-minute timeout interval, experience shows that sending
# packets every 30 seconds is necessary to prevent the majority of
# middleboxes from losing state for UDP flows [GATEWAY].

[[spec]]
level = "SHOULD"
quote = '''
Application protocols that use QUIC SHOULD provide guidance on when
deferring an idle timeout is appropriate.
'''