Subject: [Webpush] Alexey Melnikov's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT)

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 12 Oct 2016 07:39:44 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-webpush-protocol-11: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is generally a well written document, but I have a small list of
issues (which should be easy to address) I would like to discuss before
recommending its approval for publication:

1) In 5.2: is there upper limit on the TTL? The ABNF doesn't restrict the
value, but it is important for interoperability

2) In 5.3: urgency is defined as a list of one or more values. The
description says that it defines the lowest value allowed. There is also
a sentence prohibiting multiple values. Why is this a set and how would
multiple values be interpreted?

3) In 6:

I don't know where the ":link" Pseudo-Header field came from. Can you
clarify where it is defined?

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

1)
I see you defined a new HTTP Header Field "Urgency". Can you reuse email
header field "Priority" instead (possibly extending it)
      Can be 'normal', 'urgent', or 'non-urgent' and can influence
      transmission speed and delivery.
?

2) In 4.1:

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

3) In 6.1: ":link" is included in the PUSH_PROMISE and not the HEADERS
block (when compared to section 6). Is this intentional or should one of
the examples be fixed?

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) In 9.3:

Contact: IETF Chair

- I think you should point to the WG mailing list or IESG as a whole.
IETF Chair has other things to do than answer questions about IANA port
registration :-).

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 12 Oct 2016 10:48:49 -0400

> On Oct 12, 2016, at 10:39 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> 5) In 9.3:
> 
> Contact: IETF Chair
> 

Actually IETF chair is the contact mandated by RFC 6335: https://tools.ietf.org/html/rfc6335#section-8.1 <https://tools.ietf.org/html/rfc6335#section-8.1>. Agree with your point but I had asked the authors to change this to conform to 6335.

Alissa

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 12 Oct 2016 15:54:15 +0100

On Wed, Oct 12, 2016, at 03:48 PM, Alissa Cooper wrote:
> Actually IETF chair is the contact mandated by RFC 6335:
> https://tools.ietf.org/html/rfc6335#section-8.1. Agree with your point
> but I had asked the authors to change this to conform to 6335.

Ah, Ok. So arguably my fault, as I was the responsible AD for RFC 6335
:-).

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Oct 2016 02:35:54 +1100

Hi Alexey,

Thanks for going through this so thoroughly.

Most of these are - as you say - trivial, and I have PRs for the
issues that you identified, see below.

> value, but it is important for interoperability

Magnus Westerlund noted the same problem, so we've cribbed some text
from other HTTP documents.  You can see the updated text here:
https://github.com/webpush-wg/webpush-protocol/pull/131

> multiple values be interpreted?

This was in keeping with providing a definition for the header field
that is consistent with other HTTP header fields, but I believe that
you are correct in that the list construction in the ABNF is a hazard
rather than a feature:
https://github.com/webpush-wg/webpush-protocol/pull/135

> clarify where it is defined?

Pure editorial error, it's a real header field, as in RFC 5988:
https://github.com/webpush-wg/webpush-protocol/pull/134

>       transmission speed and delivery.

The working group discussed this specifically and at some length.
Priority was actually one of my original proposals.  The concern is
that this is NOT a priority, but an urgency.  That the values are the
same is merely convenient.

> should be mentioned in section 4)

I think that I'd rather leave this to Section 4.1.  It follows the
text immediately. subsection of 4 anyway.

> block (when compared to section 6). Is this intentional or should one of

Yes, the link relation should be in the response, not the promise.  Thanks.

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

You are right, we mention this elsewhere, but not here:
https://github.com/webpush-wg/webpush-protocol/pull/136

> 5) In 9.3:

Alissa covered this already.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 13 Oct 2016 10:56:31 +0100

Your changes look good to me. Thank you!