Original text:
6.3.  A push message that has been stored by the push service can be replaced with new content.  If the user agent is offline during the time that the push messages are sent, updating a push message avoids send the contents of push messages as they are sent by application servers.  Each push message is pushed as the response to a synthesized GET request in a PUSH_PROMISE.  This GET request is made to the push message resource that was created by the push service when the respond to this request, it instead uses RFC7540 to send the contents of push messages as they are sent by application servers.  Each push message is pushed as the response to a synthesized GET request sent in a PUSH_PROMISE.  This GET request is made to the push message resource that was created by the push service when the

Reviewer comments:
Should we include a reference to URL - perhaps in Acknowledgements?
I don't care about acknowledgments for -nice. But I do care about the issues that I raised on the list.

Revised text:
6.3. <ins> 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 forward 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 user agent MAY include the Urgency header field when requesting push messages to indicate that it only wants to receive messages at an equal or greater urgency. An absent Urgency header field indicates that the request is to be forwarded at "normal" urgency.  Multiple values for the header field MUST NOT be included in requests; otherwise, the push service MUST return a 400 (Bad Request) status code. 6.4. </ins> A push message that has been stored by the push service can be replaced with new content.  If the user agent is offline during the time that the push messages are sent, updating a push message avoids send the contents of push messages as they are sent by application servers. <ins> A user agent MAY include a Urgency header field in its request.  The push service MUST only deliver messages with an urgency greater than or equal to the value of the header field as defined in the urgency_values. </ins> Each push message is pushed as the response to a synthesized GET request in a PUSH_PROMISE.  This GET request is made to the push message resource that was created by the push service when the respond to this request, it instead uses RFC7540 to send the contents of push messages as they are sent by application servers. <ins> A user agent MAY include a Urgency header field in its request.  The push service MUST only deliver messages with an urgency greater than or equal to the value of the header field as defined in the urgency_values. </ins> Each push message is pushed as the response to a synthesized GET request sent in a PUSH_PROMISE.  This GET request is made to the push message resource that was created by the push service when the