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

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