Subject: [Webpush] Subscription Sets - Pull Request

From: Brian Raymor <[email-masked]>
Date: Thu, 22 Oct 2015 21:16:20 +0000

I've started a pull request for subscription sets for discussion at IETF 94 - https://github.com/webpush-wg/webpush-protocol/pull/53 - I'd appreciate any early feedback prior to the meeting. The main open issue is how to correlate two different subscriptions.

The pull request is based on the earlier proposal from IETF 93 - http://www.ietf.org/mail-archive/web/webpush/current/msg00272.html - and subsequent related issues - https://github.com/webpush-wg/webpush-protocol/issues?q=is%3Aopen+is%3Aissue+label%3A%22subscription+sets%22

...Brian

---

From: Benjamin Bangert <[email-masked]>
Date: Fri, 23 Oct 2015 14:24:39 -0700

-- copying my comments on the github PR here

Why is the receipt URL now included on every PUSH message frame? The client
should already know the receipt URL from the original subscription request,
no?

re: SHOULD for using subscription set URL vs. subscription URL

Could this be 'MUST'? Here's my rationale for why. If its should, then I
must maintain multiple indexes on every message for a subscription set. One
for the subscription URL, and one for the subscription set. At scale, this
is extremely expensive. I planned on dumping all notifications to the same
subscription set, into a single bucket. If I need to provide access based
on the subscription URL separate from the set URL, then I'll need an
additional index.
As an additional gotcha if its SHOULD, a client may ask for a subscription
set and an individual subscription in the set at the same time, which could
result in some odd situations where its likely the client will get dupes of
messages since the server could dump what it has under both overlapping
concerns before any ack's are received.

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.
Martin points out that this could also be handled by having a client
include a subscription set in the request. I like that approach as well.

Cheers,
Ben

On Thu, Oct 22, 2015 at 2:16 PM, Brian Raymor <[email-masked]>
wrote:

>
>
> I’ve started a pull request for subscription sets for discussion at IETF
> 94 - https://github.com/webpush-wg/webpush-protocol/pull/53 - I’d
> appreciate any early feedback prior to the meeting. The main open issue is
> how to correlate two different subscriptions.
>
>
>
> The pull request is based on the earlier proposal from IETF 93 -
> http://www.ietf.org/mail-archive/web/webpush/current/msg00272.html - and
> subsequent related issues -
> https://github.com/webpush-wg/webpush-protocol/issues?q=is%3Aopen+is%3Aissue+label%3A%22subscription+sets%22
>
>
>
>
>
> …Brian
>
>
>
>
>
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>
>

---

From: Brian Raymor <[email-masked]>
Date: Fri, 23 Oct 2015 22:14:50 +0000

On October 23 2015 at 2:25 PM, Benjamin Bangert <[email-masked]> wrote:

> Could this be 'MUST'? 

Martin remembered that we discussed a redirect in Prague:
  https://github.com/webpush-wg/webpush-protocol/issues/55. 

I'll update the pull request. 

> 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. 

That sounds like the registration step that we eliminated prior to publishing -00. As you've
suggested on list, the correlator could be the connection. It could also be some form of 
authentication. This may be dependent on the push service implementation.

> Martin points out that this could also be handled by having a client include a subscription
> set in the request. I like that approach as well.

We initially considered this approach in Prague, but discovered that it's fragile. For example, what happens if the client does not include the required subscription set link?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 23 Oct 2015 15:16:59 -0700

> We initially considered this approach in Prague, but discovered that it's fragile. For example, what happens if the client does not include the required subscription set link?

I don't think that's fragility, that's a feature.  If the server
thinks that a user agent is acting badly and not including these
links, it can (and should) limit the number of subscriptions it is
willing to create on a given connection.

---

From: Benjamin Bangert <[email-masked]>
Date: Fri, 23 Oct 2015 16:49:48 -0700

If the client fails to include it, then the server will make a new
subscription set. It's the clients problem that the simultaneous stream
limit is going to restrict it to listening to a single subscription set at
a time if it wants a free command channel.

On Fri, Oct 23, 2015 at 3:16 PM, Martin Thomson <[email-masked]>
wrote:

> > We initially considered this approach in Prague, but discovered that
> it's fragile. For example, what happens if the client does not include the
> required subscription set link?
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 23 Oct 2015 20:17:19 -0700

That's true, if the server is using limited concurrency, then the
client will suffer for forgetting.  I think that the answer here is as
we already have: a very strong recommendation to do what is necessary
to reuse subscription sets.

On 23 October 2015 at 16:49, Benjamin Bangert <[email-masked]> wrote:
> limit is going to restrict it to listening to a single subscription set at a
> time if it wants a free command channel.
>

---

From: Darshak Thakore <[email-masked]>
Date: Wed, 28 Oct 2015 02:30:14 +0000

I like the idea of keeping it as a strong recommendation instead of
mandating. 
There might be legitimate use cases (in IoT) where the client may want
multiple subscription sets.

Darshak