Original text:
Consolidate "ticket_early_data_info" and "early_data" into a single extension (*).  Remove spurious requirement to implement "pre_shared_key". Clarify location of "early_data" from server (it goes in EE, as as their corresponding messages sent in other flights (handshake, application_data, and alert respectively) but are protected under different keys.  After receiving the server's Finished message, if <del> the server has accepted early data, an "end_of_early_data" alert of type "warning" MUST be sent to indicate the key change.  This message will be encrypted with the 0-RTT traffic keys. </del>  A server which receives an "early_data" extension can behave in one of three ways: 4.2.8.2. Clients are permitted to "stream" 0-RTT data until they receive the <del> server's Finished, only then sending the "end_of_early_data" alert. In order to avoid deadlock, when accepting "early_data", servers MUST </del>  process the client's ClientHello and then immediately send the <del> ServerHello, rather than waiting for the client's "end_of_early_data" alert. </del>  4.2.8.3. 4.5.  TLS also allows other messages to be sent after the main handshake. These messages use a handshake content type and are encrypted under the application traffic key. <del> 4.5.1. </del>  At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message.  This message max_early_data_size bytes of 0-RTT data SHOULD terminate the connection with an "unexpected_message" alert. <del> 4.5.2. </del>  The server is permitted to request client authentication at any time after the handshake has completed by sending a CertificateRequest certificate_request_context value allows the server to disambiguate the responses). <del> 4.5.3. </del>  %%% Updating Keys any more messages on this connection.  Any data received after a closure MUST be ignored. <del> This alert is sent by the client to indicate that all 0-RTT application_data messages have been transmitted (or none will be sent at all) and that the following records are protected under handshake traffic keys.  This alert MUST be at the warning level. Servers MUST NOT send this alert and clients receiving it MUST terminate the connection with an "unexpected_message" alert. </del> This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a user cancels an operation after the handshake is complete, just TLS Alert Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this registry to <del> include values for "end_of_early_data", "missing_extension", and "certificate_required". </del>  TLS HandshakeType Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this registry to rename item 4 from "NewSessionTicket" to "new_session_ticket" and to add the "hello_retry_request", <del> "encrypted_extensions", and "key_update" values. </del>  This document also uses a registry originally created in RFC4366. IANA has updated it to reference this document.  The registry and its

Reviewer comments:
key changes happen at Handshake boundaries. Suggested by David Benjamin
I have one here, that could be a start: URL Also this is assuming PR URL is accepted ( becomes a message)
Merged.

Revised text:
Consolidate "ticket_early_data_info" and "early_data" into a single extension (*). <ins> Change end_of_early_data to be a handshake message (*). </ins> Remove spurious requirement to implement "pre_shared_key". Clarify location of "early_data" from server (it goes in EE, as as their corresponding messages sent in other flights (handshake, application_data, and alert respectively) but are protected under different keys.  After receiving the server's Finished message, if  <ins> the server has accepted early data, an EndOfEarlyData message will be sent to indicate the key change.  This message will be encrypted with the 0-RTT traffic keys. </ins> A server which receives an "early_data" extension can behave in one of three ways: 4.2.8.2. Clients are permitted to "stream" 0-RTT data until they receive the  <ins> server's Finished, only then sending the EndOfEarlyData message.  In order to avoid deadlock, when accepting "early_data", servers MUST </ins> process the client's ClientHello and then immediately send the  <ins> ServerHello, rather than waiting for the client's EndOfEarlyData message. </ins> 4.2.8.3. 4.5. <ins> %%% Updating Keys The EndOfEarlyData message is sent by the client to indicate that all 0-RTT application_data messages have been transmitted (or none will be sent at all) and that the following records are protected under handshake traffic keys.  Servers MUST NOT send this message and clients receiving it MUST terminate the connection with an "unexpected_message" alert. 4.6. </ins> TLS also allows other messages to be sent after the main handshake. These messages use a handshake content type and are encrypted under the application traffic key.  <ins> 4.6.1. </ins> At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message.  This message max_early_data_size bytes of 0-RTT data SHOULD terminate the connection with an "unexpected_message" alert.  <ins> 4.6.2. </ins> The server is permitted to request client authentication at any time after the handshake has completed by sending a CertificateRequest certificate_request_context value allows the server to disambiguate the responses).  <ins> 4.6.3. </ins> %%% Updating Keys any more messages on this connection.  Any data received after a closure MUST be ignored.  This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a user cancels an operation after the handshake is complete, just TLS Alert Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this registry to  <ins> include values for "missing_extension" and "certificate_required". </ins> TLS HandshakeType Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this registry to rename item 4 from "NewSessionTicket" to "new_session_ticket" and to add the "hello_retry_request",  <ins> "encrypted_extensions", "end_of_early_data", and "key_update" values. </ins> This document also uses a registry originally created in RFC4366. IANA has updated it to reference this document.  The registry and its