Re: [Webpush] AD evaluation: draft-ietf-webpush-protocol-09

[Alissa Cooper <[e-mail]>]

LGTM

> On Sep 26, 2016, at 12:48 AM, Martin Thomson <[e-mail]> wrote:
> 
> I've create a pull request that includes the text below, plus fixes to
> the other identified issues:
> 
> https://github.com/webpush-wg/webpush-protocol/pull/128
> 
> Preview at: https://webpush-wg.github.io/webpush-protocol/alissa_review/
> 
> On 23 September 2016 at 14:54, Martin Thomson <[e-mail]> wrote:
>> Thanks for reviewing Alissa,
>> 
>> The other comments look like they have mechanical fixes.  We will get to that.
>> 
>> On 22 September 2016 at 13:25, Alissa Cooper <[e-mail]> wrote:
>>> = Section 5.4 =
>>> 
>>> "Delivery receipts for the deleted message
>>>   SHOULD be suppressed."
>>> 
>>> Why is this a SHOULD rather than a MUST? It seems incorrect in all cases to send a delivery receipt for a message that never gets delivered.
>> 
>> I realize that this is actually too short to be comprehensible.  What
>> I think that this was trying to capture was that sometimes replaced
>> messages might be delivered successfully, but the acknowledgment might
>> be still in transit toward the server.  That acknowledgement could
>> trigger a delivery receipt.
>> 
>> This recommends that receipts be suppressed in this case.  They might
>> not be given the distributed nature of the push service.
>> (Acknowledgments might be handled in a stateless fashion, and checking
>> that a replacement has occurred can be expensive; preventing the race
>> adds cost and latency also.)
>> 
>>>>> 
>> A push message replacement request creates a new push message resource
>> and simultaneously deletes any existing message resource that has a
>> matching topic. If an attempt was made to deliver the deleted push
>> message, an acknowledgment could arrive at the push service after the
>> push message has been replaced.  Delivery receipts for such deleted
>> messages SHOULD be suppressed.
>> <<<