Move alternative confirmation method

quicwg · Dec 11, 2019 · d3aabcc · d3aabcc
1 parent e163adc
commit d3aabcc
Show file tree

Hide file tree

Showing 2 changed files with 7 additions and 7 deletions.
diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md
@@ -386,9 +386,15 @@ perspective of the endpoint in question.
 ### Handshake Confirmed {#handshake-confirmed}
 
 In this document, the TLS handshake is considered confirmed at the server when
-the handshake completes. At the client, the handshake is considered confirmed
+the handshake completes.  At the client, the handshake is considered confirmed
 when a HANDSHAKE_DONE frame is received.
 
+A client MAY consider the handshake to be confirmed when it receives an
+acknowledgement for a 1-RTT packet.  This can be implemented by recording the
+lowest packet number sent with 1-RTT keys, and the highest value of the Largest
+Acknowledged field in any received 1-RTT ACK frame: once the latter is higher
+than or equal to the former, the handshake can be confirmed.
+
 
 ### Sending and Receiving Handshake Messages
 

diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md
@@ -5508,12 +5508,6 @@ HANDSHAKE_DONE frame before completing the handshake.  A server MUST treat
 receipt of a HANDSHAKE_DONE frame as a connection error of type
 PROTOCOL_VIOLATION.
 
-A client MAY consider the handshake to be confirmed when it receives an
-acknowledgement for a 1-RTT packet.  This can be implemented by recording
-the lowest packet number sent with 1-RTT keys, and the highest value of the
-Largest Acknowledged field in any received 1-RTT ACK frame: once the latter is
-higher than or equal to the former, the handshake can be confirmed.
-
 
 ## Extension Frames