jiebi/TextFlow huggingface dataset:
Original text:
token, it MUST attempt to validate the token, unless it has already completed address validation.  If the token is invalid then the server SHOULD proceed as if the client did not have a validated <del> address, including potentially sending a Retry.  If the validation succeeds, the server SHOULD then allow the handshake to proceed. </del>  The rationale for treating the client as unvalidated rather than discarding the packet is that the client might have received the token in a previous connection using the NEW_TOKEN frame, and if the server has lost state, it might be unable to validate the token at all, leading to connection failure if the packet is <del> discarded.  A server SHOULD encode tokens provided with NEW_TOKEN frames and Retry packets differently, and validate the latter more strictly. </del>  In a stateless design, a server can use encrypted and authenticated tokens to pass information to clients that the server can later

Reviewer comments:
I think that this can be this simple.
section: Address Validation for Future Connections The following RFC2119 keyword appears within a note, which seems wrong, could the RFC2119 recommendation be moved outside of the note?: /A server SHOULD encode tokens provided with NEW_TOKEN frames and Retry packets differently, and validate the latter more strictly./

Revised text:
token, it MUST attempt to validate the token, unless it has already completed address validation.  If the token is invalid then the server SHOULD proceed as if the client did not have a validated  <ins> address, including potentially sending a Retry.  A server SHOULD encode tokens provided with NEW_TOKEN frames and Retry packets differently, and validate the latter more strictly.  If the validation succeeds, the server SHOULD then allow the handshake to proceed. </ins> The rationale for treating the client as unvalidated rather than discarding the packet is that the client might have received the token in a previous connection using the NEW_TOKEN frame, and if the server has lost state, it might be unable to validate the token at all, leading to connection failure if the packet is  <ins> discarded. </ins> In a stateless design, a server can use encrypted and authenticated tokens to pass information to clients that the server can later
Original text:
This limit does act as an additional constraint on datagram size in the same way as the path MTU, but it is a property of the <del> endpoint and not the path.  It is expected that this is the space an endpoint dedicates to holding incoming packets. </del>  The initial maximum data parameter is an integer value that contains the initial value for the maximum amount of data that can

Reviewer comments:
I did not add a citation for MAX_PLPMTU as that is subtly different and that seems like it would be more of a liability than a help in this case.
Text looks OK.
In maxudppayloadsize (0x03) the following text seems good: /This limit does act as an additional constraint on datagram size in the same way as the path MTU, but it is a property of the endpoint and not the path./ could it refer to the appropriate section in the QUIC spec? In DPLPMTUD the same value is known as “MAXPLPMTU”, Section 5.3.1 - in case you wish to cite that.
MAX_PLPMTU is slightly different as it refers to the IP layer, but you are right that it constrains the same underlying variable. I'll add a cross-reference though.

Revised text:
This limit does act as an additional constraint on datagram size in the same way as the path MTU, but it is a property of the  <ins> endpoint and not the path; see packet-size.  It is expected that this is the space an endpoint dedicates to holding incoming packets. </ins> The initial maximum data parameter is an integer value that contains the initial value for the maximum amount of data that can
Original text:
1-RTT (short-header) <del> A CONNECTION_CLOSE frame of type 0x1d cannot appear in Initial or Handshake packets. </del>  Section 4 of QUIC-TLS provides more detail about these restrictions. Note that all frames can appear in 1-RTT packets. format and assigned semantics of any fields in the frame. The initial contents of this registry are tabulated in frame-types.  22.4.

Reviewer comments:
The first inverts the description of "ih" to be clearer. The second makes it clearer for IANA that the "packets" column can be ignored.

Revised text:
1-RTT (short-header)  <ins> Only a CONNECTION_CLOSE frame of type 0x1c can appear in Initial or Handshake packets. </ins> Section 4 of QUIC-TLS provides more detail about these restrictions. Note that all frames can appear in 1-RTT packets. format and assigned semantics of any fields in the frame. The initial contents of this registry are tabulated in frame-types. <ins> Note that the registry does not include the "Packets" column from frame-types. </ins> 22.4.
Original text:
initial_max_stream_data_bidi_remote, or initial_max_streams_uni and initial_max_stream_data_uni.  A server MUST either reject 0-RTT data or abort a handshake if the implied values for transport parameters cannot be supported.

Reviewer comments:
The section for "Values of Transport Parameters for 0-RTT" specifies which parameters a client MUST or MUST NOT remember. It does not do the same for a server. (It implies that ones a client MUST NOT remember also don't need to be remembered by a server, and it lists a subset of the remaining as ones the server MUST remember.) This commit adds the remaining parameters to a list that the server need not remember.
This still looks good with the latest commit Jana pushed.
The "Values of Transport Parameters for 0-RTT" section lists some, but not all, of the transport parameters defined in the spec. As currently written, it is ambiguous whether a server needs to remember the parameters not listed. (A list of parameters that the client MUST NOT remember, and therefore the server need not remember, is provided, as well as a list that the server MUST remember so it doesn't lower limits.) As far as I understand the definitions of the remaining parameters, there isn't any need for a server to remember them. However, instead of requiring implementors to read through all of the transport parameter definitions and infer this on their own, it would be easier on implementors to spell this out in this section. (This is required for definitions of new parameters.)
I like the latest text!

Revised text:
initial_max_stream_data_bidi_remote, or initial_max_streams_uni and initial_max_stream_data_uni. <ins> A server MAY store and recover the previously sent values of the max_idle_timout, max_udp_payload_size, and disable_active_migration parameters and reject 0-RTT if it selects smaller values.  Lowering the values of these parameters while also accepting 0-RTT data could degrade the performance of the connection.  Specifically, lowering the max_udp_payload_size could result in dropped packets leading to worse performance compared to rejecting 0-RTT data outright. </ins> A server MUST either reject 0-RTT data or abort a handshake if the implied values for transport parameters cannot be supported.
Original text:
An HTTP origin advertises the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 <del> ALTSVC frame (ALTSVC), using the ALPN token defined in connection- establishment. </del>  For example, an origin could indicate in an HTTP response that HTTP/3 was available on UDP port 50781 at the same hostname by including the

Reviewer comments:
Actually, as 3.1 is "to bre removed before publication", the expansion and ref should be in 3.2.1.

Revised text:
An HTTP origin advertises the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field or the HTTP/2  <ins> ALTSVC frame (ALTSVC), using the Application Layer Protocol Negotiation (ALPN) RFC7301 token defined in connection-establishment. </ins> For example, an origin could indicate in an HTTP response that HTTP/3 was available on UDP port 50781 at the same hostname by including the
Original text:
amount of data. Implementations MUST support buffering at least 4096 bytes of data <del> received in out of order CRYPTO frames.  Endpoints MAY choose to </del>  allow more data to be buffered during the handshake.  A larger limit during the handshake could allow for larger keys or credentials to be exchanged.  An endpoint's buffer size does not need to remain

Reviewer comments:
NAME should merge this.
I'm assuming that you checked the others, and therefore surprised we got the others right.

Revised text:
amount of data. Implementations MUST support buffering at least 4096 bytes of data  <ins> received in out-of-order CRYPTO frames.  Endpoints MAY choose to </ins> allow more data to be buffered during the handshake.  A larger limit during the handshake could allow for larger keys or credentials to be exchanged.  An endpoint's buffer size does not need to remain
Original text:
bytes in length.  Connection IDs are described in connection-id. The next byte contains the length in bytes of the Source Connection <del> ID field that follows it.  This length is encoded as a 8-bit unsigned integer.  The Source Connection ID field follows the Source </del>  Connection ID Length field and is between 0 and 255 bytes in length. The remainder of the packet contains version-specific content. fields, or a truncated Supported Version. Version Negotiation packets do not use integrity or confidentiality <del> protection.  A specific QUIC version might authenticate the packet as part of its connection establishment process. </del>  An endpoint MUST include the value from the Source Connection ID field of the packet it receives in the Destination Connection ID

Reviewer comments:
My WGLC feedback for -invariants is mostly nits, so I figured I'd go straight to a PR. There's one piece of this that might be non-editorial; feel free to kick to an issue if you prefer. In one section, we say that different versions "might" define authentication for VN packets. Later, we say that QUIC versions MUST define such a mechanism. Resolving in favor of the MUST, I've changed the other occurrence to a more definitive statement that QUIC versions do so.
Thanks Mike.

Revised text:
bytes in length.  Connection IDs are described in connection-id. The next byte contains the length in bytes of the Source Connection  <ins> ID field that follows it.  This length is encoded as an 8-bit unsigned integer.  The Source Connection ID field follows the Source </ins> Connection ID Length field and is between 0 and 255 bytes in length. The remainder of the packet contains version-specific content. fields, or a truncated Supported Version. Version Negotiation packets do not use integrity or confidentiality  <ins> protection.  Specific QUIC versions define mechanisms to authenticate the packet as part of the connection establishment process. </ins> An endpoint MUST include the value from the Source Connection ID field of the packet it receives in the Destination Connection ID
Original text:
first byte being set; packets with a short header have that bit cleared.  Aside from the values described here, the payload of QUIC packets is version-specific and of arbitrary length. QUIC versions are identified with a 32-bit integer, encoded in network byte order.  Version 0 is reserved for version negotiation <del> (see version-negotiation).  All other version numbers are potentially valid. </del>  The properties described in this document apply to all versions of QUIC.  A protocol that does not conform to the properties described

Reviewer comments:
Or MAY, but let's leave this probabilistic, because in practice there is no uncertainty: packets are protected. I've changed the header of the section because it isn't just about the header: the subsections are about the specific headers, but this one is about packets as a whole.

Revised text:
first byte being set; packets with a short header have that bit cleared. <ins> QUIC packets might be integrity protected, including the header. However, QUIC Version Negotiation packets are not integrity protected; see vn. </ins> Aside from the values described here, the payload of QUIC packets is version-specific and of arbitrary length. QUIC versions are identified with a 32-bit integer, encoded in network byte order.  Version 0 is reserved for version negotiation  <ins> (see vn).  All other version numbers are potentially valid. </ins> The properties described in this document apply to all versions of QUIC.  A protocol that does not conform to the properties described
Original text:
HTTP/1.1 HTTP11 is a TCP mapping which uses whitespace-delimited text fields to convey HTTP messages.  While these exchanges are human- readable, using whitespace for message formatting leads to parsing <del> complexity and motivates tolerance of variant behavior.  Because each connection can transfer only a single HTTP request or response at a time in each direction, multiple parallel TCP connections are often used, reducing the ability of the congestion controller to effectively manage traffic between endpoints. </del>  HTTP/2 HTTP2 introduced a binary framing and multiplexing layer to improve latency without modifying the transport layer.  However,

Reviewer comments:
NAME raised the point that the following text might be misleading, since HTTP/1.1 allows pipelining: "HTTP/1.1 [HTTP11] is a TCP mapping which uses whitespace-delimited text fields to convey HTTP messages. While these exchanges are human-readable, using whitespace for message formatting leads to parsing complexity and motivates tolerance of variant behavior. Because each connection can transfer only a single HTTP request or response at a time in each direction, multiple parallel TCP connections are often used, reducing the ability of the congestion controller to effectively manage traffic between endpoints." NAME suggested the following text instead: "Because of limitations in how HTTP exchanges are mapped onto TCP connections in HTTP/1.1, multiple parallel connections are often used..." NAME suggested the following text instead: "Because HTTP/1.x does not include a multiplexing layer, multiple TCP connections are often used to service requests in parallel. However, that has a negative impact on congestion control and network efficiency, since TCP does not share congestion control across multiple connections."
Roy's works for me.

Revised text:
HTTP/1.1 HTTP11 is a TCP mapping which uses whitespace-delimited text fields to convey HTTP messages.  While these exchanges are human- readable, using whitespace for message formatting leads to parsing  <ins> complexity and motivates tolerance of variant behavior.  Because HTTP/1.x does not include a multiplexing layer, multiple TCP connections are often used to service requests in parallel.  However, that has a negative impact on congestion control and network efficiency, since TCP does not share congestion control across multiple connections. </ins> HTTP/2 HTTP2 introduced a binary framing and multiplexing layer to improve latency without modifying the transport layer.  However,
Original text:
The IPv6 flow label SHOULD be a pseudo-random function of the source and destination addresses, source and destination UDP ports, and the <del> destination CID.  The flow label generation MUST be designed to minimize the chances of linkability with a previously used flow label, as this would enable correlating activity on multiple paths; see migration-linkability. </del>  A possible implementation is to compute the flow label as a cryptographic hash function of the source and destination addresses, <del> source and destination UDP ports, destination CID, and a local secret. </del>  10.

Reviewer comments:
We've been pretty disciplined about using "connection ID", except for the text on flow labels and one mention in the diagram for preferred_address. Of course, the mentions in the flow label text were specifically for the "Destination Connection ID field", so that is what I used there.
"Use of IPv6 Flow-Label and Migration" and the definition of "preferred_address" both reference "CID" without that abbreviation of Connection ID having been defined elsewhere. It's pretty obvious, but the text for IPv6 should probably just write out connection ID in long form.

Revised text:
The IPv6 flow label SHOULD be a pseudo-random function of the source and destination addresses, source and destination UDP ports, and the  <ins> Destination Connection ID field.  The flow label generation MUST be designed to minimize the chances of linkability with a previously used flow label, as this would enable correlating activity on multiple paths; see migration-linkability. </ins> A possible implementation is to compute the flow label as a cryptographic hash function of the source and destination addresses,  <ins> source and destination UDP ports, Destination Connection ID field, and a local secret. </ins> 10.
Original text:
The server's preferred address is used to effect a change in server address at the end of the handshake, as described in <del> preferred-address.  The format of this transport parameter is shown in fig-preferred-address.  This transport parameter is only sent by a server.  Servers MAY choose to only send a preferred address of one address family by sending an all-zero address and port (0.0.0.0:0 or ::.0) for the other family.  IP addresses are </del>  encoded in network byte order.  The Connection ID field and the Stateless Reset Token field contain an alternative connection ID that has a sequence number of 1; see issue-cid.  Having these values bundled with the preferred

Reviewer comments:
In section 18.2, the definition of preferred_address says: In section 1.3, we say: The prose does not define the sequence of fields in this transport parameter.
Thanks for catching that I was looking at the wrong TP definition and knowing what I meant. Eyes glaze over indeed!

Revised text:
The server's preferred address is used to effect a change in server address at the end of the handshake, as described in  <ins> preferred-address.  This transport parameter is only sent by a server.  Servers MAY choose to only send a preferred address of one address family by sending an all-zero address and port (0.0.0.0:0 or ::.0) for the other family.  IP addresses are </ins> encoded in network byte order. <ins> The preferred_address transport parameter contains an address and port for both IP version 4 and 6.  The four-byte IPv4 Address field is followed by the associated two-byte IPv4 Port field. This is followed by a 16-byte IPv6 Address field and two-byte IPv6 Port field.  After address and port pairs, a Connection ID Length field describes the length of the following Connection ID field. Finally, a 16-byte Stateless Reset Token field includes the stateless reset token associated with the connection ID.  The format of this transport parameter is shown in fig-preferred- address. </ins> The Connection ID field and the Stateless Reset Token field contain an alternative connection ID that has a sequence number of 1; see issue-cid.  Having these values bundled with the preferred
Original text:
the application protocol that QUIC serves. TLS session tickets and address validation tokens are used to <del> carry QUIC configuration information between connections.  These MUST NOT be used to carry application semantics.  The potential for reuse of these tokens means that they require stronger protections against replay. </del>  A server that accepts 0-RTT on a connection incurs a higher cost than accepting a connection without 0-RTT.  This includes higher

Reviewer comments:
The text here was perhaps a little unclear on this point. The point is that these don't carry information from server to client or client to server, they carry information from server (previous) to server (next).
There seems to be a conflict between this assertion in Section 9.2: URL the fact that 4.8 explicitly discusses how application protocols might need to have data embedded in the session ticket. (Also, QUIC doesn't use TLS address validation tokens.) I think this is actually trying to say that receipt of the session ticket MUST NOT cause side-effect beyond setting up the connection, but it's a broader prohibition than that.
I think that it says something else, namely that these are not intended to convey semantic information from client to server (or vice versa). PR inbound.

Revised text:
the application protocol that QUIC serves. TLS session tickets and address validation tokens are used to  <ins> carry QUIC configuration information between connections. Specifically, to enable a server to efficiently recover state that is used in connection establishment and address validation.  These MUST NOT be used to communicate application semantics between endpoints; clients MUST treat them as opaque values.  The potential for reuse of these tokens means that they require stronger protections against replay. </ins> A server that accepts 0-RTT on a connection incurs a higher cost than accepting a connection without 0-RTT.  This includes higher
Original text:
4.1.5. exchange-summary summarizes the exchange between QUIC and TLS for <del> both client and server.  Each arrow is tagged with the encryption level used for that transmission. </del>  exchange-summary shows the multiple packets that form a single "flight" of messages being processed individually, to show what incoming messages trigger different actions.  New handshake messages <del> are requested after all incoming packets have been processed.  This process might vary depending on how QUIC implementations and the packets they receive are structured. </del>  4.2.

Reviewer comments:
I came back to this today and found that the ordering was inconsistent and not sufficiently clear. Changing this so that all the actions for a single endpoint were grouped seemed to be the best arrangement. All events and actions are as close as possible in the ordering to the preceding event that caused or enabled it. The application data packets are displayed with a different marking, which helps distinguish those that carry CRYPTO frames. The final implied exchange for Get Handshake was removed. This was, I think, intended to imply something about session tickets. Without explanation, it is confusing. This doesn't show HANDSHAKE_DONE, nor do I think that it should, because that is something that the transport does once it gets the Handshake Complete signal.
LGTM, one suggestion

Revised text:
4.1.5. exchange-summary summarizes the exchange between QUIC and TLS for  <ins> both client and server.  Solid arrows indicate packets that carry handshake data; dashed arrows show where application data can be sent.  Each arrow is tagged with the encryption level used for that transmission. </ins> exchange-summary shows the multiple packets that form a single "flight" of messages being processed individually, to show what incoming messages trigger different actions.  New handshake messages  <ins> are requested after incoming packets have been processed.  This process varies based on the structure of endpoint implementations and the order in which packets arrive; this is intended to illustrate the steps involved in a single handshake exchange. </ins> 4.2.