jiebi/CodeConvo huggingface dataset:
8.4. <del> Discarding unwanted messages at the user agent based on message authentication doesn't protect against a denial of service attack on the user agent.  Even a relatively small volume of push messages can cause battery-powered devices to exhaust power reserves. </del> <ins> A user agent can control where valid push messages originate by limiting the distribution of push URIs to authorized application servers.  Ensuring that push URIs are hard to guess ensures that only application servers that have received a push URI can use it. Push messages that are not successfully authenticated by the user agent will not be delivered, but this can present a denial of service risk.  Even a relatively small volume of push messages can cause battery-powered devices to exhaust power reserves. </ins> <del> An application can limit where valid push messages can originate by limiting the distribution of push URIs to authorized entities. Ensuring that push URIs are hard to guess ensures that only application servers that have been given a push URI can use it. </del> <ins> To address this case, the API has adopted I-D.ietf-webpush-vapid, which allows a user agent to restrict a subscription to a specific application server.  The push service can then identity and reject unwanted messages without contacting the user agent. </ins> A malicious application with a valid push URI could use the greater resources of a push service to mount a denial of service attack on a
A push service or user agent MAY also delete that receive too many push messages. <del> End-to-end confidentiality mechanisms, such as those in API, prevent an entity with a valid push message subscription URI from learning the contents of push messages.  Push messages that are not successfully authenticated will not be delivered by the API, but this can present a denial of service risk. Conversely, a push service is also able to deny service to user agents.  Intentional failure to deliver messages is difficult to distinguish from faults, which might occur due to transient network errors, interruptions in user agent availability, or genuine service outages. </del> <ins> A push service is also able to deny service to user agents. Intentional failure to deliver messages is difficult to distinguish from faults, which might occur due to transient network errors, interruptions in user agent availability, or genuine service outages. </ins> 8.5. <del> Server request logs can reveal subscription-related URIs.  Acquiring a push message 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 subscription-related URIs for the same user agent. Encrypted message contents are not revealed to the push service. Limitations on log retention and strong access control mechanisms can ensure that URIs are not learned by unauthorized entities. </del> <ins> Server request logs can reveal subscription-related URIs or relationships between subscription-related URIs for the same user agent.  Limitations on log retention and strong access control mechanisms can ensure that URIs are not revealed to unauthorized entities. </ins> 9.
2.1. If the application server wishes to provide contact details it MAY <del> include an "sub" (Subject) claim in the JWT.  The "sub" claim SHOULD </del> <ins> include a "sub" (Subject) claim in the JWT.  The "sub" claim SHOULD </ins> include a contact URI for the application server as either a "mailto:" (email) RFC6068 or an "https:" RFC2818 URI.
An application server requests the delivery of a push message as described in I-D.ietf-webpush-protocol.  If the application server wishes to self-identify, it includes an Authorization header field <del> with credentials that use the "WebPush" authentication scheme auth and a Crypto-Key header field that includes its public key key. </del> <ins> with credentials that use the "WebPush" authentication scheme (auth) and a Crypto-Key header field that includes its public key (key). </ins> Note that the header fields shown in ex-push don't include line wrapping.  Extra whitespace is added to meet formatting constraints.
clients and media servers, WHIP imposes the following restrictions regarding WebRTC usage: <del> Bothe the WHIP client and the media server SHALL use SDP bundle RFC8843.  The SDP offer created by the WHIP client must include the bundle-only attribute in all m-lines as per RFC8843.  Also, RTCP muxing SHALL be supported by both the WHIP client and the media server. </del> <ins> Both the the WHIP client and the WHIP endpoint SHALL use SDP bundle RFC8843.  Each "m=" section MUST be part of a single BUNDLE group. Hence, when a WHIP client sends an SDP offer, it MUST include a "bundle-only" attribute in each bundled "m=" section.  The WHIP client and the Media Server MUST support multiplexed media associated with the BUNDLE group as per RFC8843 section 9.  In addition, per RFC8843 the WHIP client and Media Server will use RTP/RTCP multiplexing for all bundled media.  The WHIP client and media server SHOULD include the "rtcp-mux-only" attribute in each bundled "m=" sections. </ins> When a WHIP client sends an SDP offer, it SHOULD insert an SDP "setup" attribute with an "actpass" attribute value, as defined in
server configuration on the responses to OPTIONS request sent to the WHIP endpoint URL before the POST request is sent. <ins> NOTE: Depending on the ICE Agent implementation, the WHIP client may need to call the setConfiguration method before calling the setLocalDespcription method with the local SDP offer in order to avoid having to perform an ICE restart for applying the updated STUN/ TURN server configuration on the next ICE gathering phase. </ins> The generation of the TURN server credentials may require performing a request to an external provider, which can both add latency to the OPTION request processing and increase the processing required to