Correct some pretty lame snafus

draft-ietf-quic-http.md

@@ -848,9 +848,9 @@ QUIC connections are persistent.  All of the considerations in Section 9.1 of
 
 HTTP clients are expected to use QUIC PING frames to keep connections open.
 Servers SHOULD NOT use PING frames to keep a connection open.  A client SHOULD
-NOT use PING frames for this purpose unless there are no responses outstanding
-for requests or server pushes.  If the client is not expecting a response from
-the server, allowing an idle connection to time out (based on the idle_timeout
+NOT use PING frames for this purpose unless there are responses outstanding for
+requests or server pushes.  If the client is not expecting a response from the
+server, allowing an idle connection to time out (based on the idle_timeout
 transport parameter) is preferred over expending effort maintaining a connection
 that might not be needed.  A gateway MAY use PING to maintain connections in
 anticipation of need rather than incur the latency cost of connection

draft-ietf-quic-transport.md

@@ -1791,19 +1791,19 @@ packet containing this frame.
 A PING frame has no additional fields.
 
 The PING frame can be used to keep a connection alive when an application or
-application protocol wishes to avoid the connection from timing out.  An
+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 cause excessive number of
 packets and poor performance.
 
-A connection will time out if no packets are for a period longer than the time
-specified in the 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.
+A connection will time out if no packets are sent or received for a period
+longer than the time specified in the 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.
 
 
 ## BLOCKED Frame {#frame-blocked}