Draft: draft-ietf-webpush-protocol

Commentary: This attempts to address all of the issues identified during AD review :
Mailing list commentary: 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 . = 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 ) .
Paragraph (version A):
A push message replacement request creates a new push message
resource and simultaneously deletes any existing message resource
that has a matching topic.  Delivery receipts for the deleted message
SHOULD be suppressed.
Paragraph (version B):
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.
Paragraph (version A):
This protocol MUST use RFC2818.  This includes any communications
between user agent and push service, plus communications between the
application and the push service.  All URIs therefore use the "https"
scheme.  This provides confidentiality and integrity protection for
subscriptions and push messages from external parties.
Paragraph (version B):
This protocol MUST use RFC2818 following the recommendations in
RFC7525.  This includes any communications between user agent and
push service, plus communications between the application and the
push service.  All URIs therefore use the "https" scheme.  This
provides confidentiality and integrity protection for subscriptions
and push messages from external parties.
Paragraph (version A):
The URIs provided for push resources MUST NOT provide any basis to
correlate communications for a given user agent.  It MUST NOT be
possible to correlate any two push resource URIs based solely on
their contents.  This allows a user agent to control correlation
across different applications, or over time.
Paragraph (version B):
The URIs provided for push resources MUST NOT provide any basis to
correlate communications for a given user agent.  It MUST NOT be
possible to correlate any two push resource URIs based solely on
their contents.  This allows a user agent to control correlation
across different applications, or over time.  Of course, this does
not prevent correlation using other information that a user agent
might expose.