jiebi/CodeConvo huggingface dataset:
%%% Key Exchange Messages This field contains the version of TLS negotiated for this <del> session.  Servers MUST select the lower of the highest supported server version and the version offered by the client in the ClientHello.  In particular, servers MUST accept ClientHello messages with versions higher than those supported and negotiate the highest mutually supported version.  For this version of the specification, the version is 0x0304.  (See backward-compatibility for details about backward compatibility.) </del> <ins> session.  Servers MUST select a version from the list in ClientHello.supported_versions extension.  A client which receives a version that was not offered MUST abort the handshake.  For this version of the specification, the version is 0x0304.  (See backward-compatibility for details about backward compatibility.) </ins> This structure is generated by the server and MUST be generated independently of the ClientHello.random.
otherwise, a TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 cipher <del> suites. </del> <ins> suites. (see cipher-suites) </ins> A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
The client uses the "signature_algorithms" extension to indicate to the server which signature algorithms may be used in digital <del> signatures.  Clients which desire the server to authenticate via a certificate MUST send this extension.  If a server is authenticating via a certificate and the client has not sent a </del> <ins> signatures.  Clients which desire the server to authenticate itself via a certificate MUST send this extension.  If a server is authenticating via a certificate and the client has not sent a </ins> "signature_algorithms" extension then the server MUST abort the handshake with a "missing_extension" alert (see mti-extensions).
prevents passive observers from correlating sessions unless tickets are reused.  Note: because ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even <del> in milliseconds.  External tickets SHOULD use an obfuscated_ticket_age of 0; servers MUST ignore this value for external tickets. </del> <ins> in milliseconds.  For identities established externally an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value. </ins> A list of the identities that the client is willing to negotiate with the server.  If sent alongside the "early_data" extension
length of the digest output.  This codepoint is also defined for use with TLS 1.2. <del> Indicates a signature algorithm using EdDSA as defined in I- D.irtf-cfrg-eddsa or its successors.  Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants. </del> <ins> Indicates a signature algorithm using EdDSA as defined in RFC8032 or its successors.  Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants. </ins> rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered. Clients offering these values for backwards compatibility MUST list
suites to the registry.  The "Value" and "Description" columns are taken from the table.  The "DTLS-OK" and "Recommended" columns are both marked as "Yes" for each new cipher suite.  [[This assumes I- <del> D.sandj-tls-iana-registry-updates has been applied.]] </del> <ins> D.ietf-tls-iana-registry-updates has been applied.]] </ins> TLS ContentType Registry: Future values are allocated via Standards Action RFC5226.
"encrypted_extensions", "end_of_early_data", "key_update", and "handshake_hash" values. <del> This document also uses a registry originally created in RFC4366. IANA has updated it to reference this document.  The registry and its allocation policy is listed below: </del> <ins> This document also uses the TLS ExtensionType Registry originally created in RFC4366.  IANA has updated it to reference this document. The registry and its allocation policy is listed below: </ins> IANA [SHALL update/has updated] this registry to include the "key_share", "pre_shared_key", "psk_key_exchange_modes",
authorities). Servers which are authenticating with a PSK MUST NOT send the <del> CertificateRequest message. </del> <ins> CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see post-handshake- authentication) provided that the client has sent the "post_handshake_auth" extension (see post_handshake_auth). </ins> 4.3.2.1.
candidates, such as STUN and TURN. All of the candidates sent within an ICE session; these are the <del> candidates that are associated with a local/remote ufrag pair (which will change on ICE restart, if any). </del> <ins> candidates that are associated with a specific local/remote ufrag pair (which will change on ICE restart, if any occurs). </ins> Any session-related (as opposed to candidate-related) attributes required to configure an ICE agent.  These include but are not
Once the candidate has been sent to the remote party, the agent checks if any remote candidates are currently known for this same <del> stream.  If not, the new candidate will simply be added to the list of local candidates. </del> <ins> stream and component.  If not, the new candidate will simply be added to the list of local candidates. </ins> Otherwise, if the agent has already learned of one or more remote candidates for this stream and component, it will begin pairing the
Working Groups might integrate the capabilities provided by GitHub into their processes for developing Internet-Drafts. <del> This document is meant as an supplement to existing Working Group </del> <ins> This document is meant as a supplement to existing Working Group </ins> practices.  It provides guidance to Working Group chairs and participants on how they can best use GitHub within the framework <del> established RFC 2418 RFC2418.  The small number of rules in this </del> <ins> established by RFC 2418 RFC2418.  The small number of rules in this </ins> document are there to ensure common usage patterns between working groups and to avoid issues that have been encountered in the past. A companion document, GH-CONFIG, describes administrative processes <del> that supports the practices described in this document. </del> <ins> that support the practices described in this document. </ins> 1.1.
the only possible choice for hosting.  There are other services that host revision control repositories and provide similar additional features to GitHub.  For instance, BitBucket [4], or GitLab [5] <del> provide a similar feature set.  In additional to a hosted service, </del> <ins> provide a similar feature set.  In addition to a hosted service, </ins> software for custom installations exists. This document concentrates primarily on GitHub as it has a large and
3. <del> A Working Group Chairs are responsible for determining how to best </del> <ins> Working Group Chairs are responsible for determining how to best </ins> accomplish the Charter in an open and transparent fashion.  The Working Group Chairs are responsible for determining if there is interest in using GitHub and making a consensus call to determine if <del> a the proposed policy and use is acceptable. </del> <ins> the proposed policy and use is acceptable. </ins> <del> Chairs MUST involve Area Directors any decision to use GitHub for anything more than managing of drafts. </del> <ins> Chairs MUST involve Area Directors in any decision to use GitHub for anything more than managing drafts. </ins> While a document editor can still use GitHub independently for documents that they edit, even if the working group does not
One common practice is to use these continuous integration services to build a text or HTML version of a document.  This is then published to GitHub Pages, which allows users to view a version of <del> the most recent revision of a document.  Including prominent link to this version of the document (such as in the README) makes it easier for new contributors to find a readable copy of the most recent version of a draft. </del> <ins> the most recent revision of a document.  Including a prominent link to this version of the document (such as in the README) makes it easier for new contributors to find a readable copy of the most recent version of a draft. </ins> Continuous integration can also validate pull requests and other changes for errors.  The most basic check is whether the source file <del> can be transformed successful into a valid Internet-Draft.  For </del> <ins> can be transformed successfully into a valid Internet-Draft.  For </ins> example, this might include checking that XML source is syntactically correct. <del> For documents that use formal languages a part of specifications, such as schema or source code, a continuous integration system might also be used to validate any formal language that the document contains.  Tests for any source code that the document contains might be run, or examples might be checked for correctness. </del> <ins> For a document that use formal languages as part of the specification, such as schema or source code, a continuous integration system might also be used to validate any formal language that the document contains.  Tests for any source code that the document contains might be run, or examples might be checked for correctness. </ins> 8.
If a contributor makes a comment that raises what you believe to be a new issue, create an issue for them.  If the issue has an obvious solution, consider creating a pull request.  It doesn't matter what <del> venue the issue was raised in, email, issue discussion, a pull request review, capturing issues quickly ensures that problems become visible and can be tracked. </del> <ins> venue the issue was raised in (e.g., email, issue discussion, a pull request review); capturing issues quickly ensures that problems become visible and can be tracked. </ins> This takes a little more effort, but these simple steps can help encourage contributions, which will ultimately improve the quality of
Group will rely upon.  features contains a more thorough discussion on the different features that can be used. <del> Once a document is published in a repository on GitHub, many features like pull requests, issue tracking or the wiki can be individually disabled.  If specific features are not used by the Working Group in the development of the document, disabling those features avoids creating confusion in the wider community about what can be used. </del> 3.2. Working Group Chairs that decide to use GitHub MUST inform their
that new contributors need.  A link to the CONTRIBUTING file from the README is advised. <ins> The set of GitHub features (features) that the Working Group relies upon need to be clearly documented in policies.  This document provides some guidance on potential policies and how those might be applied. Features that the Working Group does not rely upon SHOULD be made available to document editors.  Editors are then able to use these features for their own purposes.  For example, though the Working Group might not formally use issues to track items that require further discussion in order to reach consensus, keeping the issue tracker available to editors can be valuable. Working Group policies need to be set with the goal of improving transparency, participation, and ultimately the quality of the consensus behind documents.  At times, it might be appropriate to impose some limitations on what document editors are able to do in order to serve these goals.  Chairs SHOULD periodically consult with document editors to ensure that policies are effective and not unjustifiably constraining progress. </ins> 3.3. New repositories can be created within the Working Group organization
sufficient, though it might be helpful to occasionally remind new contributors of these guidelines. <del> A choice to use GitHub is similar to the formation of a design team (see Section 6.5 of RFC2418) provided that the work uses a public repository.  That is, the output of any activity using GitHub needs to be taken to the Working Group mailing list and subject to approval, rejection, or modification by the Working Group as with any other input. </del> Working Group Chairs are responsible for ensuring that any policy they adopt is enforced and maintained.
discovered.  Such elements may include classes of data, major roles, and role interactions.  This scenario also informs protocol and data model development in support of vulnerability assessment, as part of <del> overall posture assessment.  Vulnerability discovery, disclosure, and publication is out of scope. </del> <ins> overall posture assessment (see implementation-examples for examples of solutions that support this scenario). Vulnerability discovery, disclosure, publication, and prioritization is out of scope.  However, given the importance of prioritization in an enterprise's vulnerability assessment process, it is discussed in priority. Information on how the scenario aligns with SACM and other existing work is discussed in sacm-usage-scenarios through alignment-with- other-existing-works. </ins> 2.
value MUST be less than or equal to the value provided by the application server. <ins> 6.3. A push message that has been stored by the push service can be replaced with new content.  If the user agent is offline during the time that the push messages are sent, updating a push message avoids the situation where obsolete or redundant messages are sent to the user agent. Only push messages that have been assigned a topic can be updated.  A push message with a topic replaces any outstanding push message with an identical topic. A push message topic is a string.  A topic is carried in a Topic header field.  A topic is used to correlate push messages sent to the same subscription, it does not convey any other semantics. The grammar for the Topic header field uses the "token" and "quoted- string" rules defined in RFC7230. Any double quotes from the "quoted-string" form are removed before comparing topics for equality. For use with this protocol, the Topic header field MUST be restricted to no more than 32 characters from the URL- and filename-safe base64 set [RFC4648].  A push service that receives a request with a Token header field that does not meet these constraints SHOULD return an HTTP 400 (Bad Request) status code to an application server. A push message request creates a new push message resource, but simultaneously deletes any existing message resource that has a matching topic.  In effect, the information that is stored for the push message is updated, but a new resource is created to avoid problems with in flight acknowledgments for the old message.  The push service MAY suppress acknowledgement receipts for the replaced message. This mechanism doesn't allow for stored push messages to be deleted. An application server can remove a push message using a DELETE request to the push message URL. A push message with a topic that has a zero or absent time-to-live will cause a stored message with the same topic to be removed as well as not being stored itself, but the push service will attempt to forward the updated message to the user agent. A push message with a topic that is not shared by an outstanding message to the same subscription is stored or delivered as normal. The value of the Topic header field MUST NOT be forwarded to user agents.  Its value is not encrypted or authenticated. </ins> 7. A user agent requests the delivery of new push messages by making a
push messages to the user agent.  Flow control SHOULD be used to limit the state commitment for delivery of large messages. <ins> 5.1. A push service can improve the reliability of push message delivery considerably by storing push messages for a period.  User agents are often only intermittendly connected, and so benefit from having short term message storage at the push service. Delaying delivery might also be used to batch communication with the user agent, thereby conserving radio resources. Some push messages are not useful once a certain period of time elapses.  Delivery of messages after they have ceased to be relevant is wasteful.  For example, if the push message contains a call notification, receiving a message after the caller has abandoned the call is of no value; the application at the user agent is forced to suppress the message so that it does not generate a useless alert. An application server can use the TTL header field to limit the time that a push message is retained by a push service.  The TTL header field contains a value in seconds that describes how long a push message is retained by the push service. Once the TTL period elapses, the push service MUST remove the push message and cease any attempt to deliver it to the user agent.  A push service might retain values for a short duration after the TTL period to account for time accounting errors in processing.  For instance, distributing a push message within a server cluster might accrue errors due to clock variation, or processing and transit delays. A push service is not obligated to account for time spent by the application server in sending a push message to the push service, or delays incurred while sending a push message to the user agent.  An application server needs to account for transit delays in selecting a TTL header field value. Absence of the TTL header field is interpreted as equivalent to a zero value.  Push messages with a zero TTL indicate that storage is not needed and that the message can be dropped if the user agent isn't immediately available to receive the message.  Push messages with a zero TTL can be delivered very efficiently. A push service MAY choose to retain a push message for a shorter duration than that requested.  It indicates this by including a TTL header field in the response that includes the actual TTL.  This TTL value MUST be less than or equal to the value provided by the application server. </ins> 6. A user agent requests the delivery of new push messages by making a
7.2. <del> Push services typically store messages for some time to allow for limited recovery from transient faults.  If a push message is stored, but not delivered, the push service can indicate the probable duration of storage by including expiration information in the response to the push request. </del> <ins> Storage of push messages based on the TTL header field comprises a potentially significant amount of storage for a push service.  A push service is not obligated to store messages indefinitely.  A push service is able to indicate how long it intends to retain a message to an application server using the TTL header field (see ttl). </ins> <del> A push service is not obligated to store messages indefinitely.  If a user agent is not actively monitoring for push messages, those messages can be lost or overridden by newer messages on the same subscription. </del> <ins> A user agent that does not actively monitor for push messages will not receive messages that expire during that interval. </ins> <del> Push messages that were stored and not delivered to a user agent are </del> <ins> Push messages that are stored and not delivered to a user agent are </ins> delivered when the user agent recommences monitoring.  Stored push messages SHOULD include a Last-Modified header field (see Section 2.2 of RFC7232) indicating when delivery was requested by an application
Push services might need to limit the size and number of stored push messages to avoid overloading.  In addition to using the 413 (Payload Too Large) status code for too large push messages, a push service <del> MAY expire push messages prior to any advertised expiration time. </del> <ins> MAY expire push messages prior to any advertised expiration time.  A push service can reduce the impact push message retention by reducing the time-to-live of push messages. </ins> 7.3.
9. <ins> This protocol defines new HTTP header fields in iana.header.fields. New link relation types are identified using the URNs defined in iana.urns. 9.1. HTTP header fields are registered within the "Message Headers" registry maintained at <https://www.iana.org/assignments/message- headers/>. This document defines the following HTTP header fields, so their associated registry entries shall be added according to the permanent registrations below (see RFC3864): The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". 9.2. </ins> This document registers three URNs for use in identifying link relation types.  These are added to a new "Web Push Identifiers" registry according to the procedures in Section 4 of RFC3553; the
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 application server sending the push message and the application on the user agent that receives it are frequently just different instances of the same application, so no standardized protocol is needed to establish a proper security context.  The distribution of subscription information from the user agent to its application server also offers a convenient medium for key agreement. </ins> 8.1. The protection afforded by TLS does not protect content from the push <del> service.  Without additional safeguards, a push service is able to see and modify the content of the messages. Applications are able to provide additional confidentiality, integrity or authentication mechanisms within the push message itself.  The application server sending the push message and the application on the user agent that receives it are frequently just different instances of the same application, so no standardized protocol is needed to establish a proper security context.  The process of providing the application server with subscription information provides a convenient medium for key agreement. The Web Push API codifies this practice by requiring that each push subscription created by the browser be bound to a browser generated encryption key.  Pushed messages are authenticated and decrypted by the browser before delivery to applications.  This scheme ensures that the push service is unable to examine the contents of push messages. The public key for a subscription ensures that applications using that subscription can identify messages from unknown sources and discard them.  This depends on the public key only being disclosed to entities that are authorized to send messages on the channel.  The push service does not require access to this public key. </del> <ins> service.  Without additional safeguards, a push service can inspect and modify the message content. For its requirements, the API has adopted I-D.ietf-webpush-encryption to secure the content of messages from the push service.  Other scenarios can be addressed by similar policies. </ins> The Topic header field exposes information that allows more granular correlation of push messages on the same subject.  This might be used