jiebi/TextFlow huggingface dataset:
Original text:
application server by a user agent.  The push message is included in the body of the request. <del> A push service MAY generate a 413 (Payload Too Large) status code in response to requests that include an entity body that is too large. Push services MUST NOT generate a 413 status code in responses to an entity body that is 4k (4096 bytes) or less in size. </del>  5.1.

Reviewer comments:
Looks good aside from that one thing, the resolution of which I'll leave to your discretion.
As discussed in cc NAME The earlier proposal from JR - URL - was to include a reference to 429 with Retry-Header: URL The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting"). The response representations SHOULD include details explaining the condition, and MAY include a Retry-After header indicating how long to wait before making a new request. For example: HTTP/1.1 429 Too Many Requests Content-Type: text/html Retry-After: 3600 Would this address your requirements? ...Brian

Revised text:
application server by a user agent.  The push message is included in the body of the request.  <ins> A push service MAY return a 429 (Too Many Requests) status code RFC6585 when an application server has exceeded its rate limit for push message delivery to a push resource.  The push service SHOULD also include a Retry-After header RFC7231 to indicate how long the application server is requested to wait before it makes another request to the push resource. A push service MAY return a 413 (Payload Too Large) status code RFC7231 in response to requests that include an entity body that is too large.  Push services MUST NOT return a 413 status code in responses to an entity body that is 4k (4096 bytes) or less in size. </ins> 5.1.
Original text:
4.1. <del> PENDING: Discuss how two different subscriptions are correlated based on either authentication or connection </del>  5.

Reviewer comments:
This replaces the PENDING section on correlation. I know that NAME wanted to simply rely on ambient authority of some sort, but I think that this is the cleanest option. It doesn't cost us anything significant either.
Does the PS return the push:set with each subscribe response or just the first one? If returned in all cases, can the push:set change between responses? If so, does the UA MUST use the latest one? For a PS that wants to strongly require aggregation - besides using concurrent stream limits - can it return an error if the push:set is not included?
Good questions, both of them, I'll add a commit that answers them (rather than answer them in these comments).
Answers provided (more words added)...

Revised text:
4.1.  <ins> The aggregation of multiple subscriptions into a subscription set can represent a significant efficiency improvement for a push service. For that reason, if a subscription set is available, a user agent MUST indicate an existing subscription set in a request to create a subscription.  However, a user agent MAY omit the subscription set if it is unable to receive push messages that are aggregated for the lifetime of the subscription.  This might be necessary if the user agent is forwarding requests from other clients. The user agent adds a subscription set link relation to the request to create a subscription.  This indicates which subscription set the subscription is to be bound to. This gives the push service the option to create a subscription within an existing subscription set.  The push service returns the same subscription set in the response, though it MAY use a new subscription set if it is unable to reuse the provided one. A push service MAY reject a request if it contains an unknown or invalid subscription set, or a request that does not include a subscription set.  An 429 status code can be used to indicate that too many requests to create subscriptions sets were made. How a push service detects that requests come from the same user agent is implementation-dependent and could take ambient information into consideration, such as the TLS connection, source IP address and port.  Implementers are reminded that using some heuristics can produce false positives and cause requests to be rejected incorrectly. </ins> 5.
Original text:
A push service MAY expire a subscription set at any time and MUST also expire all push message subscriptions in the set.  If a user agent has an outstanding request to a push subscription set (monitor- <del> set) this can be signaled by returning a 400-series status code, such as 410 (Gone). </del>  A user agent can request that a subscription set be removed by sending a DELETE request to the subscription set URI.  This MUST also

Reviewer comments:
As suggested by NAME
Thanks to all for the discussion, I was lazy and missed the MUST 404 on the section above.
The language for subscription and subscription sets is still a bit asymmetical. I'll merge this PR and make the subsequent edits. For example can remove versus MAY expire ...

Revised text:
A push service MAY expire a subscription set at any time and MUST also expire all push message subscriptions in the set.  If a user agent has an outstanding request to a push subscription set (monitor-  <ins> set) this can be signaled by returning a 404 (Not Found) status code. </ins> A user agent can request that a subscription set be removed by sending a DELETE request to the subscription set URI.  This MUST also
Original text:
As a consequence of the expected deployment architecture, there is no basis for an application server to be known to a push service prior <del> to requesting delivery of a push message.  By the same measure, requesting the creation of a subscription for push message receipts has no prior authentication.  Requiring that the push service be able to authenticate application servers places an unwanted constraint on the interactions between user agents and application servers, who are the ultimate users of a push service.  That constraint would also degrade the privacy-preserving properties the protocol provides.  For these reasons, I-D.ietf-webpush-protocol does not define a mandatory system for authentication of application servers. </del>  An unfortunate consequence of this design is that a push service is exposed to a greater risk of denial of service attack.  While

Reviewer comments:
This closes but does not completely address ?
You mean that I missed yes, I missed that on my first check. Let me know if you find anything else. (I haven't used the header field in the example to concentrate on the important bits.)
Introduction By the same measure, requesting the creation of a subscription for push message receipts has no prior authentication. In webpush-05, there is no longer an explicit request to create such a subscription. It's created implicitly as the result of requesting a push message delivery with receipts. Example In webpush-05, this changes to: and a reference to RFC7240 added.

Revised text:
As a consequence of the expected deployment architecture, there is no basis for an application server to be known to a push service prior  <ins> to requesting delivery of a push message.  Requiring that the push service be able to authenticate application servers places an unwanted constraint on the interactions between user agents and application servers, who are the ultimate users of a push service. That constraint would also degrade the privacy-preserving properties the protocol provides.  For these reasons, I-D.ietf-webpush-protocol does not define a mandatory system for authentication of application servers. </ins> An unfortunate consequence of this design is that a push service is exposed to a greater risk of denial of service attack.  While
Original text:
2. <del> Application servers SHOULD generate and maintain a signing key pair usable with elliptic curve digital signature (ECDSA) over the P-256 curve FIPS186.  Use of this key when sending push messages establishes a continuous identity for the application server. </del>  When requesting delivery of a push message, the application includes a JSON Web Token (JWT) RFC7519, signed using its signing key.  The

Reviewer comments:
1 Application Server Self-Identification Application servers SHOULD generate and maintain a signing key pair usable with elliptic curve digital signature (ECDSA) over the P-256 curve [FIPS186]. What is the rationale for SHOULD rather than MUST?

Revised text:
2.  <ins> Application servers that wish to self-identity generate and maintain a signing key pair.  This key pair MUST be usable with elliptic curve digital signature (ECDSA) over the P-256 curve FIPS186.  Use of this key when sending push messages establishes an identity for the application server that is consistent across multiple messages. </ins> When requesting delivery of a push message, the application includes a JSON Web Token (JWT) RFC7519, signed using its signing key.  The
Original text:
JWT with the header and body shown in ex-jwt.  This JWT would be valid until 2016-01-21T01:53:25Z RFC3339. <del> The first part of the JWT is effectively fixed.  Would be it acceptable to require that that segment is omitted from the header field? </del> 3. A new "WebPush" HTTP authentication scheme RFC7235 is defined.  This

Reviewer comments:
What is "that segment"?
Optimizations, like dropping the header segment, tend to be problematic for some implementers, particularly since the final signature is derived from the first two segments. Also, dropping the header segment prevents possible future changes for encryption types, versioning, or other potentially required items.
Agreed. I was requesting clarification because it was unclear what omission was being proposed. For example, if it was the header, then that would be a problem because states that the alg parameter MUST be present and MUST be understood and processed by implementations.
I'll confirm with the list, but NAME is right here. We can pay a little extra here. It will mean that there is some possibility of variation in the header (whitespace), but we know how to do that.

Revised text:
JWT with the header and body shown in ex-jwt.  This JWT would be valid until 2016-01-21T01:53:25Z RFC3339.  3. A new "WebPush" HTTP authentication scheme RFC7235 is defined.  This
Original text:
When a push subscription has been associated with an application server, the request for push message delivery MUST include proof of <del> possession for the associated private key or token that was used when creating the push subscription. </del>  A push service MUST reject a message that omits mandatory credentials with a 401 (Unauthorized) status code.  A push service MAY reject a the public key used to sign the JWT doesn't match the one that was included in the creation of the push message. <del> A push subscription that is not restricted to a particular key MAY still validate a token that is present, except for the last check.  A push service MAY then reject a request if the token is found to be invalid. </del> In theory, since the push service was given a public key, the push message request could omit the public key.  On balance, requiring the key keeps things simple and it allows push services to

Reviewer comments:
This was either in error, or could refer to "JWT" instead.
There are multiple references to a token that are unclear: ...
The first is just a mistake; a relic of a previous version. It can be removed. The second refers to JWT. I'll fix that.

Revised text:
When a push subscription has been associated with an application server, the request for push message delivery MUST include proof of  <ins> possession for the associated private key that was used when creating the push subscription. </ins> A push service MUST reject a message that omits mandatory credentials with a 401 (Unauthorized) status code.  A push service MAY reject a the public key used to sign the JWT doesn't match the one that was included in the creation of the push message.  In theory, since the push service was given a public key, the push message request could omit the public key.  On balance, requiring the key keeps things simple and it allows push services to
Original text:
2.2.  An application server requests the delivery of a push message as described in I-D.ietf-webpush-protocol.  If the application server wishes to self-identify, it includes an Authorization header field

Reviewer comments:
LGTM, thank you! Is the addition required because of the following language in 7519?
Well, that's a good reason, but is the main reason. See the discussion leading up to that.
I read the thread and issue; reading JWT, there was nothing prohibiting providing additional fields (aside from that SHOULD), so I was wondering if specifying this is a normative requirement or a good clarification :-).
If I may, clarification is always good. One should presume that the readers of these specs may not be fully versed in the subtle details of other, reliant specs, so a bit of useful info like this might be very welcome.
As noted in the arguments of , there is a need for an "extra data" field which would be used by the parties using the VAPID claims. This data would contain information useful to the publisher of the claim (e.g. the originating server ID, transaction ID, or other possibly VAPID consumer opaque data). This extra data ("vapid-ext" ?) field would allow consistent, predictable definition rather than a set of 'one-offs' that may be difficult to find or ignored by operators.
Started thread: URL JR requests that we allow the inclusion of extra stuff in a vapid token: URL field which would be used by the parties using the VAPID claims. This data would contain information useful to the publisher of the claim (e.g. the originating server ID, transaction ID, or other possibly VAPID consumer opaque data). This extra data ("vapid-ext" ?) field would allow consistent, predictable definition rather than a set of 'one-offs' that may be difficult to find or ignored by operators. <<< I think that the general idea is fine. Better this than trying to pack the "sub" field with extra stuff. JR, would it suffice to point out that the (or even ) claims can be added to the token? Allowing multiple fields gives the application server a fair bit more flexibility. If that's OK, we should point out that this is possible so that push services don't lose the extra data because they aren't aware that it might exist.

Revised text:
2.2. <ins> An application server MAY include additional claims using public or private names (see Sections 4.2 and 4.3 of RFC7519).  Since the JWT is in a header field, the size of additional claims SHOULD be kept as small as possible. 2.3. </ins> An application server requests the delivery of a push message as described in I-D.ietf-webpush-protocol.  If the application server wishes to self-identify, it includes an Authorization header field
Original text:
this authentication scheme. This authentication scheme is intended for use by an application <del> server when using the webpush protocol I-D.ietf-webpush-protocol, but it could be used in other contexts if applicable. </del>  4.

Reviewer comments:
attn: NAME
Thanks !
From NAME authenticated with VAPID, all subsequent subscribe, unsubscribe, ack or monitor requests associated with the same pushset MUST be authenticated with VAPID with same public key" already needs to have code to handle EC for the e2e encryption. The main concern is an attacker 'acking' or unsubscribing - since the messages are e2e encrypted they can't read it.
This looks good to me.

Revised text:
this authentication scheme. This authentication scheme is intended for use by an application  <ins> server when using the Web Push protocol I-D.ietf-webpush-protocol, but it could be used in other contexts if applicable. </ins> 4.
Original text:
4.6. <del> Both Simulcast RFC8853 and Scalable Video Coding (SVC), including K-SVC (also known as "S modes", in which multiple encodings are sent on the same SSRC), MAY be supported by both the Media Servers and WHIP clients through negotiation in the SDP offer/answer. </del>  If the client supports simulcast and wants to enable it for publishing, it MUST negotiate the support in the SDP offer according simulcast offer MUST create an answer according to the procedures RFC8853 section 5.3.2.  4.7. In order to support future extensions to be defined for the WHIP

Reviewer comments:
From NAME Simulcast and scalable video coding Both Simulcast [RFC8853] and Scalable Video Coding (SVC), including K-SVC (also known as "S modes", in which multiple encodings are sent on the same SSRC), MAY be supported by both the Media Servers and WHIP clients through negotiation in the SDP offer/answer. [BA] K-SVC and “S” modes are different. K-SVC denotes the KEY and KEY_SHIFT modes, whereas “S” modes denote the encapsulation of multiple encodings within a single SSRC, as is supported in VP9 and AV1. Diagrams of the various modes are included in the WebRTC-SVC specification: URL Also, SVC is not negotiated within Offer/Answer in WebRTC. It is something that the encoder can just turn on. At least for temporal modes (L1T2, L1T3) ingester support can often be taken for granted. While the VP9 and AV1 specifications require a compliant decoder to be able to decode any mode than an encoder can encode, in practice there are VP9 and AV1 hardware decoders that cannot decode spatial scalability because they do not support spatial references (e.g. a P-frame at a higher resolution than the P or I frame that it references). This nasty little “wrinkle” required us to define the “spatialScalability” attribute in Media Capabilities, to allow applications to discover whether a (hardware) decoder supports spatial scalability or not: Media Capabilities URL Not sure if you want to get into this in the specification. Issues are most likely to be encountered where hardware-based transcoders are used (but in that scenario, spatial scalability probably wouldn’t be relevant anyway),

Revised text:
4.6.  <ins> Simulcast as per RFC8853 MAY be supported by both the Media Servers and WHIP clients through negotiation in the SDP offer/answer. </ins> If the client supports simulcast and wants to enable it for publishing, it MUST negotiate the support in the SDP offer according simulcast offer MUST create an answer according to the procedures RFC8853 section 5.3.2. <ins> It is possible for both Media Servers and WHIP clients to support Scalable Video Coding (SVC).  However, as there is no universal negotiation mechanism in SDP for SVC, the encoder must consider the negotiated codec(s), intended usage, and SVC support in available decoders when configuring SVC. </ins> 4.7. In order to support future extensions to be defined for the WHIP
Original text:
Abstract <del> While WebRTC has been very successful in a wide range of scenarios, </del>  its adoption in the broadcasting/streaming industry is lagging behind.  Currently there is no standard protocol (like SIP or RTSP) <del> designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it. These protocols are much older than webrtc and lack by default some important security and resilience features provided by webrtc with minimal delay. The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node, introducing delay and degrading media quality.  This transcoding step is always present in traditional streaming to support e.g.  ABR, and comes at no cost.  However webrtc implements client-side ABR, also called Network-Aware Encoding by e.g.  Huavision, by means of simulcast and SVC codecs, which otherwise alleviate the need for server-side transcoding.  Content protection and Privacy Enhancement can be achieved with End-to-End Encryption, which preclude any server-side media processing. </del>  This document proposes a simple HTTP based protocol that will allow <del> WebRTC endpoints to ingest content into streaming services and/or CDNs to fill this gap and facilitate deployment. </del>  1.

Reviewer comments:
I'd like to propose removing the mention of a specific company/brand in the abstract as well as some clarification around the language used to describe the protocol and why it is important/different from "other protocols".

Revised text:
Abstract  <ins> While WebRTC has been very sucessful in a wide range of scenarios, </ins> its adoption in the broadcasting/streaming industry is lagging behind.  Currently there is no standard protocol (like SIP or RTSP)  <ins> designed for ingesting media into a streaming service using WebRTC and so content providers still rely heavily on protocols like RTMP for it. These protocols are much older than WebRTC and by default lack some important security and resilience features provided by WebRTC with minimal overhead and additional latency. The media codecs used for ingestion in older protocols tend to be limited and not negotiated.  WebRTC includes support for negotiation of codecs, potentially alleviating transcoding on the ingest node (wich can introduce delay and degrade media quality).  Server side transcoding that has traditionally been done to present multiple renditions in Adaptive Bit Rate Streaming (ABR) implementations can be replaced with simulcasting and SVC codecs that are well supported by WebRTC clients.  In addition, WebRTC clients can adjust client- side encoding parameters based on RTCP feedback to maximize encoding quality. Encryption is mandatory in WebRTC, therefore secure end-to-end transport of media is implicit. </ins> This document proposes a simple HTTP based protocol that will allow  <ins> WebRTC based ingest of content into streaming servics and/or CDNs. </ins> 1.
Original text:
sending a 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 with the new ICE candidate or ICE <del> ufrag/pwd for ICE restarts.  A WHIP resource MAY not support trickle ICE (i.e.  ICE lite media servers) or ICE restart, in that case, it MUST return a 405 Method Not Allowed response for any HTTP PATCH request. </del>  As the HTTP PATCH request sent by a WHIP client may be received out of order by the WHIP resource, the WHIP resource MUST generate a

Reviewer comments:
While this is not ambiguous, it might be read as "MAY NOT". I suggest rewording as "Support for trickle ICE by WHIP resources is OPTIONAL".
NAME wdyt? is it ok to merge it and will this solve your concerns?
Yes, that's much better.

Revised text:
sending a 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 with the new ICE candidate or ICE  <ins> ufrag/pwd for ICE restarts. Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource. If Trickle ICE or ICE restarts are not supported by the WHIP resource, it MUST return a 405 Method Not Allowed response for any HTTP PATCH request. </ins> As the HTTP PATCH request sent by a WHIP client may be received out of order by the WHIP resource, the WHIP resource MUST generate a