Change:
These are the initial and incomplete changes related to the subscription set feature. One remaining gap is how a push service correlates two different subscriptions. See the for the related thread.
Overall I like how this looks. The PENDING section on how a server might know to attach new subscription requests to an existing subscription set could be resolved by requiring a client upon connecting to immediately request delivery of a notification set before asking for new subscriptions. This way the connection handler can associate the subscription set with the connection, and a server may then associate new subscriptions with the outstanding subscription set request. This could also provide a client with a way to manage 'groups' of subscription sets, since it could assume that the last subscription set it asked for is what new subscriptions on that connection will be attached to. This could be useful for the IoT use-cases where a client might want to have some input on which subscriptions are grouped together.
I was thinking even simpler for correlation: include link relation to a subscription set in the request. That allows clients to share a connection without risking the server creating a set that they can't use. For instance, applications using URL on windows could use the same HTTP/2 connection to a server (though I don't think that they do, the protocol permits, even encourages it). However, they might independently want to use push. Sharing a subscription set is not entirely practical in this case. Good point. In earlier discussions, one proposal was to pass the first subscription resource that was created (as parent) with subsequent subscription requests (children) to provide that common link between the user agent and push service. This allowed the user agent to make the decision to aggregate or not. If it did not pass a parent subscription, then the push service could not aggregate the separate subscriptions. My thought was to avoid 'special' properties on the first subscription. The subscription set ensures a clean separation between operations on aggregated and individual subscriptions. For example, the user agent can continue to GET (or poll) and DELETE individual subscriptions - including the first one. To enable the current proposal where the push service makes the decision to aggregate, there must be some form of client authentication/identification included with the subscription request in order for a push service to correlate the subscriptions. Darshak noted this in a previous message: I’m not sure how a PS can force a UA to aggregate (unless the PS somehow identifies the client based on authentication/cookie/something-else). I may be taking it out of context as "something-else", but Benjamin also commented: I'm associating one h2 connection as being one UA

Discussion:
agent and the push service and shared with the application server. All push messages are associated with a push message subscription. <ins> A message delivery context that is established between the user agent and the push service that collects multiple push message subscriptions into a set. </ins> A message sent from an application server to a user agent via a push service.

into user agents. This resource provides read and delete access for a message <del> subscription.  A user agent monitor using a push message subscription.  Every push message subscription has exactly one push resource associated with it. </del> <ins> subscription.  A user agent monitor-subscription using a push message subscription.  Every push message subscription has exactly one push resource associated with it. This resource provides read and delete access for a collection of push message subscriptions.  A user agent monitor-set for all the push message subscriptions in the set.  A link relation of type "urn:ietf:params:push:set" identifies a push message subscription set. </ins> A push resource is used by the application server to request the delivery of a push message (see send).  A link relation of type

ensure that these URIs are not disclosed to unauthorized recipients (see authorization). <ins> The push service MAY provide a URI for a subscription set resource in a link relation of type "urn:ietf:params:push:set".  If provided, the push service supports subscription sets.  If available, the user agent SHOULD use the subscription set to receive push messages rather than individual push message subscriptions. The push service MAY return new subscription sets in response to different subscription requests from the same user agent.  This allows the push service to control the grouping of the push message subscriptions. 3.1. PENDING: Discuss how two different subscriptions are correlated based on either authentication or connection </ins> 4. An application server requests the creation of a receipt subscription

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 by the push service when the application server requested message delivery.  The response body is the entity body from the most recent request sent to the push resource. </del> <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 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 "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. A user agent can also request the contents of the push message subscription resource immediately by including a RFC7240 with a "wait" parameter set to "0".  In response to this request, the push service MUST generate a server push for all push messages that have not yet been delivered. A 204 (No Content) status code with no associated server pushes indicates that no messages are presently available.  This could be because push messages have expired. 6.1. </ins> <del> In response to this request, the push service 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 and receipt subscribe resources. </del> <ins> There are minor differences between receiving push messages for a subscription and a subscripion set. A user agent requests the delivery of new push messages for a collection of push message subscriptions by making a GET request to a push message subscription set resource.  The push 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. 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 application server requested message delivery.  The synthetic request 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 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. </ins> A user agent can request the contents of the push message <del> subscription resource immediately by including a RFC7240 with a "wait" parameter set to "0". </del> <ins> subscription set resource immediately by including a RFC7240 with a "wait" parameter set to "0".  In response to this request, the push service MUST generate a server push for all push messages that have not yet been delivered. </ins> A 204 (No Content) status code with no associated server pushes indicates that no messages are presently available.  This could be because push messages have expired. <del> 6.1. </del> <ins> 6.2. </ins> To ensure that a push message is properly delivered to the user agent at least once, the user agent MUST acknowledge receipt of the message

failure response to the application server monitoring the receipt subscription resource. <del> 6.2. </del> <ins> 6.3. </ins> The application server requests the delivery of receipts from the push service by making a HTTP GET request to the receipt subscription

instead uses RFC7540 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 created by the push service when the application server requested message delivery.  A successful response includes a 410 (GONE) status code with no data. </del> <ins> Each receipt is pushed as the response to a synthesized GET request sent in a PUSH_PROMISE.  This GET request is made to the same push message resource that was created by the push service when the application server requested message delivery.  A successful response includes a 410 (GONE) status code with no data. </ins> If the user agent fails to acknowledge the receipt of the push message and the push service ceases to retry delivery of the message

A push service can remove a subscription at any time.  If a user agent or application server has an outstanding request to a <del> subscription resource (see monitor), this can be signaled by returning a 400-series status code, such as 410 (Gone). </del> <ins> subscription resource (see monitor-subscription), this can be signaled by returning a 400-series status code, such as 410 (Gone). </ins> A user agent or application server can request that a subscription be removed by sending a DELETE request to the push message subscription

Found) or 410 (Gone) if an application server attempts to send a push message to a removed or expired push message subscription. <ins> 7.3.1. A push service MAY expire a subscription set at any time which MUST also expire all push message subscriptions in the set.  If a user agent has an outstanding request to a push subscription set (see monitor-set) this can be signaled by returning a 400-series status code, such as 410 (Gone). A user agent can request that a subscription set be removed by sending a DELETE request to the subscription set URI.  This MUST also remove all push message subscriptions in the set. If a specific push message subscription that is a member of a subscription set is expired or removed, then it MUST also be removed from its subscription set. </ins> 7.4. A push service that does not support reliable delivery over

transient (e.g. an incoming call) or messages that are quickly superceded (e.g. the current number of unread emails). <ins> 7.5. If the push service requires that the user agent use push message subscription sets, then it MAY limit the number of concurrently active streams with the SETTINGS_MAX_CONCURRENT_STREAMS parameter within a HTTP/2 SETTINGS frame RFC7540.  The user agent MAY be limited to one concurrent stream to manage push message subscriptions and one concurrent stream for each subscription set returned by the push service.  This could force the user agent to serialize subscription requests to the push service. </ins> 8. This protocol MUST use RFC2818.  This includes any communications

The Web Push WG (webpush@ietf.org) <del> urn:ietf:params:push:receipt </del> <ins> urn:ietf:params:push:set This link relation type is used to identify a collection of push message subscriptions. (this document) The Web Push WG (webpush@ietf.org) urn:ietf:params:push:receipts </ins> This link relation type is used to identify a resource for creating new push message receipt subscriptions.