Original text:
is communicating and when they are communicating is protected. However, the amount of information that is exposed can be limited. <del> "Push" URIs MUST NOT provide any basis to correlate communications for a given user agent.  It MUST NOT be possible to correlate any two "push" URIs based solely on the content of the "push" URIs.  This allows a user agent to control correlation across different applications, or over time. </del>  <del> In particular, user and device information MUST NOT be exposed through the "push" URI. </del>  <del> In addition, "push" URIs established by the same user agent MUST NOT include any information that allows them to be correlated with the user agent. </del>  This need not be perfect as long as the resulting anonymity set (see RFC6973, Section 6.1.1) is sufficiently large.  A "push" URI Authorization for subscriptions is managed using "subscription" and "push" capability URLs (see CAP-URI).  A capability URL grants access <del> to a resource based solely on knowledge of the URL.  Capability URLs are used for their "easy onward sharing" and "easy client API" properties.  These make it possible to avoid relying on relationships between push services and application servers, with the protocols necessary to build and support those relationships. </del>  <del> A "subscription" or "push" URI therefore acts as a bearer token. Knowledge of the "subscription" URI implies authorization to either receive push messages or delete the subscription.  Knowledge of the "push" URI implies authorization to send push messages. </del>  Encoding a large amount of random entropy (at least 120 bits) in the path component ensures that it is difficult to successfully guess a <del> valid "subscription" or "push" URI. </del>  7.4. a "subscription" URI enables the receipt of messages or deletion of the subscription.  Acquiring a "push" URI permits the sending of push messages.  Logging could also reveal relationships between different <del> subscription-related URIs for the same user agent. </del>  Limitations on log retention and strong access control mechanisms can ensure that URIs are not learned by unauthorized entities.

Reviewer comments:
I realized that I hadn't done due diligence in adding the message URL. This should address that (I have hooks in here for acknowledgment too).

Revised text:
is communicating and when they are communicating is protected. However, the amount of information that is exposed can be limited.  <ins> 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" URIs based solely on their contents.  This allows a user agent to control correlation across different applications, or over time. </ins>  <ins> Similarly, the URIs provided by the push service to identify a push message MUST NOT provide any information that allows for correlation across subscriptions.  Push message URIs for the same subscription MAY contain information that would allow correlation with the associated subscription or other push messages for that subscription. </ins>  <ins> User and device information MUST NOT be exposed through a "push" or push message URI. In addition, "push" URIs established by the same user agent or push message URIs for the same subscription MUST NOT include any information that allows them to be correlated with the user agent. </ins> This need not be perfect as long as the resulting anonymity set (see RFC6973, Section 6.1.1) is sufficiently large.  A "push" URI Authorization for subscriptions is managed using "subscription" and "push" capability URLs (see CAP-URI).  A capability URL grants access  <ins> to a resource based solely on knowledge of the URL. Capability URLs are used for their "easy onward sharing" and "easy client API" properties.  These make it possible to avoid relying on relationships between push services and application servers, with the protocols necessary to build and support those relationships. </ins>  <ins> A "subscription", "push" or push message URI therefore acts as a bearer token.  Knowledge of a "subscription" URI implies authorization to either receive push messages or delete the subscription.  Knowledge of a "push" URI implies authorization to send push messages.  Knowledge of a push message URI allows for reading that specific message. </ins> Encoding a large amount of random entropy (at least 120 bits) in the path component ensures that it is difficult to successfully guess a  <ins> valid capability URL. </ins> 7.4. a "subscription" URI enables the receipt of messages or deletion of the subscription.  Acquiring a "push" URI permits the sending of push messages.  Logging could also reveal relationships between different  <ins> subscription-related URIs for the same user agent.  Encrypted message contents are not revealed to the push service. </ins> Limitations on log retention and strong access control mechanisms can ensure that URIs are not learned by unauthorized entities.