Change:
This PR restructures 17.3 to be aligned with 17.2. Note that while the diff seems to show whole paragraphs changed in the section, all I've done is replaced with . Note that I've not replaced all uses of . I've retained it where it is used alongside , for symmetry. This still touches more text than I had hoped, but it makes the structure of Section 17 clearer.
NAME Thanks for the note. I've updated the tls doc, but I've left most uses of as they are. I've retained them for symmetry, since in all the ones I've retained, it appears alongside .
While the transport draft talks a lot about "1-RTT packets", the term is not defined. We also have a sentence that seem to imply that a long-header variant of 1-RTT packets might exist (URL). We refer to the packet less frequently as "short header packets" or "packet with a short header." As a resolution, I think we might want to change the title of section 17.3 from "Short Header Packets" to "1-RTT Packets". Rest of the text can remain the same, as the first sentence of that section says that it is the only type of short header packet that we define.
Update: I think we might want to make corresponding changes to the TLS draft. Re TLS draft, I think we can replace all the occurrences of "short header packet(s)", "packet(s) with (a) short header" in the TLS draft with "1-RTT packet(s)", as well making necessary changes to table 1.This looks good. The actual changes are much smaller than the diff appears, and I think the symmetry with 17.2 helps readability despite the extra layer.

Discussion:
selected cipher suite; see hp-aes and hp-chacha. fig-sample shows an example long header packet (Initial) and a short <del> header packet. fig-sample shows the fields in each header that are covered by header protection and the portion of the protected packet payload that is sampled. </del> <ins> header packet (1-RTT). fig-sample shows the fields in each header that are covered by header protection and the portion of the protected packet payload that is sampled. </ins> Before a TLS cipher suite can be used with QUIC, a header protection algorithm MUST be specified for the AEAD used with that cipher suite.

any number more (subject to limits inherent to the protocol, such as congestion control and anti-amplification).  For instance, the server's first flight contains Initial packets, Handshake packets, <del> and "0.5-RTT data" in 1-RTT packets with a short header. </del> <ins> and "0.5-RTT data" in 1-RTT packets. </ins> tls-0rtt-handshake shows an example of a connection with a 0-RTT handshake and a single packet of 0-RTT data.  Note that as described

Handshake space: All Handshake packets (packet-handshake) are in this space. <del> Application data space: All 0-RTT (packet-0rtt) and 1-RTT (short- header) encrypted packets are in this space. </del> <ins> Application data space: All 0-RTT (packet-0rtt) and 1-RTT (packet- 1rtt) encrypted packets are in this space. </ins> As described in QUIC-TLS, each packet type uses different protection keys.

0-RTT (packet-0rtt) <del> 1-RTT (short-header) </del> <ins> 1-RTT (packet-1rtt) </ins> Only a CONNECTION_CLOSE frame of type 0x1c can appear in Initial or Handshake packets.

This version of QUIC defines a single packet type that uses the short packet header. <del> The short header can be used after the version and 1-RTT keys are negotiated.  Packets that use the short header contain the following fields: </del> <ins> 17.3.1. A 1-RTT packet uses a short packet header.  It is used after the version and 1-RTT keys are negotiated. 1-RTT packets contain the following fields: </ins> The most significant bit (0x80) of byte 0 is set to 0 for the short header.

number field is encoded in Packet Number Length field.  See packet-encoding for details. <del> Packets with a short header always include a 1-RTT protected payload. </del> <ins> 1-RTT packets always include a 1-RTT protected payload. </ins> The header form bit and the connection ID field of a short header packet are version-independent.  The remaining fields are specific to the selected QUIC version.  See QUIC-INVARIANTS for details on how packets from different versions of QUIC are interpreted. <del> 17.3.1. </del> <ins> 17.4. </ins> <del> The latency spin bit enables passive latency monitoring from observation points on the network path throughout the duration of a connection.  The server reflects the spin value received, while the client 'spins' it after one RTT.  On-path observers can measure the time between two spin bit toggle events to estimate the end-to-end RTT of a connection. </del> <ins> The latency spin bit, which is defined for 1-RTT packets (packet- 1rtt), enables passive latency monitoring from observation points on the network path throughout the duration of a connection.  The server reflects the spin value received, while the client 'spins' it after one RTT.  On-path observers can measure the time between two spin bit toggle events to estimate the end-to-end RTT of a connection. </ins> <del> The spin bit is only present in the short packet header, since it is possible to measure the initial RTT of a connection by observing the </del> <ins> The spin bit is only present in 1-RTT packets, since it is possible to measure the initial RTT of a connection by observing the </ins> handshake.  Therefore, the spin bit is available after version negotiation and connection establishment are completed.  On-path measurement and use of the latency spin bit is further discussed in QUIC-MANAGEABILITY. <del> The spin bit is an OPTIONAL feature of QUIC.  A QUIC stack that chooses to support the spin bit MUST implement it as specified in this section. </del> <ins> The spin bit is an OPTIONAL feature of this version of QUIC.  A QUIC stack that chooses to support the spin bit MUST implement it as specified in this section. </ins> Each endpoint unilaterally decides if the spin bit is enabled or disabled for a connection.  Implementations MUST allow administrators

connection ID. If the spin bit is enabled for the connection, the endpoint maintains <del> a spin value for each network path and sets the spin bit in the short header to the currently stored value when a packet with a short header is sent on that path.  The spin value is initialized to 0 in the endpoint for each network path.  Each endpoint also remembers the </del> <ins> a spin value for each network path and sets the spin bit in the packet header to the currently stored value when a 1-RTT packet is sent on that path.  The spin value is initialized to 0 in the endpoint for each network path.  Each endpoint also remembers the </ins> highest packet number seen from its peer on each path. <del> When a server receives a short header packet that increases the highest packet number seen by the server from the client on a given network path, it sets the spin value for that path to be equal to the spin bit in the received packet. </del> <ins> When a server receives a 1-RTT packet that increases the highest packet number seen by the server from the client on a given network path, it sets the spin value for that path to be equal to the spin bit in the received packet. </ins> <del> When a client receives a short header packet that increases the highest packet number seen by the client from the server on a given network path, it sets the spin value for that path to the inverse of the spin bit in the received packet. </del> <ins> When a client receives a 1-RTT packet that increases the highest packet number seen by the client from the server on a given network path, it sets the spin value for that path to the inverse of the spin bit in the received packet. </ins> An endpoint resets the spin value for a network path to zero when changing the connection ID being used on that network path.