Re: [Webpush] FW: New Version Notification for draft-thomson-webpush-protocol-00.txt

It is hard to support ordering at scale - we would prefer that ordering is
not guaranteed.
But we support de-duplication and retries.

Costin

On Wed, Apr 29, 2015 at 12:24 PM, DRUTA, DAN <dd5826@att.com> wrote:

> Hi Martin,
>
> I think we can address the relative priority in the web push draft at
> minimum with some clarifications on use cases and some of the requirements.
> Much like I tried to explain in my example and you expanded with the device
> nap scenario.
> If NICE proposal gets support in http WG I don't see any reason to
> reinvent the wheel but as of now I believe your draft is expired.
> At least we should determine how important of a feature this is.
>
> Dan
>
> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: Wednesday, April 29, 2015 11:57 AM
> To: DRUTA, DAN
> Cc: Brian Raymor (MS OPEN TECH); webpush@ietf.org
> Subject: Re: [Webpush] FW: New Version Notification for
> draft-thomson-webpush-protocol-00.txt
>
> On 29 April 2015 at 10:12, DRUTA, DAN <dd5826@att.com> wrote:
> > 1. Prioritization
> [...]
> > Is the expectation that the app server will send them in the right
> sequence and the push server will use a FIFO (first in first out) queue?
>
> The draft really doesn't say, partly because we didn't discuss it
> much, partly because I think that we'd want some flexibility.  I've
> opened an issue on this in our issue tracker so that we don't forget
> this.
>
> > Priority is a fairly basic requirement and I hope it can get handled in
> a header so it can be consistently enforced by the push service.
>
> Prioritization is a concern if there are multiple messages to deliver
> at the same time.  This happens most often when a device comes back
> from a short nap (as mobile devices do all the time).  With a small
> number of messages, this might not be a big deal, but if there is a
> backlog to clear, it could be.  I have a draft on signaling priorities
> that could be used in this context:
> https://tools.ietf.org/html/draft-thomson-http-nice-02
>
> Do you think that we need to address this in a basic protocol
> specification, or can it rely on other specifications.
>
> > 2. Message deduplication and retries.
>
> Yes, reliability is hard.  The intent is to have the application mark
> messages and perform deduplication if it does resending, especially
> within the TTL period that the push service promises.
>
> In terms of the protocol, there is a proposal for message replacement
> that might reduce the need for some of this, but Brian, Elio and I
> decided that we'd let this draft stabilize before talking about that
> feature: https://github.com/unicorn-wg/webpush-protocol/pull/12
> _______________________________________________
> Webpush mailing list
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush
>