Draft: draft-ietf-quic-http

Commentary: 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 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 .
Paragraph (version A):
HTTP clients are expected to request that the transport keep
connections open while there are responses outstanding for requests
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
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
NOT actively keep connections open.
Paragraph (version B):
HTTP clients are expected to request that the transport keep
connections open while there are responses outstanding for requests
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
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
NOT actively keep connections open.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
The PING frame can be used to keep a connection alive when an
application or application protocol wishes to prevent the connection
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.
Paragraph (version B):
The PING frame can be used to keep a connection alive when an
application or application protocol wishes to prevent the connection
from timing out; see defer-idle.