Original text:
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>  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

Reviewer comments:
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.

Revised text:
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  <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.  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