Draft: draft-ietf-webpush-protocol

Commentary: 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 ca n't use . For instance , applications using on windows could use the same HTTP/2 connection to a server ( though I do n'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 .
Paragraph (version B):
A message delivery context that is established between the user
agent and the push service that collects multiple push message
subscriptions into a set.
Paragraph (version A):
This resource provides read and delete access for a message
subscription.  A user agent monitor using a push message
subscription.  Every push message subscription has exactly one
push resource associated with it.
Paragraph (version B):
This resource provides read and delete access for a message
subscription.  A user agent monitor-subscription using a push
message subscription.  Every push message subscription has exactly
one push resource associated with it.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
A user agent can request the contents of the push message
subscription resource immediately by including a RFC7240 with a
"wait" parameter set to "0".
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
There are minor differences between receiving push messages for a
subscription and a subscripion set.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
A user agent can request the contents of the push message
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
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
returning a 400-series status code, such as 410 (Gone).
Paragraph (version B):
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-subscription), this can be
signaled by returning a 400-series status code, such as 410 (Gone).
Paragraph (version B):
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).
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
This link relation type is used to identify a collection of push
message subscriptions.