jiebi/CodeConvo huggingface dataset:
which the lookup client relies on the RD.  To avoid the limitations, RD applications should consider prescribing that lookup clients only use the discovered information as hints, and describe which pieces of <del> information need to be verified with the server because they impact the application's security. </del> <ins> information need to be verified because they impact the application's security.  A straightforward way to verify such information is to request it again from an authorized server, typically the one that hosts the target resource.  That similar to what happens in discovery when the URI discovery step is repeated. </ins> 7.3.
format payload to register. The registrant-ep includes the same registration parameters in the <del> POST request as it would per registration.  The registration base URI of the registration is taken from the registrant-ep's network address (as is default with regular registrations). </del> <ins> POST request as it would with a regular registration per registration.  The registration base URI of the registration is taken from the registrant-ep's network address (as is default with regular registrations). </ins> Example request from registrant-EP to RD (unanswered until the next step):
If the client's credentials indicate any subject name that is certified by any authority which the RD recognizes (which may be <del> the system's trust anchor store), all those subject names are </del> <ins> the system's trust anchor store), all such subject names are </ins> stored.  With CWT or JWT based credentials (as common with ACE), the Subject (sub) claim is stored as a single name, if it exists. With X.509 certificates, the Common Name (CN) and the complete
operations on a registration. After the initial registration, the registering endpoint retains the <del> returned location of the Registration Resource for further </del> <ins> returned location of the registration resource for further </ins> operations, including refreshing the registration in order to extend the lifetime and "keep-alive" the registration.  When the lifetime of the registration has expired, the RD SHOULD NOT respond to discovery queries concerning this endpoint.  The RD SHOULD continue to provide <del> access to the Registration Resource after a registration time-out </del> <ins> access to the registration resource after a registration time-out </ins> occurs in order to enable the registering endpoint to eventually refresh the registration.  The RD MAY eventually remove the registration resource for the purpose of garbage collection.  If the <del> Registration Resource is removed, the corresponding endpoint will </del> <ins> registration resource is removed, the corresponding endpoint will </ins> need to be re-registered. <del> The Registration Resource may also be used cancel the registration </del> <ins> The registration resource may also be used cancel the registration </ins> using DELETE, and to perform further operations beyond the scope of this specification. <del> Operations on the Registration Resource are sensitive to reordering; </del> <ins> Operations on the registration resource are sensitive to reordering; </ins> freshness describes how order is restored. <del> The operations on the Registration Resource are described below. </del> <ins> The operations on the registration resource are described below. </ins> 5.3.1.
victim's /.well-known/core content in the RD.  Mitigation for this is recommended in simple. <del> The Registration Resource path is visible to any client that is </del> <ins> The registration resource path is visible to any client that is </ins> allowed endpoint lookup, and can be extracted by resource lookup clients as well.  The same goes for registration attributes that are shown as target attributes or lookup attributes.  The RD needs to <del> consider this in the choice of Registration Resource paths, and </del> <ins> consider this in the choice of registration resource paths, and </ins> administrators or endpoint in their choice of attributes. 8.3.
the connection, the session is terminated. Trade-offs: RST Packet Injection has a few advantages that make it <del> extremely popular is a censorship technique.  RST Packet Injection is </del> <ins> extremely popular as a censorship technique.  RST Packet Injection is </ins> an out-of-band prevention mechanism, allowing the avoidance of the the QoS bottleneck one can encounter with inline techniques such as Packet Dropping.  This out-of-band property allows a censor to
interference.  Prescription is the process by which censors determine what types of material they should block, i.e. they decide to block a list of pornographic websites.  Identification is the process by <del> which censors classify specific traffic to be blocked or impaird, </del> <ins> which censors classify specific traffic to be blocked or impaired, </ins> i.e. the censor blocks or impairs all webpages containing "sex" in the title or traffic to sex.com.  Interference is the process by which the censor intercedes in communication and prevents access to
4.1. <ins> While other interference techniques outlined in this section mostly focus on blocking or preventing access to content, it can be an effective censorship strategy in some cases to not entirely block access to a given destination, or service but instead degrade the performance of the relevant network connection.  The resulting user experience for a site or service under performance degradation can be so bad that users opt to use a different site, service, or method of communication, or may not engage in communication at all if there are no alternatives.  Traffic shaping techniques that rate-limit the bandwidth available to certain types of traffic is one example of a performance degradation. Trade offs: While implementing a performance degradation will not always eliminate the ability of people to access a desire resource, it may force them to use other means of communication where censorship (or surveillance) is more easily accomplished. Empirical examples: Iran is known to shape the bandwidth available to HTTPS traffic to encourage unencrypted HTTP traffic Aryan-2012. 4.2. </ins> Packet dropping is a simple mechanism to prevent undesirable traffic. The censor identifies undesirable traffic and chooses to not properly forward any packets it sees associated with the traversing
can be physically seized or the hosting provider can be required to prevent access Anderson-2011. <ins> 6.4. In some countries, legal mechanisms exist where an individual can issue a legal request to a content host that requires the host to take down content.  Examples include the voluntary systems employed by companies like Google to comply with "Right to be Forgotten" policies in the European Union Google-RTBF and the copyright-oriented notice and takedown regime of the United States Digital Millennium Copyright Act (DMCA) Section 512 DMLP-512. </ins> 7. This document benefited from discussions with Stephane Bortzmeyer,
13.2. <del> In cases where ICE is used to establish some kind of session that is not real time, and has no fixed rate associated with it that is known to work on the network in which ICE is deployed, Ta and RTO revert to more conservative values.  Ta SHOULD be configurable, SHOULD have a default of 500 ms, and MUST NOT be configurable to be less than 500 ms. </del> <ins> ICE agents SHOULD use the default Ta value, 50 ms, but MAY use another value based on the characteristics of the associated media. ICE agents MUST NOT use a Ta value smaller than 5 ms. If an ICE agent wants to use another Ta value than the default value, the agent MUST indicate the proposed value to its peer during the ICE exchange.  Both agents MUST use the higher value of the proposed values.  If an agent does not propose a value, the default value is used for that agent when comparing which value is higher. NOTE: sec-concheckbw shows examples of required bandwidth, using different Ta values. </ins> <del> If other Ta value than the default is used, the agent MUST indicate the value it prefers to use in the ICE exchange.  Both agents MUST use the higher out of the two proposed values. </del> <ins> 13.3. </ins> <del> In addition, the retransmission timer for the STUN transactions, RTO, SHOULD be configurable and during the gathering phase, SHOULD have a default of: </del> <ins> During the ICE gathering phase, ICE agents SHOULD calculate the RTO value using the following formula: </ins> <del> where the number of pairs refers to the number of pairs of candidates with STUN or TURN servers. </del> <ins> For connectivity checks, ICE agents SHOULD calculate the RTO value using the following formula: </ins> <del> For connectivity checks, RTO SHOULD be configurable and SHOULD have a default of: </del> <ins> ICE agents MAY calculate the RTO value using other mechanisms than those described above.  ICE agents MUST NOT use a RTO value smaller than 500 ms. </ins> 14.
In order to limit the attacks described in sec-ice-hammer, an ICE agent MUST limit the total number of connectivity checks the agent <del> performs across all check lists to a specific value, and this value MUST be configurable.  A default of 100 is RECOMMENDED.  This limit is enforced by discarding the lower-priority candidate pairs until there are less than 100.  It is RECOMMENDED that a lower value be utilized when possible, set to the maximum number of plausible checks that might be seen in an actual deployment configuration.  The requirement for configuration is meant to provide a tool for fixing this value in the field if, once deployed, it is found to be problematic. </del> <ins> performs across all check lists in the check list set.  This is done by limiting the total number of candidate pairs in the check list set.  The default limit of candidate pairs for the check list set is 100, but the value MUST be configurable.  The limit is enforced by, within in each check list, discarding lower-priority candidate pairs until the total number of candidate pairs in the check list set is smaller than the limit value.  The discarding SHOULD be done evenly so that the number of candidate pairs in each check list is reduced the same amount. It is RECOMMENDED that a lower limit value than the default is picked when possible, and that the value is set to the maximum number of plausible candidate pairs that might be created in an actual deployment configuration.  The requirement for configuration is meant to provide a tool for fixing this value in the field if, once deployed, it is found to be problematic. </ins> 6.1.2.6.
22. <del> Following is the list of changes from RFC 5245 </del> <ins> The purpose of this updated ICE specification is to: </ins> <del> The specification was generalized to be more usable with any protocol and the parts that are specific to SIP and SDP were moved to a SIP/SDP usage document I-D.ietf-mmusic-ice-sip-sdp. </del> <ins> Clarify procedures in RFC 5245. </ins> <del> Default candidates, multiple components, ICE mismatch detection, subsequent offer/answer, and role conflict resolution were made optional since they are not needed with every protocol using ICE. </del> <ins> Make technical changes, due to discovered flows in RFC 5245 and based on feedback from the community that has implemented and deployed ICE applications based on RFC 5245. </ins> <del> With IPv6, the precedence rules of RFC 6724 are used instead of the obsoleted RFC 3483 and using address preferences provided by the host operating system is recommended. </del> <ins> Make the procedures signaling protocol independent, by removing the SIP and SDP procedures.  Procedures specific to a signaling protocol will be defined in separate usage documents.  I-D.ietf- mmusic-ice-sip-sdp defines the ICE usage with SIP and SDP. </ins> <del> Candidate gathering rules regarding loopback addresses and IPv6 addresses were clarified. </del> <ins> The following technical changes have been done: Aggressive nomination removed. The procedures for calculating candidate pair states and scheduling connectivity checks modified. Procedures for calculation of Ta and RTO modified. Active check list and frozen check list definitions removed. 'ice2' ice option added. IPv6 considerations modified. Usage with no-op for keepalives, and keepalives with non-ICE peers, removed. </ins>
multiple data channels between them. An implementation of the Interactive Connectivity Establishment <del> (ICE) I-D.ietf-ice-rfc5245bis protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166). </del> <ins> (ICE) RFC5245 protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166). </ins> Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another
browser MUST be able to communicate. When TURN is used, and the TURN server has IPv4 or IPv6 connectivity <del> to the peer or its TURN server, candidates of the appropriate types MUST be supported.  The "Happy Eyeballs" specification for ICE I- D.martinsen-mmusic-ice-dualstack-fairness SHOULD be supported. </del> <ins> to the peer or the peer's TURN server, candidates of the appropriate types MUST be supported.  The "Happy Eyeballs" specification for ICE I-D.ietf-mmusic-ice-dualstack-fairness SHOULD be supported. </ins> 3.3.
establishing UDP relay candidates using TURN over TCP to connect to their respective relay servers. <del> Third, using TCP only between the endpoint and its relay may result in less issues with TCP in regards to real-time constraints, e.g. due to head of line blocking. </del> <ins> Third, using TCP between the client's TURN server and the peer may result in more performance problems than using UDP, e.g. due to head of line blocking. </ins> ICE-TCP candidates RFC6544 MUST be supported; this may allow applications to communicate to peers with public IP addresses across
UDP-blocking firewalls without using a TURN server. If TCP connections are used, RTP framing according to RFC4571 MUST be <del> used, both for the RTP packets and for the DTLS packets used to carry data channels. </del> <ins> used for all packets.  This includes the RTP packets, DTLS packets used to carry data channels, and STUN connectivity check packets. </ins> The ALTERNATE-SERVER mechanism specified in RFC5389 (STUN) section 11 (300 Try Alternate) MUST be supported.
2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <del> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </del> <ins> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. </ins> 3.
authoritative IdPs, thus allowing the user to instantly grasp that the call is being authenticated by Facebook, Google, etc. <ins> 6.4.4.1. Because a broad range of characters are permitted in identity strings, it may be possible for attackers to craft identities which are confusable with other identities (see RFC6943 for more on this topic).  This is a problem with any identifier space of this type (e.g., e-mail addresses).  Those minting identifers should avoid mixed scripts and similar confusable characters.  Those presenting these identifiers to a user should consider highlighting cases of mixed script usage (see RFC5890, section 4.4).  Other best practices are still in development. </ins> 6.4.5. A number of optional Web security features have the potential to
11.3. The following registrations are done following the procedure <del> specified in RFC6838 and RFC7303. </del> <ins> specified in RFC6838 and RFC7303.  Clipboard formats are defined for the JSON and XML form of lists but do not make sense for streams or other formats. </ins> Note to RFC Editor - please remove this paragraph.  Note that a request for media type review for senml+json was sent to the media-
File extension(s): senml and sensml <ins> Windows Clipboard Name: "JSON Sensor Measurement List" for senml </ins> Macintosh file type code(s): none <ins> Macintosh Universal Type Identifier code: org.ietf.senml-json conforms to public.text for senml </ins> Person & email address to contact for further information: Cullen Jennings <fluffy@iii.ca>
File extension(s): senmlx and sensmlx <ins> Windows Clipboard Name: "XML Sensor Measurement List" for senmlx </ins> Macintosh file type code(s): none <ins> Macintosh Universal Type Identifier code: org.ietf.senml-xml conforms to publc.xml for senmlx </ins> Person & email address to contact for further information: Cullen Jennings <fluffy@iii.ca>
IANA will create a registry of SenML unit symbols.  The primary purpose of this registry is to make sure that symbols uniquely map to give type of measurement.  Definitions for many of these units can be <del> found in location such as NIST811 and BIPM. </del> <ins> found in location such as NIST811 and BIPM.  Units marked with an asterisk are NOT RECOMMENDED to be produced by new implementations, but are in active use and SHOULD be implemented by consumers that can use the related base units. </ins> Note 1: A value of 0.0 indicates the switch is off while 1.0 <del> indicates on and 0.5 would be half on. </del> <ins> indicates on and 0.5 would be half on.  The preferred name of this unit is "/".  For historical reasons, the name "%" is also provided for the same unit - but note that while that name strongly suggests a percentage (0..100) -- it is however NOT a percentage, but the absolute ratio! </ins> Note 2: Assumed to be in WGS84 unless another reference frame is known for the sensor.
single canonical representation outweighs the convenience of easy human representations or loss of precision in a conversion. <del> Use of SI prefixes such as "k" before the unit is not allowed. </del> <ins> Use of SI prefixes such as "k" before the unit is not recommended. </ins> Instead one can represent the value using scientific notation such <del> a 1.2e3.  TODO - Open Issue.  Some people would like to have SI prefixes to improve human readability. </del> <ins> a 1.2e3.  The "kg" unit is exception to this rule since it is an SI base unit; the "g" unit is provided for legacy compatibility. </ins> For a given type of measurement, there will only be one unit type defined.  So for length, meters are defined and other lengths such
Modification of the ciphertext can go undetected if authentication is not also used, which is the case when sending EnvelopedData without <del> wrapping it in SignedData or enclosing SignedData within it. </del> <ins> wrapping it in SignedData or enclosing SignedData within it.  This is one of the reasons for moving from EnvelopedData to AuthEnvelopedData as the authenticated encryption algorithms provide the authentication without needing the SignedData layer. </ins> If an implementation is concerned about compliance with National Institute of Standards and Technology (NIST) key size
the fact that the CEK is going to be known to both parties.  Thus the origination is always built on a presumption that "I did not send this message to myself." <ins> All of the authenticated encryption algorithms in this document use counter mode for the encryption portion of the algorithm.  This means that the length of the plain text will always be known as the cipher text length and the plain text length are always the same.  This information can enable passive observers to infer information based solely on the length of the message.  Applications for which this is a significant problem need to provide some type of padding algorithm so that the length of the message does not provide this information. </ins>
HTTPS, which effectively treats the Fronting Server as an HTTP Proxy. In this solution, the client establishes a TLS connection to the Fronting Server, and then issues an HTTP Connect request to the <del> Hidden Server.  This will effectively establish an end-to-end HTTPS over TLS connection between the client and the Hidden Server, mitigating the issues described in nocontextsharing. </del> <ins> Hidden Server.  This will establish an end-to-end HTTPS over TLS connection between the client and the Hidden Server, mitigating the issues described in nocontextsharing. </ins> The HTTPS in HTTPS solution requires double encryption of every packet.  It also requires that the fronting server decrypts and relay
a digital signature), multiple recipients, encryption of manifests (in comparison to firmware images).]] <ins> The following manifests examplify how to deliver the encrypted firmware and its encryption info to the Devices. The examples are signed using the following ECDSA secp256r1 key: The corresponding public key can be used to verify these examples: Each example uses SHA256 as the digest function. 9.1. Diagnostic notation of the SUIT Manifest: In hex: </ins> 10. The algorithms described in this document assume that the party
If an authenticator request is present, the extensions used to guide the construction of these messages are taken from the authenticator <del> request.  If the certificate_request_context from the authenticator request has already been used in the connection, then no authenticator should be constructed.  If there is no authenticator request, the extensions are chosen from the TLS handshake.  Only servers can provide an authenticator without a corresponding request. In such cases, ClientHello extensions are used to determine permissible extensions in the Certificate message. </del> <ins> request.  Unrecognized extensions MUST be ignored.  If the certificate_request_context from the authenticator request has already been used in the connection, then no authenticator should be constructed.  If there is no authenticator request, the extensions are chosen from the TLS handshake.  Only servers can provide an authenticator without a corresponding request.  In such cases, ClientHello extensions are used to determine permissible extensions in the Certificate message. </ins> 4.2.1.
understands and supports the extension, but some extensions do not require this acknowledgement. <ins> For a flag that does require a response, the only proper response is the same flag in a flags extension.  This extension MUST NOT be used to specify extensions where the response is a proper extension with content. </ins> A flag proposed by the client in ClientHello (CH) that requires acknowledgement SHOULD be acknowledged in either ServerHello (SH), in EncryptedExtensions (EE), in Certificate (CT), or in
entire certificate and the delegated credential, cannot. Each delegated credential is bound to a specific signature <del> algorithm for use use in the TLS handshake (RFC8446 section 4.2.3).  This prevents them from being used with other, perhaps unintended signature algorithms. </del> <ins> algorithm for use in the TLS handshake (RFC8446 section 4.2.3). This prevents them from being used with other, perhaps unintended signature algorithms.  The signature algorithm bound to the delegated credential can be chosen independantly of the set of signature algorithms supported by the end-entity certificate. </ins> 3.2.
rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and ed25519. <ins> TLS PskKeyExchangeMode Registry: Values with the first byte in the range 0-253 (decimal) are assigned via Specification Required RFC8126.  Values with the first byte 254 or 255 (decimal) are reserved for Private Use RFC8126.  This registry SHALL have a "Recommended" column.  The registry [shall be/ has been] initially populated psk_ke (0) and psk_dhe_ke (1).  Both SHALL be marked as "Recommended". </ins>
depend on the ServerHello and therefore has weaker guarantees. This is especially relevant if the data is authenticated either with TLS client authentication or inside the application protocol. <del> The same warnings apply to any use of the early_exporter_main_secret. </del> <ins> The same warnings apply to any use of the early_exporter_secret. </ins> 0-RTT data cannot be duplicated within a connection (i.e., the server will not process the same data twice for the same connection), and an