Re: [quicwg/base-drafts] Clarify server CONNECTION_CLOSE with Handshake (#2688)

[MikkelFJ <[e-mail]>]

mikkelfj commented on this pull request.



> @@ -2304,13 +2304,25 @@ the application requests that the connection be closed.  The application
 protocol can use an CONNECTION_CLOSE frame with an appropriate error code to
 signal closure.
 
-If the connection has been successfully established, endpoints MUST send any
-CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to connection establishment a
-peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames
-in a Handshake packet.  If the endpoint does not have Handshake keys, or it is
-not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE
-frames in an Initial packet.  If multiple packets are sent, they can be
-coalesced (see {{packet-coalesce}}) to facilitate retransmission.
+When sending CONNECTION_CLOSE, the goal is to ensure that a peer will process
+the frame.  Generally, this means sending the frame in a packet with the highest
+level of packet protection to avoid the packet being discarded.  However, during
+the handshake, it is possible that more advanced packet protection keys are not
+available to a peer, so the frame MAY be replicated in a packet that uses a
+lower packet protection level.

This paragraph doesn't really say anything that the next paragraph doesn't cover. Also, `a peer` sounds like an endpoint can have multiple peers.

> @@ -2304,13 +2304,25 @@ the application requests that the connection be closed.  The application
 protocol can use an CONNECTION_CLOSE frame with an appropriate error code to
 signal closure.
 
-If the connection has been successfully established, endpoints MUST send any
-CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to connection establishment a
-peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames
-in a Handshake packet.  If the endpoint does not have Handshake keys, or it is
-not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE
-frames in an Initial packet.  If multiple packets are sent, they can be
-coalesced (see {{packet-coalesce}}) to facilitate retransmission.
+When sending CONNECTION_CLOSE, the goal is to ensure that a peer will process
+the frame.  Generally, this means sending the frame in a packet with the highest
+level of packet protection to avoid the packet being discarded.  However, during
+the handshake, it is possible that more advanced packet protection keys are not
+available to a peer, so the frame MAY be replicated in a packet that uses a
+lower packet protection level.
+
+If the handshake is confirmed, endpoints MUST send any CONNECTION_CLOSE frames

```suggestion
When the handshake is confirmed, an endpoint MUST send any CONNECTION_CLOSE frames
```

> -CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to connection establishment a
-peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames
-in a Handshake packet.  If the endpoint does not have Handshake keys, or it is
-not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE
-frames in an Initial packet.  If multiple packets are sent, they can be
-coalesced (see {{packet-coalesce}}) to facilitate retransmission.
+When sending CONNECTION_CLOSE, the goal is to ensure that a peer will process
+the frame.  Generally, this means sending the frame in a packet with the highest
+level of packet protection to avoid the packet being discarded.  However, during
+the handshake, it is possible that more advanced packet protection keys are not
+available to a peer, so the frame MAY be replicated in a packet that uses a
+lower packet protection level.
+
+If the handshake is confirmed, endpoints MUST send any CONNECTION_CLOSE frames
+in a 1-RTT packet.  Prior to handshake confirmation, a peer might not have
+1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames in a Handshake

```suggestion
1-RTT keys, so the endpoint SHOULD send CONNECTION_CLOSE frames in a Handshake
```

> -If the connection has been successfully established, endpoints MUST send any
-CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to connection establishment a
-peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames
-in a Handshake packet.  If the endpoint does not have Handshake keys, or it is
-not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE
-frames in an Initial packet.  If multiple packets are sent, they can be
-coalesced (see {{packet-coalesce}}) to facilitate retransmission.
+When sending CONNECTION_CLOSE, the goal is to ensure that a peer will process
+the frame.  Generally, this means sending the frame in a packet with the highest
+level of packet protection to avoid the packet being discarded.  However, during
+the handshake, it is possible that more advanced packet protection keys are not
+available to a peer, so the frame MAY be replicated in a packet that uses a
+lower packet protection level.
+
+If the handshake is confirmed, endpoints MUST send any CONNECTION_CLOSE frames
+in a 1-RTT packet.  Prior to handshake confirmation, a peer might not have

```suggestion
in a 1-RTT packet.  Prior to handshake confirmation, the peer might not have
```

-- 
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/2688#pullrequestreview-237616302