jiebi/CodeConvo huggingface dataset:
If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirect URI, the authorization server informs the client by adding the following <del> parameters to the query component of the redirect URI using the "application/x-www-form-urlencoded" format, per application-x-www- form-urlencoded: </del> <ins> parameters to the query component of the redirect URI as described by query-string-serialization: </ins> REQUIRED.  A single ASCII USASCII error code from the following:
This specification is designed for use with HTTP (RFC2616).  The use of OAuth over any protocol other than HTTP is out of scope. <del> The OAuth 1.0 protocol (RFC5849), published as an informational document, was the result of a small ad hoc community effort.  This Standards Track specification builds on the OAuth 1.0 deployment experience, as well as additional use cases and extensibility requirements gathered from the wider IETF community.  The OAuth 2.0 protocol is not backward compatible with OAuth 1.0.  The two versions may co-exist on the network, and implementations may choose to support both.  However, it is the intention of this specification that new implementations support OAuth 2.0 as specified in this document and that OAuth 1.0 is used only to support existing deployments.  The OAuth 2.0 protocol shares very few implementation details with the OAuth 1.0 protocol.  Implementers familiar with OAuth 1.0 should approach this document without any assumptions as to its structure and details. </del> <ins> Since the publication of the OAuth 2.0 Authorization Framework (RFC6749) in October 2012, it has been updated by OAuth 2.0 for Native Apps (RFC8252) and OAuth Security Best Current Practice (I- D.ietf-oauth-security-topics).  The OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC6750) has also been updated with (I-D.ietf-oauth-security-topics).  This Standards Track specification consolidates the information in all of these documents and removes features that have been found to be insecure in I-D.ietf-oauth- security-topics. </ins> 1.1.
otherwise, REQUIRED.  The scope of the access token as described by access-token-scope. <del> The parameters are included in the entity-body of the HTTP response using the "application/json" media type as defined by RFC7159.  The </del> <ins> The parameters are included in the payload of the HTTP response using the "application/json" media type as defined by RFC7159.  The </ins> parameters are serialized into a JavaScript Object Notation (JSON) structure by adding each parameter at the highest structure level. Parameter names and string values are included as JSON strings.
thus MUST NOT include characters outside the set %x21 / %x23-5B / %x5D-7E. <del> The parameters are included in the entity-body of the HTTP response using the "application/json" media type as defined by RFC7159.  The </del> <ins> The parameters are included in the payload of the HTTP response using the "application/json" media type as defined by RFC7159.  The </ins> parameters are serialized into a JSON structure by adding each parameter at the highest structure level.  Parameter names and string values are included as JSON strings.  Numerical values are included
7.2.1.2. <del> When sending the access token in the HTTP request entity-body, the client adds the access token to the request-body using the "access_token" parameter.  The client MUST NOT use this method unless all of the following conditions are met: </del> <ins> When sending the access token in the HTTP request payload, the client adds the access token to the request-body using the "access_token" parameter.  The client MUST NOT use this method unless all of the following conditions are met: </ins> The HTTP request entity-header includes the "Content-Type" header field set to "application/x-www-form-urlencoded". <del> The entity-body follows the encoding requirements of the "application/x-www-form-urlencoded" content-type as defined by HTML 4.01 W3C.REC-html401-19991224. </del> <ins> The payload follows the encoding requirements of the "application/ x-www-form-urlencoded" content-type as defined by HTML 4.01 W3C.REC-html401-19991224. </ins> <del> The HTTP request entity-body is single-part. </del> <ins> The HTTP request payload is single-part. </ins> <del> The content to be encoded in the entity-body MUST consist entirely of ASCII USASCII characters. </del> <ins> The content to be encoded in the payload MUST consist entirely of ASCII USASCII characters. </ins> The HTTP request method is one for which the request-body has defined semantics.  In particular, this means that the "GET" method MUST NOT be used. <del> The entity-body MAY include other request-specific parameters, in which case the "access_token" parameter MUST be properly separated from the request-specific parameters using "&" character(s) (ASCII code 38). </del> <ins> The payload MAY include other request-specific parameters, in which case the "access_token" parameter MUST be properly separated from the request-specific parameters using "&" character(s) (ASCII code 38). </ins> For example, the client makes the following HTTP request using transport-layer security:
(authorization server), which issues the printing service delegation- specific credentials (access token). <del> This specification is designed for use with HTTP (RFC7230).  The use of OAuth over any protocol other than HTTP is out of scope. </del> <ins> This specification is designed for use with HTTP (HTTP=RFC7231).  The use of OAuth over any protocol other than HTTP is out of scope. </ins> Since the publication of the OAuth 2.0 Authorization Framework (RFC6749) in October 2012, it has been updated by OAuth 2.0 for
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "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. </del> <ins> "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> This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234.  Additionally, the rule URI-reference is
2.4. <del> Confidential and credentialed clients establish a client authentication method with the authorization server suitable for the security requirements of the authorization server.  The authorization </del> <ins> If the client is confidential or credentialed, the authorization </ins> server MAY accept any form of client authentication meeting its <del> security requirements. Confidential and credentialed clients are typically issued (or establish) a set of client credentials used for authenticating with the authorization server (e.g., password, public/private key pair). </del> <ins> security requirements (e.g., password, public/private key pair). </ins> The authorization server MUST authenticate the client whenever possible.  If the authorization server cannot authenticate the client
3.2.1. <del> Confidential clients or other clients issued client credentials MUST authenticate with the authorization server as described in client- authentication when making requests to the token endpoint.  Client authentication is used for: </del> <ins> Confidential or credentialed clients MUST authenticate with the authorization server as described in client-authentication when making requests to the token endpoint.  Client authentication is used for: </ins> Enforcing the binding of refresh tokens and authorization codes to the client they were issued to.  Client authentication is critical
HTTP 401 (Unauthorized) status code.  The client MAY request a new access token and retry the protected resource request. <del> The request requires higher privileges than provided by the access token.  The resource server SHOULD respond with the HTTP 403 (Forbidden) status code and MAY include the "scope" attribute with the scope necessary to access the protected resource. </del> <ins> The request requires higher privileges (scopes) than provided by the scopes granted to the client and represented by the access token. The resource server SHOULD respond with the HTTP 403 (Forbidden) status code and MAY include the "scope" attribute with the scope necessary to access the protected resource. </ins> If the request lacks any authentication information (e.g., the client was unaware that authentication is necessary or attempted using an
Refresh tokens should either be sender-constrained or one-time use as per Section 4.12.2 of <ins> 10.1. The OAuth 2.0 Implicit grant is omitted from OAuth 2.1 as it was deprecated in I-D.ietf-oauth-security-topics. The intent of removing the Implicit grant is to no longer issue access tokens in the authorization response, as such tokens are vulnerable to leakage and injection, and are unable to be sender- constrained to a client.  This behavior was indicated by clients using the "response_type=token" parameter.  This value for the "response_type" parameter is no longer defined in OAuth 2.1. Removal of "response_type=token" does not have an effect on other extension response types returning other artifacts from the authorization endpoint, for example, "response_type=id_token" defined by OpenID. </ins> 11. This document does not require any IANA actions.
writing, there are no IETF standards for concurrent multipath congestion control in the general Internet. <ins> 5.9. Data centers are characterized by very low latencies (< 2 ms).  Many workloads involve bursty traffic where many nodes complete a task at the same time.  As a controlled environment, data centers often deploy fabrics that employ rich signalling from switches to endpoints.  Furthermore, the operator can often limit the number of operating congestion controls. For these reasons, data center congestion controls are often distinct from those running elsewhere on the Interenet.  A proposed congestion control need not coexist well with all other algorithms if it is intended for data centers, but the proposal SHOULD indicate which are expected to safely coexist with it. </ins> 6. This document does not represent a change to any aspect of the TCP/IP
algorithm would perform in the presence of transient events such as sudden onset of congestion, a routing change, or a mobility event. Routing changes, link disconnections, intermittent link connectivity, <del> and mobility are discussed in more detail in Section 17 of Tools. </del> <ins> and mobility are discussed in more detail in Section 16 of Tools. </ins> As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of RFC4782 (Quick-Start).
3.1.3. <ins> A congestion control algorithm should try to avoid causing excessively high rates of packet loss.  To accomplish this, it should avoid excessive increases in sending rate, and reduce its sending rate if experiencing high packet loss. The first version of the BBR algorithm BBRv1-draft failed this requirement.  Experimental evaluation BBRv1-Evaluation showed that it caused a sustained rate of packet loss when multiple BBRv1 flows shared a bottleneck and the buffer size was less than roughly one and a half BDP.  This kind of behavior needed to be fixed, and indeed further versions of BBR BBR-draft fixed this issue. This requirement does not imply that the algorithm should react to packet losses in exactly the same way as current standards-track congestion control algorithms (e.g., RFC5681). 3.1.4. </ins> When multiple competing flows all use the same proposed congestion control algorithm, the proposal should explore how the capacity is shared among the competing flows.  Capacity fairness can be important
In contexts where differing congestion control algorithms are used, it is important to understand whether the proposed congestion control <del> algorithm could result in more harm than previously defined algorithms to flows sharing a common bottleneck.  The measure of harm is not restricted to the equality of capacity, but ought also to consider metrics such as the introduced latency, or an increase in packet loss.  An evaluation must assess the potential to cause starvation, including assurance that a loss of all feedback (e.g., detected by expiry of a retransmission time out) results in backoff. </del> <ins> algorithm could result in more harm than previous standards-track algorithms (e.g.  RFC5681, RFC9002, RFC9438) to flows sharing a common bottleneck.  The measure of harm is not restricted to the equality of capacity, but ought also to consider metrics such as the introduced latency, or an increase in packet loss.  An evaluation must assess the potential to cause starvation, including assurance that a loss of all feedback (e.g., detected by expiry of a retransmission time out) results in backoff. </ins> 4.2.1.
simulate their interaction with those algorithms.  To the extent they are not, experiments can be conducted where possible. <del> Note that in many deployments, real-time flows are directed into distinct queues via Differentiated Services Code Points (DSCP) or other mechanisms, which substantially reduces the interplay with other traffic.  However, a proposal targeting general Internet use </del> <ins> Real-time flows can be directed into distinct queues via Differentiated Services Code Points (DSCP) or other mechanisms, which can substantially reduce the interplay with other traffic.  However, a proposal targeting general Internet use can not assume this is always the case. </ins> 4.2.3.
introduce bursty traffic where many nodes complete a task at the same time). <del> In evaluating a new proposal for use in a controlled environment, the IETF needs to understand the usage, e.g., how the usage is scoped to the controlled environment, whether the algorithm will share resources with Internet traffic and consider what could happen if used in a protocol that is bridged across an Internet path. Algorithms that are designed for special environments and are forbidden from use in the general Internet, might instead seek real- world data for those environments.  In such cases, the evaluation criteria in the remainder of this document might not apply. </del> <ins> In evaluating a new proposal for use in a controlled environment RFC8799, the IETF needs to understand the usage, e.g., how the usage is scoped to the controlled environment, whether the algorithm will share resources with Internet traffic and consider what could happen if used in a protocol that is bridged across an Internet path. Algorithms that are designed to be confined to a controlled environment and are not intended for use in the general Internet, might instead seek real-world data for those environments.  In such cases, the evaluation criteria in the remainder of this document might not apply. </ins> 4.
Informational RFC in 2017 RFC8312 and then as a Proposed Standard in 2023 RFC9438. <del> BBR is developed as an internal research project by Google, with the first implementation contributed to Linux kernel 4.19 in 2016.  It was described in an IRTF draft in 2018, and that draft is regularly updated to document the evolving versions of the algorithm BBR-draft. BBR is widely used for Google services using either TCP or QUIC, and is also widely deployed outside of Google. </del> <ins> At the time of writing, BBR is being developed as an internal research project by Google, with the first implementation contributed to Linux kernel 4.19 in 2016.  It was described in an IRTF draft in 2018, and that draft has been regularly updated to document the evolving versions of the algorithm BBR-draft.  BBR is currently widely used for Google services using either TCP or QUIC, and is also widely deployed outside of Google. </ins> We cannot say now whether the original authors of RFC5033 expected that developers would be somehow waiting for IETF review before widely deploying a new congestion control algorithm over the Internet, but the examples of Cubic and BBR teach us that deployment <del> of new algorithms is not in fact gated by publication of the </del> <ins> of new algorithms is not in fact gated by the publication of the </ins> algorithm as an RFC. Nevertheless, specifying congestion control algorithms has a number
specification can help multiple contributors align on a consensus change to the algorithm. <del> A specification that is accessible to anyone circumvents the issue that some implementors may be unable to read open source reference implementations due to the constraints of some open source licenses. </del> <ins> A specification that is accessible to anyone can circumvent the issue that some implementors may be unable to read open source reference implementations due to the constraints of some open source licenses. </ins> Beyond helping develop specific algorithm proposals, guidelines can also serve as a reminder to potential inventors and developers of the
proposals in this space. This document is meant to reduce the barriers to entry for new <del> congestion control work to the IETF.  As such, proponents ought not to interpret these criteria as a checklist of requirements before approaching the IETF.  Instead, proponents are encouraged to think about these issues beforehand, and have the willingness to do the work implied by the remainder of this document. </del> <ins> congestion control work to the IETF.  As such, proponents of new congestion control algorithms ought not to interpret these criteria as a checklist of requirements before approaching the IETF.  Instead, proponents are encouraged to think about these issues beforehand, and have the willingness to do the work implied by the remainder of this document. </ins> 2.
a proposal targeting general Internet use can not assume this is always the case. <ins> circuit-breakers describes the impact of network transport circuit breaker algorithms.  RFC8083 also defines a minimal set of RTP circuit breakers that operate across a path.  This identifies conditions under which a sender needs to stop transmitting media data to protect the network from excessive congestion.  It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. </ins> 4.2.3. The effect on short-lived and long-lived flows using other common
on a specific proposed congestion control algorithm - is out of scope of this document.  RFC7567 describes design considerations for AQMs. <ins> 6.1.1. Some equipment in the network use an automatic mechanism to continuously monitor the use of resources by a flow or aggregate set of flows RFC8084.  Such a network transport circuit breaker can automatically detect excessive congestion, and when detected, it can terminate (or significantly reduce the rate of) the flow(s).  A well- designed congestion control algorithm ought to react before the flow uses excessive resources and therefore will operate within the envelope set by network transport circuit breaker algorithms. </ins> 6.2. An Internet Path can include simple links, where the minimum delay is
might then have to buffer data until an assigned transmission opportunity or when the physical path changes (e.g., when the length of a wireless path changes, or the physical layer changes its mode of <del> operation).  Variation also arises when a higher priority diffserv traffic classic prompts the transmission by a lower class.  In these cases, the delay varies as a function of external factors and attempting to infer congestion from an increase in the delay results in reduced throughput.  The jitter from variation over short timescales might not be distinguishable similar from other effects. </del> <ins> operation).  Variation also arises when traffic with a higher priority diffserv class pre-empts transmission of traffic with a lower class.  In these cases, the delay varies as a function of external factors and attempting to infer congestion from an increase in the delay results in reduced throughput.  The jitter from variation over short timescales might not be distinguishable similar from other effects. </ins> A proposed congestion control algorithm SHOULD be evaluated to ensure their operation is robust when there is a significant change in the
operating congestion controls. For these reasons, data center congestion controls are often distinct <del> from those running elsewhere on the Interenet.  A proposed congestion control need not coexist well with all other algorithms if it is intended for data centers, but the proposal SHOULD indicate which are expected to safely coexist with it. </del> <ins> from those running elsewhere on the Interenet (see controlled- environments).  A proposed congestion control need not coexist well with all other algorithms if it is intended for data centers, but the proposal SHOULD indicate which are expected to safely coexist with it. </ins> 7.
Another example use is concurrent multipath, where the transport protocol simultaneously schedules flows to aggregate the capacity <del> across multiple paths.  The Internet provides no guarantee that different paths (e.g., using different endpoint addresses) are disjoint.  This has additional implications: A proposed congestion control algorithm MUST evaluate the potential harm to other flows when the multiple paths share a common congested bottleneck (or share resources that are coupled between different paths, such as an overall capacity limit), and SHOULD consider the potential for harm to other flows.  Synchronisation of congestion control mechanisms (e.g., where multiple flows change their behaviour on similar timeframes) can also contribute to harm and/or reduce fairness, these effects also ought to be evaluated.  At the time of writing, there are no IETF standards for concurrent multipath congestion control in the general Internet. </del> <ins> across multiple paths. The Internet provides no guarantee that different paths (e.g., using different endpoint addresses) are disjoint.  This has additional implications: A proposed congestion control algorithm MUST evaluate the potential harm to other flows when the multiple paths share a common congested bottleneck (or share resources that are coupled between different paths, such as an overall capacity limit), and SHOULD consider the potential for harm to other flows. Synchronisation of congestion control mechanisms (e.g., where multiple flows change their behaviour on similar timeframes) can also contribute to harm and/or reduce fairness, these effects also ought to be evaluated. At the time of writing, there are currently no Standards Track RFCs, but there is an Experimental RFC RFC6356 that specifies a concurrent multipath congestion control algorithm for TCP (MP-TCP). </ins> 6.9.
proceed with caution when evaluating proposals for alternate congestion control.  The goal of this document is to provide guidance for considering standardization of a proposed congestion control <del> algorithm at the IETF.  It replaces RFC5033 to reflect changes in the congestion control landscape. </del> <ins> algorithm at the IETF.  It obsoletes RFC5033 to reflect changes in the congestion control landscape. </ins> 1.