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: I've specified a Topic header field that we can use as a "collapse key".
Regarding max topics, I don't plan on limiting the max topics. I'm using a sharded db with a compound hash+range key for indexing, and plan on storing the topic in the range key for direct access to delete it for later messages with a topic field. There is the side-effect that the UA will get messages out-of-order as a result. ie. all messages with no topic will be delivered in order, then messages with a topic will be delivered in the order of their topic names.
We currently impose a limit of four topics (née collapse keys) +NAME I do like the change. GCM has a separate feature called Topics, i.e. subscriptions to a category, which may cause some confusion. Thinking about the name without taking this into account, I still think it makes sense in this context. URL
NAME yup, the common use case of sending "You have N messages in your mailbox", makes sense to just tell a developer to add the topic "Inbox", and the user will always get the last one sent in. I am curious about how systems having topic limits plan on communicating this to the app-server. Is there some minimum the spec should mandate just so that an app developer isn't surprised later when their app needing 5 topics doesn't work right on a browser that has topic limits?
Would 429 work for systems that run out of topics (or collapse keys)? That seems right to me.
429 seems to specific to be used for this scenario: The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting"). Could be a 500?
Is there a length limitation on the Topic? This could also be implementation-specific and signaled by: 431 Request Header Fields Too Large (RFC6585)
I think that NAME and I concluded that we could accept any size of topic. Up to the limits on header field sizes, that is, which would trigger 431. Maybe, but it is the best match I have. And I think that 4xx is better than 5xx.
If you continue with 429, how does an application server discern between 429 Rate Limiting and 429 Too Many Topics? By the presence of Retry-After?
Retry-After might be present in all cases.