[Webpush] Urgency of Messages

[Brian Raymor <[e-mail]>]

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