Original text:
A push message replacement request creates a new push message resource and simultaneously deletes any existing message resource <del> that has a matching topic.  Delivery receipts for the deleted message SHOULD be suppressed. </del>  The replacement request also replaces the stored TTL, Urgency, and any receipt subscription associated with the previous message in the 8. <del> 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. </del>  Applications using this protocol MUST use mechanisms that provide confidentiality, integrity and data origin authentication.  The 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 <del> across different applications, or over time. </del>  Similarly, the URIs provided by the push service to identify a push message MUST NOT provide any information that allows for correlation tcp <del> IESG (iesg@ietf.org) </del>  <del> The Web Push WG (webpush@ietf.org) </del>  HTTP Web Push

Reviewer comments:
This attempts to address all of the issues identified during AD review: URL 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).

Revised text:
A push message replacement request creates a new push message resource and simultaneously deletes any existing message resource  <ins> 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. </ins> The replacement request also replaces the stored TTL, Urgency, and any receipt subscription associated with the previous message in the 8.  <ins> 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. </ins> Applications using this protocol MUST use mechanisms that provide confidentiality, integrity and data origin authentication.  The 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  <ins> across different applications, or over time.  Of course, this does not prevent correlation using other information that a user agent might expose. </ins> Similarly, the URIs provided by the push service to identify a push message MUST NOT provide any information that allows for correlation tcp  <ins> The IESG (iesg@ietf.org) </ins>  <ins> The IETF Chair (chair@ietf.org) </ins> HTTP Web Push