Draft: draft-ietf-webpush-protocol

Commentary: I 've specified a Topic header field that we can use as a " collapse key " . 
 Regarding  topics , I do n't plan on limiting the  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 ) + 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 . 
 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 is n't surprised later when their app needing 5 topics does n'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 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 . 
 the idea here was that remembering the push message URI was a burden we did n't want to impose on applications . Those that are n'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 . 
 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 do n'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 ) . 
 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 . 
 do you have any opinions on this change ? 
 Updated based on feedback from Note that I have n'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 ? 
 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  or as a separate document . I 'm closing this issue for webpush since it 's no longer actionable - - re - open if you want to track for " futures " . I 'll tag appropriately .
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
The grammar for the Topic header field uses the "token" and "quoted-
string" rules defined in RFC7230.
Paragraph (version B):
Any double quotes from the "quoted-string" form are removed before
comparing topics for equality.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
A push message with a topic that is not shared by an outstanding
message to the same subscription is stored or delivered as normal.
Paragraph (version B):
The value of the Topic header field MUST NOT be forwarded to user
agents.  Its value is not encrypted or authenticated.
Paragraph (version B):
The Topic header field exposes information that allows more granular
correlation of push messages on the same subject.  This might be used
to aid traffic analysis of push messages by the push service.