Change:
This moves it up under the idle timeout section. As discussed on the issue, the HTTP draft is basically good.
The transport Draft states: This guidance was added to the HTTP Draft in , but was subsequently removed.
I guess that something to discuss in the applicability draft as well
Looks like made this text more generic, leaving the specifics of how to keep a connection alive (e.g. with PING frames) to the transport implementation. The text in question is now in Section 5.1: It's possible the transport draft needs a similar generalization, to recommend implementations expose a way for the application layer to control whether an connection is idle.
Actually there is a section on "Session resumption versus Keep-alive" in the applicability draft already. Do we need to say more? Is that needed in the transport draft as well?
On the whole, this is good. Might be worth having something a little stronger than "might provide"; that would be normative, but the old text already hinted fairly strongly that this was a capability that needed to be exposed to applications.

Discussion:
a packet.  Restarting this timer when sending a packet ensures that connections are not closed after new activity is initiated. <ins> 10.2.1. An endpoint that sends packets close to the effective timeout risks having them be discarded at the peer, since the peer might enter its draining state before these packets arrive. An endpoint can send a PING or another ack-eliciting frame to test the connection for liveness if the peer could time out soon, such as within a PTO; see Section 6.2 of QUIC-RECOVERY.  This is especially useful if any available application data cannot be safely retried. Note that the application determines what data is safe to retry. 10.2.2. </ins> 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. <del> An endpoint that sends packets close to the effective timeout risks having them be discarded at the peer, since the peer might enter its draining state before these packets arrive.  An endpoint can send a PING or another ack-eliciting frame to test the connection for liveness if the peer could time out soon, such as within a PTO; see Section 6.2 of QUIC-RECOVERY.  This is especially useful if any available application data cannot be safely retried.  Note that the application determines what data is safe to retry. </del> <ins> 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 periodically to defer an idle timeout; see frame-ping. 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 termination.  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 15 to 30 seconds is necessary to prevent the majority of middleboxes from losing state for UDP flows. </ins> 10.3.

The PING frame can be used to keep a connection alive when an application or application protocol wishes to prevent the connection <del> from timing out.  An application protocol SHOULD provide guidance about the conditions under which generating a PING is recommended. This guidance SHOULD indicate whether it is the client or the server that is expected to send the PING.  Having both endpoints send PING frames without coordination can produce an excessive number of packets and poor 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 termination.  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 15 to 30 seconds is necessary to prevent the majority of middleboxes from losing state for UDP flows. </del> <ins> from timing out; see defer-idle. </ins> 19.3.

HTTP clients are expected to request that the transport keep connections open while there are responses outstanding for requests <del> or server pushes, as described in Section 19.2 of QUIC-TRANSPORT.  If the client is not expecting a response from the server, allowing an idle connection to time out is preferred over expending effort </del> <ins> or server pushes, as described in Section 10.2.2 of QUIC-TRANSPORT. If the client is not expecting a response from the server, allowing an idle connection to time out is preferred over expending effort </ins> maintaining a connection that might not be needed.  A gateway MAY maintain connections in anticipation of need rather than incur the latency cost of connection establishment to servers.  Servers SHOULD