Subject: Re: [Webpush] Non-blocking comments on -05

From: RUELLAN Herve <[email-masked]>
Date: Wed, 1 Jun 2016 11:46:14 +0000

Hello everyone,

I also have some comments on the spec, none of which are blocking for the WGLC.

I also generated a pull-request for editorial things:
https://github.com/webpush-wg/webpush-protocol/pull/93

And another one for changing the URIs used in the examples and making them more explicit (which I think is helpful for a first-time reader of the spec):
https://github.com/webpush-wg/webpush-protocol/pull/94

1. Some of the URNs used may be confusing. Renaming them could help make things clearer.

The push message subscription set URN, "urn:ietf:params:push:set", could be changed to "urn:ietf:params:push:sub:set", to better show it is related to push message subscription resources and not directly to push resources.

The receipt subscription URN, "urn:ietf:params:push:receipt", could be changed to "urn:ietf:param:push:receipt:sub", to better show it corresponds to a receipt *subscription* resource and not to a receipt resource (even if these don't exist).

2. What does a push server that receives a request for a push message with "Prefer: respond-async" but doesn't want to provide a receipt subscription, or doesn't support providing receipts? Is this allowed in the first place?

3. Adds in 5.1 a paragraph similar to the third one of 4.1 (containing some modifications from my editorial pull-request):

An application server MAY omit the receipt subscription if it is unable to receive receipts in an aggregated way for the lifetime of the push messages. This might be necessary if the application server is forwarding push messages from other servers.

4. In 5.4, replace:

A 201 (Created) response indicates...

with:

A 201 (Created) response or a 202 (Accepted) response indicates...

5. In 6, in the last paragraph (and similarly in 6.1), replace:

A 204 (No Content) status code with no associated server pushes...

with:

A 204 (No Content) status code sent in response to the initial request with no associated server pushes...

6. In 6.1, maybe emphasize the difference on the location of the link header (PUSH_PROMISE vs response) and give some reason for this difference.

7. In 6.3, what is the status code for a message not successfully delivered at its expiration time?

8. The draft is not clear on how GET to subscription resources (or subscription set) are handled. It is stated that the push service does not respond to this request. However the last paragraph of 6 tells about using a 204 (No Content) status code when no messages are available, and this is stated again by paragraph 4 of 7.2. Is it only for the case when "Prefer: wait=0" header field is used? Or can the push server use it to close the connection?

9. In 7.5, add a paragraph for the client proxying scenario:

It should be noted that some user agent might need to use several subscription sets if they are forwarding subscription requests from other servers.

Thanks for all the work on the spec,

Hervé

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Jun 2016 22:56:49 +1000

On 1 June 2016 at 13:42, Brian Raymor <[email-masked]> wrote:
> There was some early discussion in https://github.com/webpush-wg/webpush-protocol/issues/24.
>
> There were no major objections at the time. It just felt odd to have a special case for TTL=0 in comparison to TTL=1.

That's right, I remember now.  Costin has said as much on the PR that
I generated.  If Peter is OK with this explanation, I will just close
the PR.

---

From: Peter Beverloo <[email-masked]>
Date: Wed, 1 Jun 2016 14:01:17 +0100

On Wed, Jun 1, 2016 at 1:56 PM, Martin Thomson <[email-masked]>
wrote:

> > There was some early discussion in
> https://github.com/webpush-wg/webpush-protocol/issues/24.
> >
> > There were no major objections at the time. It just felt odd to have a
> special case for TTL=0 in comparison to TTL=1.
>

I will defer to Costin— no-change resolution works for me.

Thanks,
Peter

---

From: Costin Manolache <[email-masked]>
Date: Wed, 01 Jun 2016 14:43:12 +0000

If  encoding what is needed for receipt in the message ID works for other
implementations,
I think we should keep it. I agree that requiring storage for TTL=0 defeats
the
purpose, ttl=0 should be the fastest and lowest cost way to deliver a
message.

In GCM we do send receipts for TTL=0, but it's easy to disable them for
webpush.

Costin

On Wed, Jun 1, 2016 at 6:01 AM Peter Beverloo <[email-masked]> wrote:

> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>

---

From: Brian Raymor <[email-masked]>
Date: Wed, 1 Jun 2016 23:34:51 +0000

Herve,

Thanks for all the feedback and suggestions. Here are some partial responses.

> https://github.com/webpush-wg/webpush-protocol/pull/94

Comments in https://github.com/webpush-wg/webpush-protocol/pull/94#issuecomment-223152708

> The push message subscription set URN, "urn:ietf:params:push:set", could be changed to "urn:ietf:params:push:sub:set",
> to better show it is related to push message subscription resources and not directly to push resources.

> The receipt subscription URN, "urn:ietf:params:push:receipt", could be changed to "urn:ietf:param:push:receipt:sub",
> to better show it corresponds to a receipt *subscription* resource and not to a receipt resource (even if these don't exist).

I don't have strong feelings about making this change now. I'll wait to see if there's further support on the mailing list.

> 2. What does a push server that receives a request for a push message with "Prefer: respond-async"
> but doesn't want to provide a receipt subscription, or doesn't support providing receipts? Is this allowed in the first place?

The push service is required to support receipt subscriptions.

   The push service MUST also provide a URI for the receipt
    subscription resource in a link relation of type
  "urn:ietf:params:push:receipt".

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Jun 2016 12:13:39 +1000

> 2. What does a push server that receives a request for a push message with "Prefer: respond-async" but doesn't want to provide a receipt subscription, or doesn't support providing receipts? Is this…

This is handled in RFC7240.  It ignores the Prefer header.  I believe
that existing implementations do this very well :)

---

From: Kit Cambridge <[email-masked]>
Date: Thu, 2 Jun 2016 00:01:32 -0700

Hi all,

First, I'd like to echo Peter's "thank you". I'm very grateful for all your work in putting this standard together and marshaling feedback, here and on GitHub! In addition to the comments from Peter, JR, and Hervé, I have a few questions and suggestions. None of them block the WGLC.

In section 4.1, I'm not clear what "unable to receive push messages that are aggregated for the lifetime of the subscription" means. If the UA is forwarding requests, could it still disaggregate messages sent to a subscription set before delivering them to the other clients?

In section 5.1...

* It might help to include the `Link: </r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM>; rel="urn:ietf:params:push:receipt"` header in the `POST` example. The prose suggests a symmetry with subscription sets, but I was confused how the app server specifies the receipt subscription URL on the first reading.
* I agree with Peter that clarifying whether receipts are sent for TTL=0 messages would be nice.
* Does it make sense for the push server to use a 400-class status code in a receipt to report a nack? For example, if the UA failed to decrypt the message, or the app threw an exception. IIUC, the spec allows 204 for successful deliveries and 410 for expired messages, but it's not clear if the PS can send other statuses in receipts.

* I'm also curious to hear implementer feedback about receipts in general.

In section 5.4...

* Could we restrict the `Topic` grammar to just `token`? ISTM base64url already fits this definition.
* If the replaced and new message specify TTLs, and the new TTL is shorter...does it just replace the old TTL? (This is implied by "the information that is stored for the push message is updated", as well as the restriction that the response TTL must be <= request TTL, but I wanted to double-check).

In section 6, are non-zero `wait` values allowed? (I'm assuming not, since the UA can disconnect at any time).

In section 6.2...

* Is there a way for the push server to indicate to the UA how long it's willing to wait for acks before re-delivering? (For instance, so that the UA can batch acks for a burst of incoming messages. Or does this not make sense with H2?)
* Can a UA "nack" a message, or would this be implementation-specific? (Related to my note above about reporting nacks to the AS in the receipt subscription).

In section 7.2, could we consider allowing push servers to reject messages < 4k? If the PS is proxying the message to a third-party server, which Mozilla's server does on iOS and Android, it might not be able to control the size limit.

In section 7.3.1, if the UA deletes a subscription that belongs to a subscription set, does it receive a 410 for the deleted subscription on the subscription set stream?

Cheers,
- kit

---

From: RUELLAN Herve <[email-masked]>
Date: Thu, 2 Jun 2016 08:04:30 +0000

On Wed, 2016-06-01 at 23:34 +0000, Brian Raymor wrote:
> > but doesn't want to provide a receipt subscription, or doesn't
support providing receipts? Is this allowed in the first place?
>   "urn:ietf:params:push:receipt". 

This sentence could be interpreted either as making support for receipt
subscriptions mandatory or as being a mandatory part of the 202
(Accepted) response, implying that the push service can also respond
with a 201 (Created) even when the Prefer header field is present.

> that existing implementations do this very well :)

As two authors of the spec have divergent opinions, I think that a clear
statement would be helpful ;-).
I've created a pull request stating that support for push receipts is
not mandatory, but I've not strong opinion on the subject.

https://github.com/webpush-wg/webpush-protocol/pull/95

Hervé

---

From: RUELLAN Herve <[email-masked]>
Date: Thu, 2 Jun 2016 09:09:35 +0000

Hi Kit,

> In section 4.1, I'm not clear what "unable to receive push messages that are aggregated for the lifetime of the subscription" means. If the UA is forwarding requests, could it still disaggregate me…

The use case here is that the user agent is acting as a proxy for
another client for monitoring a subscription. This can be for example a
camera using a mobile phone to monitor its subscription. The
subscription should be linked to the client and not the user agent to
allow the client to use another user agent as a proxy without changing
the subscription.

I just created a pull request for trying to make this use case clearer:
https://github.com/webpush-wg/webpush-protocol/pull/96

Cheers,

Hervé

---

From: Brian Raymor <[email-masked]>
Date: Thu, 2 Jun 2016 23:00:10 +0000

Kit - Thanks for the comments.

On Thursday, June 2, 2016 12:02 AM, Kit Cambridge <[email-masked]> wrote:

> Does it make sense for the push server to use a 400-class status code in a receipt to report a nack? For example, if the UA failed to decrypt the message,
> or the app threw an exception. IIUC, the spec allows 204 for successful deliveries and 410 for expired messages, but it's not clear if the PS can send other
> statuses in receipts.

Earlier, Elio proposed Acknowledgement Data for this scenario - https://github.com/webpush-wg/webpush-protocol/issues/42
 & https://github.com/webpush-wg/webpush-protocol/pull/57 - which allows the user agent to return opaque data to its application server.

This was presented and discussed at IETF 94. It was closed with an agreement to re-open if there was more customer data to justify the use cases:

https://datatracker.ietf.org/doc/minutes-94-webpush/
 * Discuss use cases for PR #57 and account for the results in a future update

---

From: Brian Raymor <[email-masked]>
Date: Fri, 3 Jun 2016 03:39:30 +0000

On Thursday, June 2, 2016 12:02 AM, Kit Cambridge <[email-masked]> wrote:

> In section 4.1, I'm not clear what "unable to receive push messages that are aggregated for the lifetime of the subscription" means.
> If the UA is forwarding requests, could it still disaggregate messages sent to a subscription set before delivering them to the other clients?

This change was introduced for Canon's scenario - http://www.ietf.org/mail-archive/web/webpush/current/msg00357.html.

Herve has a pending pull request - https://github.com/webpush-wg/webpush-protocol/pull/96 - with editorial updates to 4.1:
  https://github.com/webpush-wg/webpush-protocol/pull/96/commits/55b6b5efc16ab4db8363770279c87c0412a8cc12 

Does this offer enough clarification? 

...Brian

---

From: Brian Raymor <[email-masked]>
Date: Fri, 3 Jun 2016 03:58:35 +0000

> * It might help to include the `Link: </r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM>; rel="urn:ietf:params:push:receipt"` header in the `POST` example.
> The prose suggests a symmetry with subscription sets, but I was confused how the app server specifies the receipt subscription URL on the first reading.

To be clear, you're requesting a new example for subsequent POSTS that pass the push:receipt which would be similar to the example for subscription sets in section 4.1.1?

Something like:

For subsequent receipt requests to the same origin [RFC6454], the
application server SHOULD include the returned receipt subscription
in a link relation of type "urn:ietf:params:push:receipt". This
gives the push service an option to aggregate the receipts.

POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
Prefer: respond-async
Link: </receipt-subscription/3ZtI4YVNBnUUZhuoChl6omUvG4ZM>;
rel="urn:ietf:params:push:receipt"
TTL: 15
Content-Type: text/plain;charset=utf8
Content-Length: 36

iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB

The push service SHOULD return the same receipt subscription in its response,
although it MAY return a new receipt subscription if it is unable to
reuse the one provided by the application server.

HTTP/1.1 202 Accepted
Date: Thu, 11 Dec 2014 24:56:55 GMT
Link: </receipt-subscription/3ZtI4YVNBnUUZhuoChl6omUvG4ZM>;
rel="urn:ietf:params:push:receipt"
Location: https://push.example.net/message/xDIYHNcfAIPP_5ITvURr-d6BGt

> * I agree with Peter that clarifying whether receipts are sent for TTL=0 messages would be nice.

See the discussion in https://github.com/webpush-wg/webpush-protocol/pull/91

We've iterated on zero TTL quite a bit. Do you have any suggestions on how to further clarify:

A Push message with a zero TTL is immediately delivered if the user
agent is available to receive the message. After delivery, the push
service is permitted to immediately remove a push message with a zero
TTL. This might occur before the user agent acknowledges receipt of
the message by performing a HTTP DELETE on the push message resource.
Consequently, an application server cannot rely on receiving
acknowledgement receipts for zero TTL push messages.

---

From: Brian Raymor <[email-masked]>
Date: Fri, 3 Jun 2016 04:07:51 +0000

Please see my comments in  https://github.com/webpush-wg/webpush-protocol/pull/95 and
https://github.com/webpush-wg/webpush-protocol/pull/97 - which are both now closed.

We agreed that receipts "on demand" were required some time ago. I can certainly tighten up the language to
remove any ambiguity introduced by the use of Prefer: to simplify the flow. There was never
an intention or related discussion to make this feature optional. 

-----Original Message-----
From: Webpush [mailto:[email-masked]] On Behalf Of RUELLAN Herve
Sent: Thursday, June 2, 2016 1:05 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Webpush] Non-blocking comments on -05

Hervé

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Jun 2016 17:23:59 +1000

I don't think that Brian addressed these already...

> * If the replaced and new message specify TTLs, and the new TTL is shorter...does it just replace the old TTL? (This is implied by "the information that is stored for the push message is updated",…

Yes, let's be explicit though:
  https://github.com/webpush-wg/webpush-protocol/pull/102

I've also changed from MAY to SHOULD for suppressing delivery receipts
on replacement.  There is a race condition, otherwise I would say
MUST.

> In section 6, are non-zero `wait` values allowed? (I'm assuming not, since the UA can disconnect at any time).

The 0 value is special in that it is required.  Other values are up to
the push service to decide on what to do, though it does give a client
some control over liveness without having to initiate PING frames.

Do you think we need text about non-zero values?  Respecting Prefer is
generally discretionary, and I'd like to keep it that way.

> * Is there a way for the push server to indicate to the UA how long it's willing to wait for acks before re-delivering? (For instance, so that the UA can batch acks for a burst of incoming messages…

You mean like Retry-After?  There isn't really anything like that.

> In section 7.2, could we consider allowing push servers to reject messages < 4k? If the PS is proxying the message to a third-party server, which Mozilla's server does on iOS and Android, it might…

The point of having this value is that it's a low limit and
application servers can rely on that many octets being available.  I
hate to suggest it, because it's disgusting to implement, but if you
are sending messages to iOS devices, maybe you need to consider
split-and-merge.

---

From: Costin Manolache <[email-masked]>
Date: Fri, 03 Jun 2016 14:39:19 +0000

On Thu, Jun 2, 2016 at 2:09 AM RUELLAN Herve <[email-masked]>
wrote:

> > First, I'd like to echo Peter's "thank you". I'm very grateful for all
> your work in putting this standard together and marshaling feedback, here
> and on GitHub! In addition to the comments from Peter, JR, and Hervé, I
> have a few questions and suggestions. None of them block the WGLC.
> >
> > In section 4.1, I'm not clear what "unable to receive push messages that
> are aggregated for the lifetime of the subscription" means. If the UA is
> forwarding requests, could it still disaggregate messages sent to a
> subscription set before delivering them to the other clients?
> >
>
I'm not very comfortable to adding features at this point - proxy mode and
migrating
subscription sets have quite a few implementation implications. I think
it's a useful
feature and use case - but it is very tricky. We can discuss it in separate
thread.

In particular the AS proxy is very unlikely to work with authentication.

Costin

---

From: Costin Manolache <[email-masked]>
Date: Fri, 03 Jun 2016 14:56:25 +0000

On Thu, Jun 2, 2016 at 12:01 AM Kit Cambridge <[email-masked]>
wrote:

> * It might help to include the `Link: </r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM>;
> rel="urn:ietf:params:push:receipt"` header in the `POST` example. The prose
> suggests a symmetry with subscription sets, but I was confused how the app
> server specifies the receipt subscription URL on the first reading.
> * Does it make sense for the push server to use a 400-class status code in
> a receipt to report a nack? For example, if the UA failed to decrypt the
> message, or the app threw an exception. IIUC, the spec allows 204 for
> successful deliveries and 410 for expired messages, but it's not clear if
> the PS can send other statuses in receipts.
>

Would generate too much traffic and load, and would increase the
implementation costs. In some cases
the messages can be expired by the storage system, in batch - it wouldn't
be a problem if 'nack'
would be a rare case, but in mobile a very large number of devices (
tablets, etc ) are offline for
long time so nack would be very frequent.

> * If the replaced and new message specify TTLs, and the new TTL is
> shorter...does it just replace the old TTL? (This is implied by "the
> information that is stored for the push message is updated", as well as the
> restriction that the response TTL must be <= request TTL, but I wanted to
> double-check).
>

One thing to keep in mind is that some PS may use nosql and be distributed
and use eventual consistency.
Messages have a timestamp, so either they will be collapsed, or both will
be sent. If the new one has shorter
TTL, it may get lost.

> * Is there a way for the push server to indicate to the UA how long it's
> willing to wait for acks before re-delivering? (For instance, so that the
> UA can batch acks for a burst of incoming messages. Or does this not make
> sense with H2?)
>

Batch acks would be useful, but with resource URL it's trickier. If ACK
would be implemented at lower level it may be possible
( i.e. UA would ack the H2 stream IDs of the messages ), but it's an
optimization that can be done later.

I expect PS will re-deliver on the next connection or monitor request.

> * Can a UA "nack" a message, or would this be implementation-specific?
> (Related to my note above about reporting nacks to the AS in the receipt
> subscription).
>

It would add costs to the PS, and I don't think it's a common use case. To
'nack', the UA needs to first get the message to know the ID.

>
> In section 7.2, could we consider allowing push servers to reject messages
> < 4k? If the PS is proxying the message to a third-party server, which
> Mozilla's server does on iOS and Android, it might not be able to control
> the size limit.
>

+1

Costin

>
> In section 7.3.1, if the UA deletes a subscription that belongs to a
> subscription set, does it receive a 410 for the deleted subscription on the
> subscription set stream?
>

---

From: Martin Thomson <[email-masked]>
Date: Sat, 4 Jun 2016 09:16:34 +1000

>> Mozilla's server does on iOS and Android, it might not be able to control

Do either of you want to recommend an alternative limit?  The limit
exists so that application servers can send messages of a certain size
without having to worry that they will be told to go away.  That's a
useful property to maintain.  However, if there are practical limits
that make 4k too hard, please pick a more realistic limit.  Is it 2k?
Less?

---

From: Costin Manolache <[email-masked]>
Date: Sat, 04 Jun 2016 02:48:11 +0000

We support 4k, and it would be great to keep it as is for regular UA
and PS.

However if the push service is proxying to other protocols - there are
services limiting the size to 2k, and I assume for IoT or other cases
the limit may be even lower. In such cases the PS can't deliver - so
should indicate the cause.
In most cases the AS has more information about the UA - so it shouldn't
attempt to send 4k to a lightbulb with 256B of free RAM.

Costin

---

From: Brian Raymor <[email-masked]>
Date: Tue, 7 Jun 2016 23:17:31 +0000

If there are no further comments or proposals, I will close https://github.com/webpush-wg/webpush-protocol/issues/109

Thanks,
…Brian

From: Costin Manolache [mailto:[email-masked]]
Sent: Friday, June 3, 2016 7:48 PM
To: Martin Thomson <[email-masked]>
Cc: Kit Cambridge <[email-masked]>; Brian Raymor <[email-masked]>; Peter Beverloo <[email-masked]>; [email-masked]; RUELLAN Herve <[email-masked]>
Subject: Re: [Webpush] Non-blocking comments on -05

Costin

On Fri, Jun 3, 2016 at 4:16 PM Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Brian Raymor <[email-masked]>
Date: Wed, 8 Jun 2016 20:44:59 +0000

Thanks to Herve for updating this - https://github.com/webpush-wg/webpush-protocol/pull/114

Kit - does the PR address your feedback below?

Costin raised a concern about this specific sentence:
  Each subscription set can then be managed independently, which might include being moved between user agents.

noting:

> BTW - I am also interested in the 'move between UA' use case, but I don't think there is enough implementation and data around it.

Does anyone else share this concern?

Thanks,
...Brian

-----Original Message-----
From: RUELLAN Herve [mailto:[email-masked]] 
Sent: Thursday, June 2, 2016 2:10 AM
To: [email-masked]
Cc: [email-masked]; Brian Raymor <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Webpush] Non-blocking comments on -05

Hi Kit,

Cheers,

Hervé

---

From: Kit Cambridge <[email-masked]>
Date: Thu, 9 Jun 2016 11:40:17 -0700

Following up: I think keeping the 4k minimum makes sense. It really depends on the service that’s proxying the message…or the characteristics of the receiving device, as Costin points out.

The push server can chunk the message before proxying, per Martin’s suggestion. It could also refuse to deliver the message with another 400-class status code, instead of a 413.

---

From: Kit Cambridge <[email-masked]>
Date: Thu, 9 Jun 2016 12:01:12 -0700

> Kit - does the PR address your feedback below?

Yes, “monitoring subscriptions for other clients” is clearer. Thank you!

> Does anyone else share this concern?

Does moving a subscription set mean another UA would be able to receive messages sent to subscriptions in that set? (That is, without requiring the old UA to drop all its subscriptions and the new UA to reregister).

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Jun 2016 07:33:41 +1000

> Does moving a subscription set mean another UA would be able to receive messages sent to subscriptions in that set? (That is, without requiring the old UA to drop all its subscriptions and the new…

I think that you have it. If you have 2 subscriptions that are in the
same set, they have to be monitored together.  If they are in separate
sets, then they can be monitored separately.  The separation enables
intermediation.

I don't think that this is a use case that is particularly important
for the web case; I confess that it isn't that interesting to me.
However, I think that it is an entirely valid use case, and it costs
little.  It does however enable things on the web side that *are* very
interesting to me.

Say you have a UA that wants to go into a deep sleep to save power.
In that mode, it still wants to receive push messages from several
high priority sites.  But it doesn't want to get the deal-of-the-day
and all that junk from other sites.

Now, the UA knows that the push service is unable to discriminate
between important and unimportant properly and it doesn't want to risk
getting things like text message notifications from unimportant sites.
Even if these are normally sent with moderately high urgency,
legitimately.

If it can split the important sites and the unimportant sites into two
subscription sets, then it can monitor the important sites only.
That's not possible if you don't allow the UA to control which
subscriptions get grouped together.

If you want a concrete example, think pagerduty.com vs. skype.com.  A
call might be entirely undesirable at 3am, but if a production site is
on fire, it's wake up time.

---

From: jr conlin <[email-masked]>
Date: Thu, 9 Jun 2016 15:03:30 -0700

For some of our bridged protocols, we lose a percentage due to the
protocol exchange overhead. Our server knows the limit and usually
returns that with a 413 error (I'm fine with our server being
non-standard, since I suspect that not all implementations would use
bridges the way we do.)

Our bridge currently limits to just over 3K, however to Costin's point,
I can perceive some future bridge or device having much tighter
restrictions.

On 6/3/2016 7:48 PM, Costin Manolache wrote:
> On Fri, Jun 3, 2016 at 4:16 PM Martin Thomson
> <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: RUELLAN Herve <[email-masked]>
Date: Fri, 10 Jun 2016 10:17:04 +0000

> on fire, it's wake up time.

As there seems to be several use cases here (your use case for the web,
Costin's multi-user case in android, and my UA proxying use case), I
think more of them could be listed in the spec.

How about:

Each subscription set can then be managed independently, which might
include monitoring only a set of very important subscriptions, handling
subscription for different users separately, or moving a subscription
set between user agents.

For moving subscription sets between UA, I agree that it's too early to
solve it in this Webpush draft. My concern here is to leave open the
possibility of building it in the future.

Hervé

---

From: Costin Manolache <[email-masked]>
Date: Fri, 10 Jun 2016 17:17:33 +0000

Most use cases mentioned - with the exception of 'moving subscription' -
can be implemented
efficiently by storing the messages keyed by some 'primary' ID. For large
numbers, it
is desirable to optimize the number of DB queries done at connect - i.e. do
a single read that
hits a single shard.  Most of the time the read will return empty, but the
locality of the
messages for a single device is pretty important.

Moving subscriptions pretty much requires a different design - and I don't
have any experience
with how it can scale.

Costin

On Fri, Jun 10, 2016 at 3:17 AM RUELLAN Herve <[email-masked]>
wrote:

> > > Does moving a subscription set mean another UA would be able to
> receive messages sent to subscriptions in that set? (That is, without
> requiring the old UA to drop all its subscriptions and the new UA to
> reregister).
> >

---

From: Brian Raymor <[email-masked]>
Date: Mon, 13 Jun 2016 17:46:29 +0000

My opinion is that we do not need to block on potential/experimental (“might include”) use cases.

If there are no strong objections and/or further edits for Herve, I’ll merge/edit this PR later today.

From: Costin Manolache [mailto:[email-masked]]
Sent: Friday, June 10, 2016 10:18 AM
To: RUELLAN Herve <[email-masked]>; [email-masked]
Cc: Brian Raymor <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Webpush] Non-blocking comments on -05

Most use cases mentioned - with the exception of 'moving subscription' - can be implemented
efficiently by storing the messages keyed by some 'primary' ID. For large numbers, it
is desirable to optimize the number of DB queries done at connect - i.e. do a single read that
hits a single shard.  Most of the time the read will return empty, but the locality of the
messages for a single device is pretty important.

Moving subscriptions pretty much requires a different design - and I don't have any experience
with how it can scale.

Costin

On Fri, Jun 10, 2016 at 3:17 AM RUELLAN Herve <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, 2016-06-10 at 07:33 +1000, Martin Thomson wrote:
> On 10 June 2016 at 05:01, Kit Cambridge <[email-masked]<mailto:[email-masked]>> wrote:
> If you want a concrete example, think pagerduty.com<http://pagerduty.com> vs. skype.com<http://skype.com>.  A

How about:

Hervé