jiebi/TextFlow huggingface dataset:
Original text:
negotiation (both compatible and incompatible) interacts with retry during a handshake that requires both.  For example, that could be accomplished by having the server send a Retry packet in the original <del> version first and therefore validating the client's IP address before </del>  attempting compatible version negotiation.  If both versions support authenticating Retry packets, the compatibility defition needs to define how to authenticate the Retry in the negotiated version QUIC version 1 uses TLS 1.3, which supports session resumption by sending session tickets in one connection that can be used in a later connection; see TLS.  New versions that also use TLS 1.3 SHOULD <del> mandate that their session tickets are rightly scoped to one version of QUIC; i.e., require that clients not use them across version and that servers validate this client requirement. </del>  6.3. 0-RTT, that document MUST address the scenario where there are 0-RTT packets in the client's first flight.  For example, this could be accomplished by defining which transformations are applied to 0-RTT <del> packets.  Alternatively, that document could specify that compatible version negotiation causes 0-RTT data to be rejected by the server. </del>  7.

Reviewer comments:
s/and therefore/, thereby/
s/rightly/tightly s/across version/across multiple versions
s/Alternatively, t/T/

Revised text:
negotiation (both compatible and incompatible) interacts with retry during a handshake that requires both.  For example, that could be accomplished by having the server send a Retry packet in the original  <ins> version first thereby validating the client's IP address before </ins> attempting compatible version negotiation.  If both versions support authenticating Retry packets, the compatibility defition needs to define how to authenticate the Retry in the negotiated version QUIC version 1 uses TLS 1.3, which supports session resumption by sending session tickets in one connection that can be used in a later connection; see TLS.  New versions that also use TLS 1.3 SHOULD  <ins> mandate that their session tickets are tightly scoped to one version of QUIC; i.e., require that clients not use them across multiple version and that servers validate this client requirement. </ins> 6.3. 0-RTT, that document MUST address the scenario where there are 0-RTT packets in the client's first flight.  For example, this could be accomplished by defining which transformations are applied to 0-RTT  <ins> packets.  That document could specify that compatible version negotiation causes 0-RTT data to be rejected by the server. </ins> 7.
Original text:
The Application Server then encrypts the payload.  Header fields are populated with URL-safe base-64 encoded RFC4648 values: <del> the "keyid" from the User Agent is added to both the Encryption- Key and Encryption header fields; </del> the salt is added to the "salt" parameter of the Encryption header field; and the "rs" parameter can be omitted for messages that fit within this limit.  4. A User Agent decrypts messages are decrypted as described in I-

Reviewer comments:
NAME was unhappy about the freedom we offered. This doesn't remove the header field separation, but it removes most of it.
Thank you, Martin! This looks good to me.

Revised text:
The Application Server then encrypts the payload.  Header fields are populated with URL-safe base-64 encoded RFC4648 values:  the salt is added to the "salt" parameter of the Encryption header field; and the "rs" parameter can be omitted for messages that fit within this limit. <ins> An application server MUST NOT use other content encodings for push messages.  In particular, content encodings that compress could result in leaking of push message contents.  The Content-Encoding header field therefore has exactly one value, which is "aesgcm128". An application server MUST include exactly one entry in each of the Encryption and Encryption-Key header fields.  This allows the "keyid" parameter to be omitted from both header fields. An application server MUST NOT include a "key" parameter in the Encryption header field. </ins> 4. A User Agent decrypts messages are decrypted as described in I-
Original text:
Server with other details of the push subscription. When sending a message, an Application Server generates an ECDH key <del> pair and a random salt.  The ECDH public key is encoded into the "dh" parameter of the Crypto-Key header field; the salt is encoded into message payload.  The ECDH key pair can be discarded after encrypting the message. </del>  The content of the push message is encrypted or decrypted using a content encryption key and nonce that is derived using all of these An Application combines its ECDH private key with the public key provided by the User Agent using the process described in ECDH; on receipt of the push message, a User Agent combines its private key <del> with the public key provided by the Application Server in the "dh" </del>  parameter in the same way.  These operations produce the same value for the ECDH shared secret. the shared secret derived using ECDH the concatenation of the ASCII-encoded string "WebPush: info", a <del> zero octet, the X9.62 encoding of the User Agent ECDH public key, and X9.62 encoding of the Application Server ECDH public key; that is </del>  32 octets (i.e., the output is the length of the underlying SHA-256 HMAC function output)

Reviewer comments:
/cc NAME Not sure about "parameter of that same header" phrasing. Not a fan of duplicating the text about the content coding header either. Suggestions?
Yep, these are both correct. Thanks.

Revised text:
Server with other details of the push subscription. When sending a message, an Application Server generates an ECDH key  <ins> pair and a random salt.  The ECDH public key is encoded into the "keyid" parameter of the encrypted content coding header, the salt in the "salt" parameter of that same header (see Section 2.1 of I- D.ietf-httpbis-encryption-encoding).  The ECDH key pair can be discarded after encrypting the message. </ins> The content of the push message is encrypted or decrypted using a content encryption key and nonce that is derived using all of these An Application combines its ECDH private key with the public key provided by the User Agent using the process described in ECDH; on receipt of the push message, a User Agent combines its private key  <ins> with the public key provided by the Application Server in the "keyid" </ins> parameter in the same way.  These operations produce the same value for the ECDH shared secret. the shared secret derived using ECDH the concatenation of the ASCII-encoded string "WebPush: info", a  <ins> zero octet, and the User Agent ECDH public key and the Application Server ECDH public key, both in the uncompressed point form defined in X9.62; that is </ins> 32 octets (i.e., the output is the length of the underlying SHA-256 HMAC function output)
Original text:
the "keyid" parameter of the encrypted content coding header.  The uncompressed point form defined in X9.62 (that is, a 65 octet sequence that starts with a 0x04 octet) forms the entirety of the <del> "keyid". </del>  A push service is not required to support more than 4096 octets of payload body (see Section 7.2 of RFC8030).  Absent header (86

Reviewer comments:
This is the best that I can do for this one..
I think this is as good as it gets.

Revised text:
the "keyid" parameter of the encrypted content coding header.  The uncompressed point form defined in X9.62 (that is, a 65 octet sequence that starts with a 0x04 octet) forms the entirety of the  <ins> "keyid".  Note that this means that the "keyid" parameter will not be valid UTF-8 as recommended in RFC8188. </ins> A push service is not required to support more than 4096 octets of payload body (see Section 7.2 of RFC8030).  Absent header (86
Original text:
header field therefore has exactly one value, which is "aesgcm128". Multiple "aesgcm128" values are not permitted. <del> An application server MUST include exactly one entry in each of the Encryption and Crypto-Key header fields.  This allows the "keyid" parameter to be omitted from both header fields. </del>  An application server MUST NOT include an "aesgcm128" parameter in the Encryption header field.

Reviewer comments:
defines: This removes a number of edge-cases and simplifies implementations. However, defines: Which is a violation of the former. Semantically it makes most sense for these to be distinct values since they're intended for different audiences. I'll propose a PR limiting webpush-encryption to one Crypto-Key entry having a value instead.
Because life is complicated, there are some libraries that are using ";" and creating a single parameter set containing both ECE and VAPID parameters, e.g. Because of "quirks" in both the mozilla and FCM handlers, this works. It may be beneficial if legacy push servers continue to support this behavior while libraries and applications that depend on them transition to any new division format.

Revised text:
header field therefore has exactly one value, which is "aesgcm128". Multiple "aesgcm128" values are not permitted.  <ins> An application server MUST include exactly one entry in the Encryption field, and at most one entry having a "dh" parameter in the Crypto-Key field.  This allows the "keyid" parameter to be omitted from both header fields. </ins> An application server MUST NOT include an "aesgcm128" parameter in the Encryption header field.
Original text:
A user agent MAY omit the subscription set if it is unable to receive push messages in an aggregated way for the lifetime of the subscription.  This might be necessary if the user agent is <del> monitoring subscriptions for other clients (see sets-streams). </del>  The push service SHOULD return the same subscription set in its response, although it MAY return a new subscription set if it is unable to receive receipts in an aggregated way for the lifetime of the receipt subscription.  This might be necessary if the application server is monitoring receipt subscriptions on the behalf of other <del> push message senders (see sets-streams). </del>  A push service MUST return a 400 (Bad Request) status code for requests which contain an invalid receipt subscription.  If a push push service.  This could force the user agent to serialize subscription requests to the push service. <del> A user agent that monitors subscriptions for other clients might require multiple subscription sets.  Each subscription set can then be managed independently, which might include being moved between user agents. </del> 8. This protocol MUST use RFC2818.  This includes any communications

Reviewer comments:
I ensured that the "proxy" text in UA and AS were similar. I removed the cross-references to and added text in Section 7.5, which is specific to PS policies if it doesn't want to support multiple subscription sets. I did not call out potential UA scenarios in detail other than "monitoring on behalf" of other receivers or senders. WebPush provides a mechanism to enable proxies - but it may be better to have separate drafts that describe specific policies that use this mechanism to support scenarios such as moving between UA(s).
NAME and NAME - please review and comment.
LGTM, but I'll wait until others have commented before merging.
This works for me.

Revised text:
A user agent MAY omit the subscription set if it is unable to receive push messages in an aggregated way for the lifetime of the subscription.  This might be necessary if the user agent is  <ins> monitoring subscriptions on behalf of other push message receivers. </ins> The push service SHOULD return the same subscription set in its response, although it MAY return a new subscription set if it is unable to receive receipts in an aggregated way for the lifetime of the receipt subscription.  This might be necessary if the application server is monitoring receipt subscriptions on the behalf of other  <ins> push message senders. </ins> A push service MUST return a 400 (Bad Request) status code for requests which contain an invalid receipt subscription.  If a push push service.  This could force the user agent to serialize subscription requests to the push service.  8. This protocol MUST use RFC2818.  This includes any communications
Original text:
be completed using HTTP/1.1, where HTTP/2 is necessary, the more verbose frame format from RFC7540 is used.  2. A general model for push services includes three basic actors: a user An application server requests the delivery of a push message by sending a HTTP POST request to a push resource distributed to the <del> application server by a user agent.  The ciphertext of the push message is included in the body of the request. </del>  5.1.

Reviewer comments:
"The ciphertext of the push message is included in the body of the request." The example looks like base64 - it should be clear it's binary content ( ciphertext is not base64) If we give an example with ciphertext, it should include the extra headers. Alternative is to say "The content of the push message is included", and have a "I am walrus" example" - with a link to the encryption document for proper encrypted example. But since most implementations will require encryption - I think it's better to add the extra headers and make it clear it's binary.
I prefer the "Alternative" approach to keep the webpush examples simple and uncluttered. I will add a reference to the example in to illustrate encryption.

Revised text:
be completed using HTTP/1.1, where HTTP/2 is necessary, the more verbose frame format from RFC7540 is used. <ins> Examples do not include specific methods for push message encryption or application server authentication because the protocol does not define a mandatory system.  The examples in I-D.ietf-webpush-vapid and I-D.ietf-webpush-encryption demonstrate the approach adopted by the API for its requirements. </ins> 2. A general model for push services includes three basic actors: a user An application server requests the delivery of a push message by sending a HTTP POST request to a push resource distributed to the  <ins> application server by a user agent.  The content of the push message is included in the body of the request. </ins> 5.1.
Original text:
The push service MUST use HTTP over TLS [RFC2818] following the recommendations in [RFC7525].  The push service shares the same default port number (443/TCP) with HTTPS, but MAY also advertise the <del> IANA allocated TCP System Port 1001 using HTTP alternative services RFC7838. </del>  While the default port (443) offers broad reachability characteristics, it is most often used for web browsing scenarios For webpush scenarios, this would contribute to unnecessary radio communications to maintain the connection on battery-powered devices. <del> Advertising the alternate port (1001) allows middleboxes to optimize idle timeouts for connections specific to push scenarios with the expectation that data exchange will be infrequent. </del>  Middleboxes SHOULD comply with REQ-5 in RFC5382 which requires that "the value of the 'established connection idle-timeout' MUST NOT be <https://www.iana.org/assignments/service-names-port-numbers/service- names-port-numbers.xhtml>. <del> IANA is requested to assign the System Port number 1001 and the service name "webpush" in accordance with RFC6335. </del>  webpush 1001 

Reviewer comments:
Based on the IANA review: Update IANA Considerations to indicate the System Port 1001 is a suggestion Update inline references to 1001 to "TBD"
LGTM (I'll let you merge this one).

Revised text:
The push service MUST use HTTP over TLS [RFC2818] following the recommendations in [RFC7525].  The push service shares the same default port number (443/TCP) with HTTPS, but MAY also advertise the  <ins> IANA allocated TCP System Port (WEBPUSH-PORT) using HTTP alternative services RFC7838. </ins> While the default port (443) offers broad reachability characteristics, it is most often used for web browsing scenarios For webpush scenarios, this would contribute to unnecessary radio communications to maintain the connection on battery-powered devices.  <ins> Advertising the alternate port (WEBPUSH-PORT) allows middleboxes to optimize idle timeouts for connections specific to push scenarios with the expectation that data exchange will be infrequent. </ins> Middleboxes SHOULD comply with REQ-5 in RFC5382 which requires that "the value of the 'established connection idle-timeout' MUST NOT be <https://www.iana.org/assignments/service-names-port-numbers/service- names-port-numbers.xhtml>.  <ins> In accordance with RFC6335, it is requested that IANA assign the suggested System Port number 1001 (or another port in the System range) and the service name "webpush". </ins> webpush 1001 <ins> [[The RFC Editor is requested to remove this editorial note at publication.]] This document uses a placeholder value for a system port pending IANA assignment which needs to be replaced with the finalized value at the time of publication.  Please apply the following replacement: "WEBPUSH-PORT" --> the assigned port value for "webpush" </ins>
Original text:
provides confidentiality and integrity protection for subscriptions and push messages from external parties. <del> Applications using this protocol MUST use mechanisms that provide confidentiality, integrity and data origin authentication.  The application server sending the push message and the application on the user agent that receives it are frequently just different instances of the same application, so no standardized protocol is needed to establish a proper security context.  The distribution of subscription information from the user agent to its application server also offers a convenient medium for key agreement. </del> 8.1. The protection afforded by TLS does not protect content from the push service.  Without additional safeguards, a push service can inspect and modify the message content. <del> For its requirements, the API has adopted I-D.ietf-webpush-encryption </del>  to secure the content of messages from the push service.  Other scenarios can be addressed by similar policies.

Reviewer comments:
Ben commented in his review that the requirement for confidentiality seemed to be covered by TLS, unless the text was actually referring to e2e protections (which I believe that it was). Moving the paragraph from the introduction of S8 to the immediate subsection resolves this confusion.

Revised text:
provides confidentiality and integrity protection for subscriptions and push messages from external parties.  8.1. The protection afforded by TLS does not protect content from the push service.  Without additional safeguards, a push service can inspect and modify the message content.  <ins> Applications using this protocol MUST use mechanisms that provide end-to-end confidentiality, integrity and data origin authentication. The application server sending the push message and the application on the user agent that receives it are frequently just different instances of the same application, so no standardized protocol is needed to establish a proper security context.  The distribution of subscription information from the user agent to its application server also offers a convenient medium for key agreement. For this requirement, the API has adopted I-D.ietf-webpush-encryption </ins> to secure the content of messages from the push service.  Other scenarios can be addressed by similar policies.
Original text:
A user agent sends a POST request to its configured push service resource to create a new subscription. <del> A 201 (Created) response indicates that the a push subscription was </del>  created.  A URI for the push message subscription resource that was created in response to the request MUST be returned in the Location header field. A push service that does not support reliable delivery over intermittent network connections or failing applications on devices, forces the device to acknowledge receipt directly to the application <del> server, incurring additional power drain in order to establish (usually secure) connections to the individual application servers. </del>  Push message reliability can be important if messages contain information critical to the state of an application.  Repairing state

Reviewer comments:
This is the initial update for the Spencer Dawkins review. I'll wait to see if there are additional comments to address before merging. Editorial update to Section 7.4 Also fixed a the a nit.
Merging per Spencer's response.

Revised text:
A user agent sends a POST request to its configured push service resource to create a new subscription.  <ins> A 201 (Created) response indicates that the push subscription was </ins> created.  A URI for the push message subscription resource that was created in response to the request MUST be returned in the Location header field. A push service that does not support reliable delivery over intermittent network connections or failing applications on devices, forces the device to acknowledge receipt directly to the application  <ins> server, incurring additional power drain in order to establish and maintain (usually secure) connections to the individual application servers. </ins> Push message reliability can be important if messages contain information critical to the state of an application.  Repairing state
Original text:
application server requested message delivery.  The response headers SHOULD provide a URI for the push resource corresponding to the push message subscription in a link relation of type <del> "urn:ietf:params:push" and a URI for the receipt subscribe resource in a link relation of type "urn:ietf:params:push:receipt".  The response body is the entity body from the most recent request sent to the push resource by the application server. </del>  A user agent can also request the contents of the push message subscription resource immediately by including a RFC7240 with a MUST provide a URI for the push resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push".  This enables the user agent to differentiate <del> the source of the message.  The response headers SHOULD provide a URI for the receipt subscribe resource in a link relation of type "urn:ietf:params:push:receipt".  The response body is the entity body from the most recent request sent to the push resource by an application server. </del>  A user agent can request the contents of the push message subscription set resource immediately by including a RFC7240 with a

Reviewer comments:
LGTM, just one nit.
I think that having the push service return the link relation on requests to subscriptions (and subscription sets) is enough. I think that perhaps it was added to push messages in error.
cc NAME

Revised text:
application server requested message delivery.  The response headers SHOULD provide a URI for the push resource corresponding to the push message subscription in a link relation of type  <ins> "urn:ietf:params:push".  The response body is the entity body from the most recent request sent to the push resource by the application server. </ins> A user agent can also request the contents of the push message subscription resource immediately by including a RFC7240 with a MUST provide a URI for the push resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push".  This enables the user agent to differentiate  <ins> the source of the message.  The response body is the entity body from the most recent request sent to the push resource by an application server. </ins> A user agent can request the contents of the push message subscription set resource immediately by including a RFC7240 with a