Re: [Webpush] Non-blocking comments on -05

[Martin Thomson <[e-mail]>]

I don't think that Brian addressed these already...

On 2 June 2016 at 17:01, Kit Cambridge <[e-mail]> wrote:
> * If the replaced and new message specify TTLs, and the new TTL is shorter...does it just replace the old TTL? (This is implied by "the information that is stored for the push message is updated", as well as the restriction that the response TTL must be <= request TTL, but I wanted to double-check).

Yes, let's be explicit though:
  https://github.com/webpush-wg/webpush-protocol/pull/102

I've also changed from MAY to SHOULD for suppressing delivery receipts
on replacement.  There is a race condition, otherwise I would say
MUST.

> In section 6, are non-zero `wait` values allowed? (I'm assuming not, since the UA can disconnect at any time).

The 0 value is special in that it is required.  Other values are up to
the push service to decide on what to do, though it does give a client
some control over liveness without having to initiate PING frames.

Do you think we need text about non-zero values?  Respecting Prefer is
generally discretionary, and I'd like to keep it that way.

> * Is there a way for the push server to indicate to the UA how long it's willing to wait for acks before re-delivering? (For instance, so that the UA can batch acks for a burst of incoming messages. Or does this not make sense with H2?)

You mean like Retry-After?  There isn't really anything like that.

> In section 7.2, could we consider allowing push servers to reject messages < 4k? If the PS is proxying the message to a third-party server, which Mozilla's server does on iOS and Android, it might not be able to control the size limit.

The point of having this value is that it's a low limit and
application servers can rely on that many octets being available.  I
hate to suggest it, because it's disgusting to implement, but if you
are sending messages to iOS devices, maybe you need to consider
split-and-merge.