Draft: draft-ietf-quic-tls

Commentary: This adds a short introductory section to the three sections that deal with 0 - RTT . That might help contextualize and help contain the spaghetti structure that this section seems to have . 
 Thanks  . I took it in a slightly different direction , but I think that I captured this . 
 One high - order bit : Using 0 - RTT as a noun does n't sound right , though we do use it informally in that sense . My suggestion use of " The 0 - RTT handshake delay feature " or " 0 - RTT delay before sending application data " as appropriate . This change looks good .
Paragraph (version A):
To communicate their willingness to process 0-RTT data, servers send
a NewSessionTicket message that contains the "early_data" extension
with a max_early_data_size of 0xffffffff; the amount of data which
the client can send in 0-RTT is controlled by the "initial_max_data"
transport parameter supplied by the server.  Servers MUST NOT send
the "early_data" extension with a max_early_data_size set to any
value other than 0xffffffff.  A client MUST treat receipt of a
NewSessionTicket that contains an "early_data" extension with any
other value as a connection error of type PROTOCOL_VIOLATION.
Paragraph (version A):
A client that wishes to send 0-RTT packets uses the "early_data"
extension in the ClientHello message of a subsequent handshake (see
Section 4.2.10 of TLS13).  It then sends the application data in
0-RTT packets.
Paragraph (version B):
The 0-RTT feature in QUIC allows a client to send application data
before the handshake is complete.  This is made possible by reusing
negotiated parameters from a previous connection.  To enable this,
0-RTT depends on the client remembering critical parameters and
providing the server with a TLS session ticket that allows the server
to recover the same information.
Paragraph (version B):
This information includes parameters that determine TLS state, as
governed by TLS13, QUIC transport parameters, the chosen application
protocol, and any information the application protocol might need;
see app-0rtt.  This information determines how 0-RTT packets and
their contents are formed.
Paragraph (version B):
To ensure that the same information is available to both endpoints,
all information used to establish 0-RTT comes from the same
connection.  Endpoints cannot selectively disregard information that
might alter the sending or processing of 0-RTT.
Paragraph (version B):
TLS13 sets a limit of 7 days on the time between the original
connection and any attempt to use 0-RTT.  There are other constraints
on 0-RTT usage, notably those caused by the potential exposure to
replay attack; see replay.
Paragraph (version B):
To communicate their willingness to process 0-RTT data, servers send
a NewSessionTicket message that contains the "early_data" extension
with a max_early_data_size of 0xffffffff.  The TLS
max_early_data_size parameter is not used in QUIC.  The amount of
data which the client can send in 0-RTT is controlled by the
"initial_max_data" transport parameter supplied by the server.
Paragraph (version B):
Servers MUST NOT send the "early_data" extension with a
max_early_data_size set to any value other than 0xffffffff.  A client
MUST treat receipt of a NewSessionTicket that contains an
"early_data" extension with any other value as a connection error of
type PROTOCOL_VIOLATION.
Paragraph (version B):
A client that wishes to send 0-RTT packets uses the "early_data"
extension in the ClientHello message of a subsequent handshake; see
Section 4.2.10 of TLS13.  It then sends application data in 0-RTT
packets.
Paragraph (version B):
A client that attempts 0-RTT might also provide an address validation
token if the server has sent a NEW_TOKEN frame; see Section 8.1 of
QUIC-TRANSPORT.
Paragraph (version A):
A client MAY attempt to send 0-RTT again if it receives a Retry or
Version Negotiation packet.  These packets do not signify rejection
of 0-RTT.
Paragraph (version B):
A client MAY reattempt 0-RTT if it receives a Retry or Version
Negotiation packet.  These packets do not signify rejection of 0-RTT.