target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.3"

# 13.3.  Retransmission of Information
#
# QUIC packets that are determined to be lost are not retransmitted
# whole.  The same applies to the frames that are contained within lost
# packets.  Instead, the information that might be carried in frames is
# sent again in new frames as needed.
# 
# New frames and packets are used to carry information that is
# determined to have been lost.  In general, information is sent again
# when a packet containing that information is determined to be lost,
# and sending ceases when a packet containing that information is
# acknowledged.
# 
# *  Data sent in CRYPTO frames is retransmitted according to the rules
#    in [QUIC-RECOVERY], until all data has been acknowledged.  Data in
#    CRYPTO frames for Initial and Handshake packets is discarded when
#    keys for the corresponding packet number space are discarded.
# 
# *  Application data sent in STREAM frames is retransmitted in new
#    STREAM frames unless the endpoint has sent a RESET_STREAM for that
#    stream.  Once an endpoint sends a RESET_STREAM frame, no further
#    STREAM frames are needed.
# 
# *  ACK frames carry the most recent set of acknowledgments and the
#    acknowledgment delay from the largest acknowledged packet, as
#    described in Section 13.2.1.  Delaying the transmission of packets
#    containing ACK frames or resending old ACK frames can cause the
#    peer to generate an inflated RTT sample or unnecessarily disable
#    ECN.
# 
# *  Cancellation of stream transmission, as carried in a RESET_STREAM
#    frame, is sent until acknowledged or until all stream data is
#    acknowledged by the peer (that is, either the "Reset Recvd" or
#    "Data Recvd" state is reached on the sending part of the stream).
#    The content of a RESET_STREAM frame MUST NOT change when it is
#    sent again.
# 
# *  Similarly, a request to cancel stream transmission, as encoded in
#    a STOP_SENDING frame, is sent until the receiving part of the
#    stream enters either a "Data Recvd" or "Reset Recvd" state; see
#    Section 3.5.
# 
# *  Connection close signals, including packets that contain
#    CONNECTION_CLOSE frames, are not sent again when packet loss is
#    detected.  Resending these signals is described in Section 10.
# 
# *  The current connection maximum data is sent in MAX_DATA frames.
#    An updated value is sent in a MAX_DATA frame if the packet
#    containing the most recently sent MAX_DATA frame is declared lost
#    or when the endpoint decides to update the limit.  Care is
#    necessary to avoid sending this frame too often, as the limit can
#    increase frequently and cause an unnecessarily large number of
#    MAX_DATA frames to be sent; see Section 4.2.
# 
# *  The current maximum stream data offset is sent in MAX_STREAM_DATA
#    frames.  Like MAX_DATA, an updated value is sent when the packet
#    containing the most recent MAX_STREAM_DATA frame for a stream is
#    lost or when the limit is updated, with care taken to prevent the
#    frame from being sent too often.  An endpoint SHOULD stop sending
#    MAX_STREAM_DATA frames when the receiving part of the stream
#    enters a "Size Known" or "Reset Recvd" state.
# 
# *  The limit on streams of a given type is sent in MAX_STREAMS
#    frames.  Like MAX_DATA, an updated value is sent when a packet
#    containing the most recent MAX_STREAMS for a stream type frame is
#    declared lost or when the limit is updated, with care taken to
#    prevent the frame from being sent too often.
# 
# *  Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED,
#    and STREAMS_BLOCKED frames.  DATA_BLOCKED frames have connection
#    scope, STREAM_DATA_BLOCKED frames have stream scope, and
#    STREAMS_BLOCKED frames are scoped to a specific stream type.  A
#    new frame is sent if a packet containing the most recent frame for
#    a scope is lost, but only while the endpoint is blocked on the
#    corresponding limit.  These frames always include the limit that
#    is causing blocking at the time that they are transmitted.
# 
# *  A liveness or path validation check using PATH_CHALLENGE frames is
#    sent periodically until a matching PATH_RESPONSE frame is received
#    or until there is no remaining need for liveness or path
#    validation checking.  PATH_CHALLENGE frames include a different
#    payload each time they are sent.
# 
# *  Responses to path validation using PATH_RESPONSE frames are sent
#    just once.  The peer is expected to send more PATH_CHALLENGE
#    frames as necessary to evoke additional PATH_RESPONSE frames.
# 
# *  New connection IDs are sent in NEW_CONNECTION_ID frames and
#    retransmitted if the packet containing them is lost.
#    Retransmissions of this frame carry the same sequence number
#    value.  Likewise, retired connection IDs are sent in
#    RETIRE_CONNECTION_ID frames and retransmitted if the packet
#    containing them is lost.
# 
# *  NEW_TOKEN frames are retransmitted if the packet containing them
#    is lost.  No special support is made for detecting reordered and
#    duplicated NEW_TOKEN frames other than a direct comparison of the
#    frame contents.
# 
# *  PING and PADDING frames contain no information, so lost PING or
#    PADDING frames do not require repair.
# 
# *  The HANDSHAKE_DONE frame MUST be retransmitted until it is
#    acknowledged.
# 
# Endpoints SHOULD prioritize retransmission of data over sending new
# data, unless priorities specified by the application indicate
# otherwise; see Section 2.3.
# 
# Even though a sender is encouraged to assemble frames containing up-
# to-date information every time it sends a packet, it is not forbidden
# to retransmit copies of frames from lost packets.  A sender that
# retransmits copies of frames needs to handle decreases in available
# payload size due to changes in packet number length, connection ID
# length, and path MTU.  A receiver MUST accept packets containing an
# outdated frame, such as a MAX_DATA frame carrying a smaller maximum
# data value than one found in an older packet.
# 
# A sender SHOULD avoid retransmitting information from packets once
# they are acknowledged.  This includes packets that are acknowledged
# after being declared lost, which can happen in the presence of
# network reordering.  Doing so requires senders to retain information
# about packets after they are declared lost.  A sender can discard
# this information after a period of time elapses that adequately
# allows for reordering, such as a PTO (Section 6.2 of
# [QUIC-RECOVERY]), or based on other events, such as reaching a memory
# limit.
# 
# Upon detecting losses, a sender MUST take appropriate congestion
# control action.  The details of loss detection and congestion control
# are described in [QUIC-RECOVERY].

[[spec]]
level = "MUST"
quote = '''
The content of a RESET_STREAM frame MUST NOT change when it is
sent again.
'''

[[spec]]
level = "SHOULD"
quote = '''
An endpoint SHOULD stop sending
MAX_STREAM_DATA frames when the receiving part of the stream
enters a "Size Known" or "Reset Recvd" state.
'''

[[spec]]
level = "MUST"
quote = '''
*  The HANDSHAKE_DONE frame MUST be retransmitted until it is
acknowledged.
'''

[[spec]]
level = "SHOULD"
quote = '''
Endpoints SHOULD prioritize retransmission of data over sending new
data, unless priorities specified by the application indicate
otherwise; see Section 2.3.
'''

[[spec]]
level = "MUST"
quote = '''
A receiver MUST accept packets containing an
outdated frame, such as a MAX_DATA frame carrying a smaller maximum
data value than one found in an older packet.
'''

[[spec]]
level = "SHOULD"
quote = '''
A sender SHOULD avoid retransmitting information from packets once
they are acknowledged.
'''

[[spec]]
level = "MUST"
quote = '''
Upon detecting losses, a sender MUST take appropriate congestion
control action.
'''