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

[Costin Manolache <[e-mail]>]

On Thu, Jun 2, 2016 at 12:01 AM Kit Cambridge <[e-mail]>
wrote:

> Hi all,
>
> First, I'd like to echo Peter's "thank you". I'm very grateful for all
> your work in putting this standard together and marshaling feedback, here
> and on GitHub! In addition to the comments from Peter, JR, and Hervé, I
> have a few questions and suggestions. None of them block the WGLC.
>
> In section 4.1, I'm not clear what "unable to receive push messages that
> are aggregated for the lifetime of the subscription" means. If the UA is
> forwarding requests, could it still disaggregate messages sent to a
> subscription set before delivering them to the other clients?
>
> In section 5.1...
>
> * It might help to include the `Link: </r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM>;
> rel="urn:ietf:params:push:receipt"` header in the `POST` example. The prose
> suggests a symmetry with subscription sets, but I was confused how the app
> server specifies the receipt subscription URL on the first reading.
> * I agree with Peter that clarifying whether receipts are sent for TTL=0
> messages would be nice.
> * Does it make sense for the push server to use a 400-class status code in
> a receipt to report a nack? For example, if the UA failed to decrypt the
> message, or the app threw an exception. IIUC, the spec allows 204 for
> successful deliveries and 410 for expired messages, but it's not clear if
> the PS can send other statuses in receipts.
>

Would generate too much traffic and load, and would increase the
implementation costs. In some cases
the messages can be expired by the storage system, in batch - it wouldn't
be a problem if 'nack'
would be a rare case, but in mobile a very large number of devices (
tablets, etc ) are offline for
long time so nack would be very frequent.



>
> * I'm also curious to hear implementer feedback about receipts in general.
>


>
> In section 5.4...
>
> * Could we restrict the `Topic` grammar to just `token`? ISTM base64url
> already fits this definition.
> * 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).
>

One thing to keep in mind is that some PS may use nosql and be distributed
and use eventual consistency.
Messages have a timestamp, so either they will be collapsed, or both will
be sent. If the new one has shorter
TTL, it may get lost.


>
> In section 6, are non-zero `wait` values allowed? (I'm assuming not, since
> the UA can disconnect at any time).
>
> In section 6.2...
>
> * 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?)
>

Batch acks would be useful, but with resource URL it's trickier. If ACK
would be implemented at lower level it may be possible
( i.e. UA would ack the H2 stream IDs of the messages ), but it's an
optimization that can be done later.

I expect PS will re-deliver on the next connection or monitor request.


> * Can a UA "nack" a message, or would this be implementation-specific?
> (Related to my note above about reporting nacks to the AS in the receipt
> subscription).
>

It would add costs to the PS, and I don't think it's a common use case. To
'nack', the UA needs to first get the message to know the ID.


>
> 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.
>

+1

Costin


>
> In section 7.3.1, if the UA deletes a subscription that belongs to a
> subscription set, does it receive a 410 for the deleted subscription on the
> subscription set stream?
>




>
> Cheers,
> - kit
>
> _______________________________________________
> Webpush mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webpush
>