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

["Alexey Melnikov" <[e-mail]>]

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