Subject: [Webpush] SHOULD return link references to the push and receipt subscribe resources

From: Brian Raymor <[email-masked]>
Date: Fri, 9 Oct 2015 23:36:02 +0000

https://tools.ietf.org/html/draft-ietf-webpush-protocol-00#section-6
   ...
   In response to this request, the push server MUST generate a server
   push for all push messages that have not yet been delivered.  In
   addition, the push service SHOULD return link references to the push
   and receipt subscribe resources ...

What is the rationale for returning the :push and :push:receipt link references in this response? For example, if a user agent is receiving a push message, then it has already received and shared the :push link reference with its application server.  Why would it need to receive the :push link reference from the push server again?

...Brian

---

From: Martin Thomson <[email-masked]>
Date: Sat, 10 Oct 2015 10:00:16 +0200

> What is the rationale for returning the :push and :push:receipt link references in this response? For example, if a user agent is receiving a push message, then it has already received and shared t…

The idea was to reduce the state commitment requirements on user
agents.  This way, a client only needs to remember the subscription
URI.  The server needs to know the mapping to receipt and push
resources for each subscription anyway, so this should be trivial to
implement.  Without it, user agents are forced to remember three URIs
for each subscription.

---

From: Brian Raymor <[email-masked]>
Date: Sun, 11 Oct 2015 23:18:05 +0000

On 10 October 2015, Martin Thomson <[email-masked]> wrote:

> The idea was to reduce the state commitment requirements on user agents.  This way, a client only needs to remember the subscription > URI.  The server needs to know the mapping to receipt and push resources for each subscription anyway, so this should be trivial to 
> implement.  Without it, user agents are forced to remember three URIs for each subscription.

Under what circumstances would the user agent need to remember the :push and :push:receipt URIs after sharing them with its application server?  I'm trying to understand the scenario that motivated the recommendation. 

Thanks,
...Brian

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Oct 2015 18:54:37 +0200

> Under what circumstances would the user agent need to remember the :push and :push:receipt URIs after sharing them with its application server?  I'm trying to understand the scenario that motivated…

It might want to share the subscription with new instances of the
application server.  In the browser case, you might imagine the
application calling `getSubscription()`.  That results in the :push
and :push:receipt being shared again with the application.