Re: [quicwg/base-drafts] Make keep-alive advice more generic (#3745)

[Mike Bishop <[e-mail]>]

@MikeBishop approved this pull request.

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.

>  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 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.
+An implementation of QUIC might provide applications with an option to defer an
+idle timeout.  This facility could be used when the application has wishes to

```suggestion
idle timeout.  This facility could be used when the application wishes to
```

>  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 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.
+An implementation of QUIC might provide applications with an option to defer an
+idle timeout.  This facility could be used when the application has wishes to
+avoid the loss of state that is bound to an open connection, but does not expect

I don't have a good suggestion here, but this trips up a first reading by being ambiguous about whether it's the state or the loss which is associated with the connection.  Maybe "application wishes to avoid losing the state associated with an open connection"?  Or "application wishes to avoid the connection timing out, but..."?

-- 
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/3745#pullrequestreview-427146973