Change:
visible in the UDP datagrams containing the QUIC handshake, then examine each of the datagrams in detail. <del> The QUIC handshake can normally be recognized on the wire through at least four datagrams labelled "Client Initial", "Server Initial", and "Client Completion", and "Server Completion", in the illustration shown in fig-handshake. </del> <ins> The QUIC handshake can normally be recognized on the wire through four flights of datagrams labelled "Client Initial", "Server Initial", "Client Completion", and "Server Completion", in the illustration shown in fig-handshake. </ins> Packets in the handshake belong to three separate cryptographic and transport contexts ("Initial", which contains observable payload, and "Handshake" and "1-RTT", which do not).  QUIC packets in separate <del> contexts during the handshake are generally coalesced (see coalesced) in order to reduce the number of UDP datagrams sent during the handshake. </del> <ins> contexts during the handshake can be coalesced (see coalesced) in order to reduce the number of UDP datagrams sent during the handshake.  QUIC packets can be lost and reordered, so packets within a flight might not be sent close in time, though the sequence of the flights will not change, because one flight depends upon the peer's previous flight. </ins> As shown here, the client can send 0-RTT data as soon as it has sent its Client Hello, and the server can send 1-RTT data as soon as it has sent its Server Hello. <del> A typical handshake starts with the client sending of a Client Initial datagram as shown in fig-client-initial, which elicits a Server Initial datagram as shown in fig-server-initial typically containing three packets: an Initial packet with the beginning of the server's side of the TLS handshake, a Handshake packet with the rest of the server's side of the TLS handshake, and 1-RTT data, if present. </del> <ins> A handshake starts with the client sending one or more datagrams containing Initial packets as shown in fig-client-initial, which elicits the Server Initial response as shown in fig-server-initial typically containing three types of packets: Initial packet(s) with the beginning of the server's side of the TLS handshake, Handshake packet(s) with the rest of the server's portion of the TLS handshake, and 1-RTT packet(s), if present. </ins> <del> The Client Completion datagram contains at least one Handshake packet </del> <ins> The Client Completion flight contains at least one Handshake packet </ins> and could also include an Initial packet. Datagrams that contain an Initial packet (Client Initial, Server

Discussion:
As noted in the "The QUIC Handshake" is written in a way that could cause readers to assume things such as there's only one datagram containing a Client Initial. This PR changes the naming from 'Client/Server Initial/Finished datagram' to 'Client/Server Initial/Finished flight' and makes related changes to make it read correctly. The diagrams have not been fully updated yet.
QUIC handshakes may or may not coalesce packets, which is stated, but I'm worried it could be missed by a reader. I think it'd be good to clarify that any portion of the server or client flight could span multiple datagrams. In particular, I'm worried this paragraph could mislead people, because unless the connection is resumed, the Handshake CRYPTO data typically spans multiple datagrams. Similarly, the client or server's Initial can span multiple datagrams, though that's not currently common:
I think some clarity about multiple packets/datagrams would be helpful in the Extracting SNI section as well: URL Specifically: 1) Client initial data can span multiple datagrams, and the SNI could be in any of them. 2) A single client Initial packet can contain multiple CRYPTO frames, and there's no strict requirement they're in order of offset.
NAME can you maybe propose a PR? :-)
Yes, possibly later today after I finish reviewing the draft.
NAME are you still planning to do a PR here?
I will unless someone beats me to it, but I've been on paternity leave for 10 days. NAME had some suggested text for the SNI section, but I can try to fix "The QUIC Handshake" and assume David's text is a good start for SNI.
While writing the PR, I discovered a problem I'm not sure how to fix, which is how does an observer know when the handshake is complete for the server, given the server can start using 1-RTT keys immediately after receiving the client hello? Receipt of the client's 1-RTT packet doesn't guarantee anything, because the server can't process it if it doesn't have keys.
lgtm, one potential diagram nit.