Re: [quicwg/base-drafts] Idle timeout editorial fixes (#3444)

[Martin Thomson <[e-mail]>]

martinthomson requested changes on this pull request.

I think that the shift in the explanation misses the important point for a lesser one.

> @@ -2420,20 +2420,21 @@ close ({{immediate-close}}) if it abandons the connection prior to the effective
 value.
 
 An endpoint restarts its idle timer when a packet from its peer is received
-and processed successfully.  The idle timer is also restarted when sending
-an ack-eliciting packet (see {{QUIC-RECOVERY}}), but only if no other
-ack-eliciting packets have been sent since last receiving a packet.  Restarting
-when sending packets ensures that connections do not prematurely time out when
-initiating new activity.  An endpoint might need to send packets to avoid an
-idle timeout if it is unable to send application data due to being blocked on
-flow control limits; see {{flow-control}}.
+and processed successfully.  The idle timer is also restarted when sending the
+first ack-eliciting packet (see {{QUIC-RECOVERY}}) after receiving a packet.
+Only restarting when sending after receipt of a packet ensures the idle timeout
+is not excessively lengthened past the time the peer's timeout has expired.

This sentence doesn't really capture what the original text was attempting to explain.  That is, the original text intended to explain that a reset on receipt is insufficient because local attempts to restart communication might still result in the idle timeout period lapsing.  This says something different.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3444#pullrequestreview-355640812