Subject: [Webpush] Urgency of Messages

From: Brian Raymor <[email-masked]>
Date: Thu, 4 Feb 2016 20:29:06 +0000

https://github.com/webpush-wg/webpush-protocol/issues/28

There's been a long conversation in this issue that I'd like to bring to the mailing list for broader discussion and closure.

Questions:

a) Is there rough consensus to support this feature in the protocol?
b) If so, then what is the shape of the design?

I believe that there's general agreement that we need the following capabilities for an application server publishing a message to the push service:

* 0 | "high" | "urgent" - send urgent message immediately and wake up the user agent 
* 1 | "normal" - send opportunistically - send prior to expiration if no urgent messages are queued
* 2 | "low" | "non-urgent" - send opportunistically - allow to expire if no urgent messages are queued

Multiple variations for the mapping have been suggested. I don't have a strong feeling for whether the mapping should be 0 or "high" or "urgent".  GCM uses "high" and "normal" in its Priority field. APNS uses 10 and 5. 

In addition, not everyone favors the "Nice" header field name unless they're quite fond of Unix. Perhaps we could rename it to "Urgency". I would prefer to avoid "Priority".  As I remarked in the issue:

Priority is too overloaded a term, since it may refer to:
* Message Ordering
* Urgency ("Niceness") as in "Is it urgent enough to wake the device and burn the battery?"

Then there's another question of whether there also needs to be a public protocol between the user agent and push service to either hint at the device state or apply an urgency "filter":

Benjamin writes:

>> @costinm Do you plan on introducing additional flags for the client when making a
>> notification request that conveys all this additional knowledge (on wifi, 'charging', etc)
>> to the Push service? Is it the right place for the Push service to choose how to optimize
>> delivery, or should the client flag indicate what level of urgency it wants notifications for?

Costin responds:

> GCM uses a binary protocol for UA-push service, which already has the flags ( it wouldn't work
 > otherwise for the deep sleep for example ). I think common ones could be added to webpush
> spec, but with lots of care - we don't want the UA to send notifications too often (for example
> on state change). 
> A start would be to define a header for the 'monitor' request, with a list of flags, and
> define common ones ( charging, network type ). 

I'm curious what the working group thinks about these proposals. Are there alternative approaches that we should consider?

Thanks,
...Brian

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 Feb 2016 22:21:58 +1100

I think that you have the right idea here, picking urgency.

> I'm curious what the working group thinks about these proposals. Are there alternative approaches that we should consider?

I think that it would be better to simply have the client indicate the
urgency of the messages it wants to receive.  That way, there's a
clear understanding of what it will receive without being subject to
some unspecified algorithm in the push service.

We can make some suggestions perhaps.  For instance:

  On power and wifi: urgency = very-low
  On one but not both: urgency = low
  On neither: urgency = normal (or absent)
  Low battery: urgency = high

Setting a value indicates that the UA wants "normal" delivery of
messages at that urgency.  Higher urgency values than what was
advertised would get accelerated delivery.  Lower values would get
stored and delivered later.

We can also try to set some guidelines around what each urgency means:

  high = incoming phone call, time-sensitive alert
  normal = chat message, first email notification, calendar message
  low = subsequent email notification
  very-low = advertising

That might help establish some consistency between applications in
terms of what they use, so that user agents can set values with some
confidence that they will be respected.  I tried that with -nice, but
it could definitely be improved.