Code change:
value MUST be less than or equal to the value provided by the application server. <ins> 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 the situation where obsolete or redundant messages are sent to the user agent. Only push messages that have been assigned a topic can be updated.  A push message with a topic replaces any outstanding push message with an identical topic. A push message topic is a string.  A topic is carried in a Topic header field.  A topic is used to correlate push messages sent to the same subscription, it does not convey any other semantics. The grammar for the Topic header field uses the "token" and "quoted- string" rules defined in RFC7230. Any double quotes from the "quoted-string" form are removed before comparing topics for equality. For use with this protocol, the Topic header field MUST be restricted to no more than 32 characters from the URL- and filename-safe base64 set [RFC4648].  A push service that receives a request with a Token header field that does not meet these constraints SHOULD return an HTTP 400 (Bad Request) status code to an application server. A push message request creates a new push message resource, but simultaneously deletes any existing message resource that has a matching topic.  In effect, the information that is stored for the push message is updated, but a new resource is created to avoid problems with in flight acknowledgments for the old message.  The push service MAY suppress acknowledgement receipts for the replaced message. This mechanism doesn't allow for stored push messages to be deleted. An application server can remove a push message using a DELETE request to the push message URL. A push message with a topic that has a zero or absent time-to-live will cause a stored message with the same topic to be removed as well as not being stored itself, but the push service will attempt to forward the updated message to the user agent. A push message with a topic that is not shared by an outstanding message to the same subscription is stored or delivered as normal. The value of the Topic header field MUST NOT be forwarded to user agents.  Its value is not encrypted or authenticated. </ins> 7. A user agent requests the delivery of new push messages by making a

Related discussion:
text: However, you raise a point that the definition of 429 leaves open: Is this too many requests globally? By the same client? To the same resource? To the same resource by the same client? Basically, the "scope" of applicability for 429 is hard - if not impossible - to determine. The scope is defined in some server specific terms. The question I'd ask is whether we want to provide some webpush-specific mechanism for identifying the scope of applicability for the rejection.
What about using a Scope header field in the response? In this case it will be 'Topic', maybe for too many messages for a subscription it could be 'Subscription', etc.
All these things are possible. The question is how important it is. Also, if we wanted to address the scope problem, I would want to address it more generally and then maybe add any push-specific extensions as necessary. This is a problem with 429 that - if it is worth fixing here - is probably worth fixing generally.
Maybe this was answered elsewhere, but why not just reusing the push message URI? To replace a previous message, the application would create a new message and include the previous message URI in the creation request, inside a "Replace" header. Otherwise, it would work in the same way as this proposal. This would be easy to handle on the Push Server side. On the application server side, this would mean storing the previous message URI. But the application server needs to store the topic of the previous message anyway.
NAME the idea here was that remembering the push message URI was a burden we didn't want to impose on applications. Those that aren't using acknowledgments will be able to use this version without holding any special state. Thanks for the grammatical review, I'll fix those up.
NAME an application wanting to be able to update a message will need to keep the topic of this message, so it will need to keep this state. I don't think keeping a topic or the push message URI is a large difference. However, it's true that simple applications could use only 1 topic, which would be predefined (or a few predefined topics).
NAME an application can hard-code a topic or small set of topics. They can also derive a topic from context. A URL needs to be first learned, then memorized.
NAME do you have any opinions on this change?