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

From: Alissa Cooper <[email-masked]>
Date: Wed, 21 Sep 2016 23:25:33 -0400

I have reviewed this document in preparation for IETF last call. It is almost ready to go. I have a few comments below. Once these are resolved and a rev published, I will request publication.

= Shepherd write-up =

RFC 2818 is in the downref registry already. That is the only explanation necessary for the downref.

= Section 5.3 =

I'm assuming the application scenarios listed in the table are illustrative since they do not cover every possible application. It would be good to note that.

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

= Section 8 =

I think the first paragraph should include a normative recommendation to follow the guidance in RFC 7525 for use of TLS.

= Section 8.2 =

I think it would be useful to acknowledge in this section that while correlation using push URIs can be limited in the various ways described, correlation based on other information exposed by user agents may still be possible.

= Section 9.3 =

The Contact should be IETF Chair (per RFC 6335).

---

From: Martin Thomson <[email-masked]>
Date: Fri, 23 Sep 2016 14:54:09 +1000

Thanks for reviewing Alissa,

The other comments look like they have mechanical fixes.  We will get to that.

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Sep 2016 14:48:37 +1000

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/

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 26 Sep 2016 13:49:59 -0400

LGTM

> On Sep 26, 2016, at 12:48 AM, Martin Thomson <[email-masked]> wrote:
>

---

From: Brian Raymor <[email-masked]>
Date: Mon, 26 Sep 2016 21:54:30 +0000

I've merged Martin's PR, updated the change log, and published webpush-10.

-----Original Message-----
From: Webpush [mailto:[email-masked]] On Behalf Of Alissa Cooper
Sent: Monday, September 26, 2016 6:50 PM
To: Martin Thomson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Webpush] AD evaluation: draft-ietf-webpush-protocol-09

LGTM

>> messages SHOULD be suppressed.

_______________________________________________
Webpush mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/webpush