support Urgency
See original GitHub issuehttps://tools.ietf.org/html/rfc8030#section-5.3
5.3. Push Message Urgency
For a device that is battery-powered, it is often critical that it
remains dormant for extended periods. Radio communication in
particular consumes significant power and limits the length of time
that the device can operate.
To avoid consuming resources to receive trivial messages, it is
helpful if an application server can communicate the urgency of a
message and if the user agent can request that the push server only
forwards messages of a specific urgency.
An application server MAY include an Urgency header field in its
request for push message delivery. This header field indicates the
message urgency. The push service MUST NOT forward the Urgency
header field to the user agent. A push message without the Urgency
header field defaults to a value of "normal".
A user agent MAY include the Urgency header field when monitoring for
push messages to indicate the lowest urgency of push messages that it
is willing to receive. A push service MUST NOT deliver push messages
with lower urgency than the value indicated by the user agent in its
monitoring request. Push messages of any urgency are delivered to a
user agent that does not include an Urgency header field when
monitoring for messages.
The grammar for the Urgency header field is as follows:
Urgency = urgency-option
urgency-option = ("very-low" / "low" / "normal" / "high")
In order of increasing urgency:
+----------+-----------------------------+--------------------------+
| Urgency | Device State | Example Application |
| | | Scenario |
+----------+-----------------------------+--------------------------+
| very-low | On power and Wi-Fi | Advertisements |
| low | On either power or Wi-Fi | Topic updates |
| normal | On neither power nor Wi-Fi | Chat or Calendar Message |
| high | Low battery | Incoming phone call or |
| | | time-sensitive alert |
+----------+-----------------------------+--------------------------+
Table 1: Illustrative Urgency Values
Multiple values for the Urgency header field MUST NOT be included in
requests; otherwise, the push service MUST return a 400 (Bad Request)
status code.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:6 (3 by maintainers)
Top Results From Across the Web
Support Center Urgency Levels - PALS - MnPALS
Then, follow up with a phone call to the PALS Support Center phone number (507-389-2000), explain that it is an emergency, and provide...
Read more >About Support Ticket Urgency and Classification
Student submitted tickets are generally addressed based on order of submission, working from oldest to newest. Ticket Urgency and Classification.
Read more >Impact, Urgency & Priority: Understanding the Matrix
When it comes to business priorities, nothing speaks louder than having available and reliable IT services that support business outcomes.
Read more >Support Ticket Priority Levels: 11 Ways to Optimize Your System
11 Tips to Optimize Your Support Ticket Prioritization · 1. Define Your Service-Level Agreement (SLA) · 2. Prioritize Urgent Support Tickets · 3....
Read more >9 reliable ways to prioritize customer service tickets and ...
Customer request prioritization is key to customer service and CX. Here are 9 ways to prioritize support conversations.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Thanks, I’ll add support in the next weeks.
Thank you, kind sir. I recently switched from GCM to Web Push, and some of my firefighters had noted that they were getting their notifications much slower after the update. I’m hoping that setting the urgency to “high” solves their problems 🤞