Subject: [Webpush] Alexey Melnikov's Yes on draft-ietf-webpush-protocol-12: (with COMMENT)

From: "Alexey Melnikov" <[email-masked]>
Date: Sat, 22 Oct 2016 10:40:03 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-webpush-protocol-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing my DISCUSS points.

I haven't checked whether you addressed all of my earlier comments:

1) <This comment was replied to. Withdrawn.>

2) In 4.1:

Can 429 be used when no subscription set is specified? (If yes, this
should be mentioned in section 4).

3) <Addressed>

4) In general case it is not possible to achieve message reliability
because a push server is allowed to expire messages after they were
accepted for delivery due to overload. (Similarly for forced subscription
expiration.) I don't think the document makes this clear in Section 7.4.

5) <This comment was replied to. Withdrawn.>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Oct 2016 10:54:24 +1100

> should be mentioned in section 4).

The document says:

   A push service
   MAY return a 429 (Too Many Requests) status code [RFC6585] to reject
   requests which omit a subscription set.

That's in Section 4.1:
https://tools.ietf.org/html/draft-ietf-webpush-protocol-12#section-4.1
I believe that to be sufficient.

> expiration.) I don't think the document makes this clear in Section 7.4.

I realize that I dropped this somehow.  I made a PR, but then Brian
corrected me.  The push service is required to provide a negative
acknowledgment if it drops a push message before the TTL period ends:

   The push service MAY cease to retry delivery of the message prior to
   its advertised expiration due to scenarios such as an unresponsive
   user agent or operational constraints.  If the application has
   requested a delivery receipt, then the push service MUST return a 410
   (Gone) response to the application server monitoring the receipt
   subscription.

Section 6.2: https://tools.ietf.org/html/draft-ietf-webpush-protocol-12#section-6.2