Original text:
value MUST be less than or equal to the value provided by the application server.  7. A user agent requests the delivery of new push messages by making a

Reviewer comments:
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. 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?
Updated based on feedback from NAME Note that I haven't changed the name. Not sure that we have consensus on that yet.
Conversation starts : How does the PS know that AS can accept more receipts, and how does it know a receipt has been accepted by the AS ?
Two-Pipe model a la mode de TIP? URL
NAME started on HTTPbis
Costin : we discussed my concerns on flow control for push promises, and I think it's reasonable to have them addressed either as part of http2 or as a separate document. I'm closing this issue for webpush since it's no longer actionable - NAME - re-open if you want to track for "futures". I'll tag appropriately. +1 - we discussed my concerns on flow control for push promises, and I think it's reasonable to have them addressed either as part of http2 or as a separate document. Other than that I think it's reasonable and stable base - extensions and features can be added on top of it. Costin Richard Maher wrote: >
+1 But I'm not sure we can support the mode that Martin described, so I think we may take advantage of "PS MAY return a new receipt subscription if it is unable to reuse". Buffering and flow control are complicated - the choice is between dropping receipts or sending them to a different DC. I haven't checked, but I think there is no guarantee on saving receipts if AS doesn't have enough ingress capacity. One question for HTTP/2 experts: I assumed the receipt promises are subject to normal 'max concurrent streams' ( and this will be the main mechanism to do flow control/balancing from PS to AS). However I see rfc7540: ... " Note: The client never sends a frame with the END_STREAM flag for a server push." How does the PS know that AS can accept more receipts, and how does it know a receipt has been accepted by the AS ? Costin Brian Raymor wrote: >

Revised text:
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