Original text:
application_data, and alert respectively) but are protected under different keys.  After all the 0-RTT application data messages (if any) have been sent, a "end_of_early_data" alert of type "warning" is <del> sent to indicate the end of the flight. </del>  A server which receives an "early_data" extension can behave in one of two ways: The type of 0-RTT handshake that this configuration is to be used for (see early-data-indication).  If "client_authentication" or <del> "client_authentication_and_data", then the client should select the certificate for future handshakes based on the CertificateRequest parameters supplied in this handshake.  The server MUST NOT send either of these two options unless it also requested a certificate on this handshake.  [[OPEN ISSUE: Should we relax this?]] </del>  This field is a placeholder for future extensions to the The client MUST send a Certificate message whenever the server has requested client authentication via a CertificateRequest message <del> (certificate-request) or when the EarlyDataIndication indicates client authentication.  This message is only sent if the server requests a certificate.  If no suitable certificate is available, </del>  the client MUST send a Certificate message containing no certificates (i.e., with the "certificate_list" field having length 0).

Reviewer comments:
This cleans up some of the text around EarlyDataIndication that was introduced previously.
The early data indication parameters are defined as clientauthentication(1), earlydata(2), and clientauthenticationanddata(3). A few paragraph after that, some text refers to them by what was probably an old name: If TLS client authentication is being used, then either "earlyhandshake" or "earlyhandshakeand_data" MUST be indicated in order to send the client authentication data on the first flight. Easy fix...
See URL
This should now be fixed.

Revised text:
application_data, and alert respectively) but are protected under different keys.  After all the 0-RTT application data messages (if any) have been sent, a "end_of_early_data" alert of type "warning" is  <ins> sent to indicate the end of the flight.  Clients which do 0-RTT MUST always send "end_of_early_data" even if the ServerConfiguration indicates that no application data is allowed (EarlyDataType of "client_authentication"), though in that case it MUST NOT send any non-empty data records (i.e., those which consist of anything other than padding). </ins> A server which receives an "early_data" extension can behave in one of two ways: The type of 0-RTT handshake that this configuration is to be used for (see early-data-indication).  If "client_authentication" or  <ins> "client_authentication_and_data", then the client MUST select the certificate for future handshakes based on the CertificateRequest parameters supplied in this handshake.  The server MUST NOT send either of these two options unless it also requested a certificate on this handshake.  [[OPEN ISSUE: Should we relax this?]] </ins> This field is a placeholder for future extensions to the The client MUST send a Certificate message whenever the server has requested client authentication via a CertificateRequest message  <ins> (certificate-request) or when the EarlyDataType provided with the server configuration indicates a need for client authentication. This message is only sent if the server requests a certificate via one of these mechanisms.  If no suitable certificate is available, </ins> the client MUST send a Certificate message containing no certificates (i.e., with the "certificate_list" field having length 0).