jiebi/CodeConvo huggingface dataset:
Change:
"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.

Discussion:
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 <del> application server by a user agent.  The ciphertext of the push message is included in the body of the request. </del> <ins> application server by a user agent.  The content of the push message is included in the body of the request. </ins> 5.1.
Change:
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).

Discussion:
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> <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. <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> <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>. <del> IANA is requested to assign the System Port number 1001 and the service name "webpush" in accordance with RFC6335. </del> <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>
Change:
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.

Discussion:
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> <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.
Change:
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.

Discussion:
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> <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 <del> server, incurring additional power drain in order to establish (usually secure) connections to the individual application servers. </del> <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
Change:
Removed references to HTTP cache headers and RFC7234
LGTM
Tracking Darshak Thakore feedback: There was ambiguity about the type of "expiration information" returned: Also I'm assuming here that the "expiration information" refers to the expiration info of the push messages (i.e their TTL), correct? NAME has added a small clarification: URL but an example should be developed.
As discussed on the , the use of HTTP cache headers for graceful subscription expiration was deprecated. Our implementation is currently only reactive when it comes to subscription expiration. That means that we tolerate a break if the server is forced to expire a subscription. Note that the discussion from before was all predicated on a different design, one where individual subscriptions were subjugate to a larger "registration". The current design, even the with the addition of subscription sets, doesn't suffer from the ambiguity problem you described. However, after reviewing the HTTP cache control stuff in more detail, I think that it might be best to remove this feature. The use case (graceful replacement of a subscription), might be important, but I don't think that using response freshness as a proxy for subscription lifetime is correct. If we discover that there is a need, I think that an alternative mechanism will be required. A more direct signal an explicit "refresh now" message - might be a superior option. The consequence of that is that we will rely on the 4xx responses to inform user agents of when the push service has expired a subscription. For the moment, that's probably OK. The consequential drop in reliability should be low.

Discussion:
In response to this request, the push server MUST generate a server push for all push messages that have not yet been delivered.  In addition, the push service SHOULD return link references to the push <del> and receipt subscribe resources, plus expiration information for the subscription. </del> <ins> and receipt subscribe resources. </ins> A user agent can request the contents of the push message subscription resource immediately by including a RFC7240 with a

they can be refreshed.  This applies to both push message subscriptions and receipt subscriptions. <del> A push service might choose to set a fixed expiration time.  If a resource has a known expiration time, expiration information is included in responses to requests that create the resource, or in requests that retrieve a representation of the resource. Expiration is indicated using either the Expires header field, or by setting a "max-age" parameter on a Cache-Control header field (see RFC7234).  The Cache-Control header field MUST also include the "private" directive. </del> A push service can remove a subscription at any time.  If a user agent or application server has an outstanding request to a subscription resource (see monitor), this can be signaled by
Change:
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

Discussion:
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> <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 <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> <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
Change:
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

Discussion:
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> <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.
Change:
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)...

Discussion:
4.1. <del> PENDING: Discuss how two different subscriptions are correlated based on either authentication or connection </del> <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.
Change:
Should we include a reference to URL - perhaps in Acknowledgements?
I don't care about acknowledgments for -nice. But I do care about the issues that I raised on the list.

Discussion:
6.3. <ins> For a device that is battery-powered, it is often critical that it remains dormant for extended periods.  Radio communication in particular consumes significant power and limits the length of time that the device can operate. To avoid consuming resources to receive trivial messages, it is helpful if an application server can communicate the urgency of a message and if the user agent can request that the push server only forward messages of a specific urgency. An application server MAY include an Urgency header field in its request for push message delivery.  This header field indicates the message urgency.  The push service MUST not forward the Urgency header field to the user agent.  A user agent MAY include the Urgency header field when requesting push messages to indicate that it only wants to receive messages at an equal or greater urgency. An absent Urgency header field indicates that the request is to be forwarded at "normal" urgency.  Multiple values for the header field MUST NOT be included in requests; otherwise, the push service MUST return a 400 (Bad Request) status code. 6.4. </ins> A push message that has been stored by the push service can be replaced with new content.  If the user agent is offline during the time that the push messages are sent, updating a push message avoids

send the contents of push messages as they are sent by application servers. <ins> A user agent MAY include a Urgency header field in its request.  The push service MUST only deliver messages with an urgency greater than or equal to the value of the header field as defined in the urgency_values. </ins> Each push message is pushed as the response to a synthesized GET request in a PUSH_PROMISE.  This GET request is made to the push message resource that was created by the push service when the

respond to this request, it instead uses RFC7540 to send the contents of push messages as they are sent by application servers. <ins> A user agent MAY include a Urgency header field in its request.  The push service MUST only deliver messages with an urgency greater than or equal to the value of the header field as defined in the urgency_values. </ins> Each push message is pushed as the response to a synthesized GET request sent in a PUSH_PROMISE.  This GET request is made to the push message resource that was created by the push service when the
Change:
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 ...

Discussion:
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> <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
Change:
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.

Discussion:
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> <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
Change:
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?

Discussion:
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> <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
Change:
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.

Discussion:
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