jiebi/TextFlow huggingface dataset:
Original text:
packets.  That document could specify that compatible version negotiation causes 0-RTT data to be rejected by the server. <del> 7. </del>  Because QUIC version 1 was the only IETF Standards Track version of QUIC published before this document, it is handled specially as

Reviewer comments:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Revised text:
packets.  That document could specify that compatible version negotiation causes 0-RTT data to be rejected by the server.  <ins> 8. </ins> Because QUIC version 1 was the only IETF Standards Track version of QUIC published before this document, it is handled specially as
Original text:
version negotiation to negotiate versions other than QUIC version 1 will need to implement this draft. <del> 8. </del>  The security of this version negotiation mechanism relies on the authenticity of the Version Information exchanged during the

Reviewer comments:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Revised text:
version negotiation to negotiate versions other than QUIC version 1 will need to implement this draft.  <ins> 9. </ins> The security of this version negotiation mechanism relies on the authenticity of the Version Information exchanged during the
Original text:
possibility of cross-protocol attacks, but more analysis is still needed here. <del> 9. </del>  <del> 9.1. </del>  This document registers a new value in the "QUIC Transport Parameters" registry maintained at

Reviewer comments:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Revised text:
possibility of cross-protocol attacks, but more analysis is still needed here.  <ins> 10. </ins>  <ins> 10.1. </ins> This document registers a new value in the "QUIC Transport Parameters" registry maintained at
Original text:
of a codepoint in the 0-63 range to replace the provisional codepoint described above. <del> 9.2. </del>  This document registers a new value in the "QUIC Transport Error Codes" registry maintained at <<https://www.iana.org/assignments/

Reviewer comments:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Revised text:
of a codepoint in the 0-63 range to replace the provisional codepoint described above.  <ins> 10.2. </ins> This document registers a new value in the "QUIC Transport Error Codes" registry maintained at <<https://www.iana.org/assignments/
Original text:
attempt prior to receiving the Version Negotiation packet is distinct from the connection with the incompatible version that follows.  2.5. When the client picks its original version, it will try to avoid

Reviewer comments:
I am not sure that I agree with this as some state carries across from the first connection attempt to the second (and hopefully successfully completed) connection. (Also, I've implemented this within the same connection object. I know that other implementations differ here, so what I'm looking for is a little finesse in how this is framed.)

Revised text:
attempt prior to receiving the Version Negotiation packet is distinct from the connection with the incompatible version that follows. <ins> Note that this separation across two connections is conceptual: it applies to normative requirements on QUIC connections, but does not require implementations to internally use two distinct connection objects. </ins> 2.5. When the client picks its original version, it will try to avoid
Original text:
differ after the handshake, then A is compatible with B and B is compatible with A. <del> Version compatibility is not bijective: it is possible for version A </del>  to be compatible with version B and for B not to be compatible with A.  This could happen for example if version B is a strict superset of version A.

Reviewer comments:
Bijective should be symmetric. We're describing a relation not a function. This is a very minor comment, will send a PR hopefully soon.
Indeed, my math is pretty rusty :) Totally agree with you, and thanks for offering to write the PR!
NAME any luck with the PR?
I completely forgot about this!
URL opened
Closing now that has been merged.

Revised text:
differ after the handshake, then A is compatible with B and B is compatible with A.  <ins> Version compatibility is not symmetric: it is possible for version A </ins> to be compatible with version B and for B not to be compatible with A.  This could happen for example if version B is a strict superset of version A.
Original text:
6. Clients MUST ignore any received Version Negotiation packets that <del> contain the version that they initially attempted.  Once a client has reacted to a Version Negotiation packet, it MUST drop all subsequent Version Negotiation packets on that connection. </del>  Both endpoints MUST parse their peer's Version Information during the handshake.  If parsing the Version Information failed (for example,

Reviewer comments:
The draft says explicitly that receiving Version Negotiation terminates a connection attempt. This isn't consistent with that. This probably needs to say something like this instead:
That sounds good to me, can you make this a PR?

Revised text:
6. Clients MUST ignore any received Version Negotiation packets that  <ins> contain the version that they initially attempted.  A client that makes a connection attempt based on information received from a Version Negotiation packet MUST ignore any Version Negotiation packets it receives in response to that connection attempt. </ins> Both endpoints MUST parse their peer's Version Information during the handshake.  If parsing the Version Information failed (for example,
Original text:
topic is used to correlate push messages sent to the same subscription and does not convey any other semantics. <del> The grammar for the Topic header field uses the "token" and "quoted- string" rules defined in RFC7230. Any double quotes from the "quoted-string" form are removed before comparing topics for equality. </del>  For use with this protocol, the Topic header field MUST be restricted to no more than 32 characters from the URL and filename safe Base 64

Reviewer comments:
NAME suggested this. It's a simplification that should reduce errors. It prevents topics like "Hello world!", but that's probably a good thing on balance.

Revised text:
topic is used to correlate push messages sent to the same subscription and does not convey any other semantics.  <ins> The grammar for the Topic header field uses the "token" rule defined in RFC7230. </ins> For use with this protocol, the Topic header field MUST be restricted to no more than 32 characters from the URL and filename safe Base 64
Original text:
Generic Event Delivery Using HTTP Push <del> draft-thomson-webpush-protocol-latest </del>  Abstract

Reviewer comments:
closed closed renamed draft-thomson-webpush-URL to draft-ietf-webpush-URL updated the HTTP/2 reference updated the alt-svc reference
From Darshak Thakore feedback: Add Push-Receipt header to Section 5 example Reference in Section 5.1
From Darshak Thakore review: Section 5 - In the example, Is the post operation to the right URL? Is that just an editorial oversight or is that the intended URL? Current example: POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 Probably should be: POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 The current example is incorrect. It should match the urn:ietf:params:push link relation returned in the Subscription response - /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV - and distributed to the application server.

Revised text:
Generic Event Delivery Using HTTP Push  <ins> draft-ietf-webpush-protocol-latest </ins> Abstract
Original text:
Examples in this document use the RFC7230.  Many of the exchanges can be completed using HTTP/1.1, where HTTP/2 is necessary, the more <del> verbose frame format from I-D.ietf-httpbis-http2 is used. </del>  2.

Reviewer comments:
closed closed renamed draft-thomson-webpush-URL to draft-ietf-webpush-URL updated the HTTP/2 reference updated the alt-svc reference
From Darshak Thakore feedback: Add Push-Receipt header to Section 5 example Reference in Section 5.1
From Darshak Thakore review: Section 5 - In the example, Is the post operation to the right URL? Is that just an editorial oversight or is that the intended URL? Current example: POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 Probably should be: POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 The current example is incorrect. It should match the urn:ietf:params:push link relation returned in the Subscription response - /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV - and distributed to the application server.

Revised text:
Examples in this document use the RFC7230.  Many of the exchanges can be completed using HTTP/1.1, where HTTP/2 is necessary, the more  <ins> verbose frame format from RFC7540 is used. </ins> 2.
Original text:
A user agent requests the delivery of new push messages by making a GET request to a push message subscription resource.  The push <del> service does not respond to this request, it instead uses I-D.ietf- httpbis-http2 to send the contents of push messages as they are sent by application servers. </del>  Each push message is pushed in response to a synthesized GET request. The GET request is made to the push message resource that was created

Reviewer comments:
closed closed renamed draft-thomson-webpush-URL to draft-ietf-webpush-URL updated the HTTP/2 reference updated the alt-svc reference
From Darshak Thakore feedback: Add Push-Receipt header to Section 5 example Reference in Section 5.1
From Darshak Thakore review: Section 5 - In the example, Is the post operation to the right URL? Is that just an editorial oversight or is that the intended URL? Current example: POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 Probably should be: POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 The current example is incorrect. It should match the urn:ietf:params:push link relation returned in the Subscription response - /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV - and distributed to the application server.

Revised text:
A user agent requests the delivery of new push messages by making a GET request to a push message subscription resource.  The push  <ins> service does not respond to this request, it instead uses RFC7540 to send the contents of push messages as they are sent by application servers. </ins> Each push message is pushed in response to a synthesized GET request. The GET request is made to the push message resource that was created
Original text:
The application server requests the delivery of receipts from the push server by making a HTTP GET request to the receipt subscription resource.  The push service does not respond to this request, it <del> instead uses I-D.ietf-httpbis-http2 to send push receipts when messages are acknowledged (acknowledge_message) by the user agent. </del>  Each receipt is pushed in response to a synthesized GET request.  The GET request is made to the same push message resource that was

Reviewer comments:
closed closed renamed draft-thomson-webpush-URL to draft-ietf-webpush-URL updated the HTTP/2 reference updated the alt-svc reference
From Darshak Thakore feedback: Add Push-Receipt header to Section 5 example Reference in Section 5.1
From Darshak Thakore review: Section 5 - In the example, Is the post operation to the right URL? Is that just an editorial oversight or is that the intended URL? Current example: POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 Probably should be: POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 The current example is incorrect. It should match the urn:ietf:params:push link relation returned in the Subscription response - /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV - and distributed to the application server.

Revised text:
The application server requests the delivery of receipts from the push server by making a HTTP GET request to the receipt subscription resource.  The push service does not respond to this request, it  <ins> instead uses RFC7540 to send push receipts when messages are acknowledged (acknowledge_message) by the user agent. </ins> Each receipt is pushed in response to a synthesized GET request.  The GET request is made to the same push message resource that was
Original text:
4.2.  In order to reduce the complexity of implementing WHIP in both clients and media servers, WHIP imposes the following restrictions regarding WebRTC usage:

Reviewer comments:
The text says: "The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node," I don't understand this sentence. If I use an "older protocol", e.g, RTMP, why do I need to care about WebRTC codecs?
That refers if you use RTMP for ingest and WebRTC for viewing.
rewriten the editorial in
The text says: "These protocols are much older than webrtc and lack by default some important security and resilience features provided by webrtc with minimal delay." I assume you refer to RTMP, which is mentioned in the previous Section. Doesn't RTMPS solve some of the security issues? But in general, if you want to put up WHIP against RTMP, I think you need a little more text. Also, as WHIP is supposed to be an "easy to implement" protocol, I think it would be fair to also list some of the functions NOT supported compared to e.g., RTMP. As I have mentioned before, there is no command for start the ingestion - it is assumed to have begun when the connection has been established. Also, there is no PAUSE/RESUME.
It is more referring to RTSP which lacks DTLS support. no command for start the ingestion - it is assumed to have begun when the connection has been established. Also, there is no PAUSE/RESUME. RTMP protocol was intended as an RPC mechanism between the flash player and server. It allowed to create custom apps both on client and server side, which supported a wide range of methods using AMF. However, current "RTMP protocol" implemented for ingesting is a reversed engineered version of the implementation done by the FMS and it lacks support for PAUSE/RESUME and the publication is started from the start of the RTMP connection (same as whip).
rewriten the editorial in

Revised text:
4.2. <ins> In the specific case of media ingestion into a streaming service, some assumptions can be made about the server-side which simplifies the WebRTC compliance burden, as detailed in WebRTC-gateway document draft-ietf-rtcweb-gateways. </ins> In order to reduce the complexity of implementing WHIP in both clients and media servers, WHIP imposes the following restrictions regarding WebRTC usage:
Original text:
The initial offer by the WHIP client MAY be sent after the full ICE gathering is complete with the full list of ICE candidates, or it MAY <del> only contain local candidates (or even an empty list of candidates). </del>  In order to simplify the protocol, there is no support for exchanging gathered trickle candidates from Media Server ICE candidates once the

Reviewer comments:
NAME ping?
Section 4.1 “The WHIP client MAY perform trickle ICE or ICE restarts ] by sending an HTTP PATCH request…” Why is there a reference to RFC8863, which specifies ICE PAC, here? In general a reference to ICE PAC is useful, because this draft allows an offer without any candidates. So maybe that reference should go at the end of: “The initial offer by the WHIP client MAY be sent after the full ICE gathering is complete with the full list of ICE candidates, or it MAY only contain local candidates (or even an empty list of candidates).”
I think it was a typo.
I created a PR to fix the tricke ice reference and add the pac one as suggested.

Revised text:
The initial offer by the WHIP client MAY be sent after the full ICE gathering is complete with the full list of ICE candidates, or it MAY  <ins> only contain local candidates (or even an empty list of candidates) as per RFC8863. </ins> In order to simplify the protocol, there is no support for exchanging gathered trickle candidates from Media Server ICE candidates once the
Original text:
candidates of the Media Server.  The Media Server MAY use ICE lite, while the WHIP client MUST implement full ICE. <del> The WHIP client MAY perform trickle ICE or ICE restarts RFC8863 by sending an HTTP PATCH request to the WHIP resource URL with a body containing a SDP fragment with MIME type "application/trickle-ice- sdpfrag" as specified in RFC8840.  When used for trickle ICE, the body of this PATCH message will contain the new ICE candidate; when used for ICE restarts, it will contain a new ICE ufrag/pwd pair. </del>  Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource. If the WHIP resource supports either Trickle ICE or ICE restarts, but

Reviewer comments:
NAME ping?
Section 4.1 “The WHIP client MAY perform trickle ICE or ICE restarts ] by sending an HTTP PATCH request…” Why is there a reference to RFC8863, which specifies ICE PAC, here? In general a reference to ICE PAC is useful, because this draft allows an offer without any candidates. So maybe that reference should go at the end of: “The initial offer by the WHIP client MAY be sent after the full ICE gathering is complete with the full list of ICE candidates, or it MAY only contain local candidates (or even an empty list of candidates).”
I think it was a typo.
I created a PR to fix the tricke ice reference and add the pac one as suggested.

Revised text:
candidates of the Media Server.  The Media Server MAY use ICE lite, while the WHIP client MUST implement full ICE.  <ins> The WHIP client MAY perform trickle ICE or ICE restarts as per RFC8838 by sending an HTTP PATCH request to the WHIP resource URL with a body containing a SDP fragment with MIME type "application/ trickle-ice-sdpfrag" as specified in RFC8840.  When used for trickle ICE, the body of this PATCH message will contain the new ICE candidate; when used for ICE restarts, it will contain a new ICE ufrag/pwd pair. </ins> Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource. If the WHIP resource supports either Trickle ICE or ICE restarts, but