Change:
3. As discussed in introduction, clients may want different numbers of <del> tickets for fresh or resumed handshakes.  Clients may indicate to </del> <ins> tickets for new or resumed connections.  Clients may indicate to </ins> servers their desired number of tickets to receive on a single <del> connection, in the case of a full handshake or resumption, via the </del> <ins> connection, in the case of a new or resumed connection, via the </ins> following "ticket_request" extension: Clients MAY send this extension in ClientHello.  It contains the following structure: The number of tickets desired by the client when the server <del> chooses to negotiate a fresh session (full handshake). </del> <ins> chooses to negotiate a new connection. </ins> The number of tickets desired by the client when the server is willing to resume using a ticket presented in this ClientHello. <del> A client starting a fresh connection SHOULD set new_session_count to </del> <ins> A client starting a new connection SHOULD set new_session_count to </ins> the desired number of session tickets and resumption_count to 0. Once a client's ticket cache is primed, a resumption_count of 1 is a <del> good choice that allows the server to replace each ticket with a fresh ticket, without over-provisioning the client with excess tickets.  However, clients which race multiple connections and place a separate ticket in each will ultimately end up with just the tickets from a single resumed session.  In that case, clients can send a resumption_count equal to the number of sessions they are attempting in parallel.  (Clients which send a resumption_count less than the number of parallel connection attempts might end up with zero tickets.) </del> <ins> good choice that allows the server to replace each ticket with a new ticket, without over-provisioning the client with excess tickets. However, clients which race multiple connections and place a separate ticket in each will ultimately end up with just the tickets from a single resumed session.  In that case, clients can send a resumption_count equal to the number of sessions they are attempting in parallel.  (Clients which send a resumption_count less than the number of parallel connection attempts might end up with zero tickets.) </ins> When a client presenting a previously obtained ticket finds that the <del> server nevertheless negotiates a fresh session, the client SHOULD </del> <ins> server nevertheless negotiates a new connection, the client SHOULD </ins> assume that any other tickets associated with the same session as the presented ticket are also no longer valid for resumption.  This <del> includes tickets obtained during the initial full handshake and all </del> <ins> includes tickets obtained during the initial (new) connection and all </ins> tickets subsequently obtained as part of subsequent resumptions. <del> Requesting more than one ticket in cases when servers select a full handshake helps keep the session cache primed. </del> <ins> Requesting more than one ticket in cases when servers complete a new connection helps keep the session cache primed. </ins> <del> Servers SHOULD NOT send more tickets than requested for the handshake type selected by the server (resumption or full handshake). </del> <ins> Servers SHOULD NOT send more tickets than requested for the connection type selected by the server (new or resumed connection). </ins> Moreover, servers SHOULD place a limit on the number of tickets they <del> are willing to send, whether for full handshakes or resumptions, to save resources.  Therefore, the number of NewSessionTicket messages sent will typically be the minimum of the server's self-imposed limit and the number requested.  Servers MAY send additional tickets, up to the same limit, if the tickets that are originally sent are somehow invalidated. </del> <ins> are willing to send, whether for new or resumed connections, to save resources.  Therefore, the number of NewSessionTicket messages sent will typically be the minimum of the server's self-imposed limit and the number requested.  Servers MAY send additional tickets, typically using the same limit, if the tickets that are originally sent are somehow invalidated. </ins> A server which supports and uses a client "ticket_request" extension MUST also send the "ticket_request" extension in the

Discussion:
I opted to go with "new connection" instead of "full handshake" (where appropriate), since that seemed to be the more natural phrase. Please let me know what you think! cc NAME (and thanks for the review!)