jiebi/CodeConvo huggingface dataset:
Code change:
This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM

Related discussion:
text: metadata document (RFC8414) and fetched programmatically at runtime. The token endpoint URL MUST NOT include a fragment component, and MAY <del> include an "application/x-www-form-urlencoded" formatted query component (WHATWG.URL). </del> <ins> include a query string component query-string-serialization. </ins> The client MUST use the HTTP "POST" method when making requests to the token endpoint.
Code change:
This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM

Related discussion:
text: 3.2.2. The client makes a request to the token endpoint by sending the <del> following parameters using the "application/x-www-form-urlencoded" format per application-x-www-form-urlencoded with a character encoding of UTF-8 in the HTTP request content: </del> <ins> following parameters using the form-encoded serialization format per form-serialization with a character encoding of UTF-8 in the HTTP request content: </ins> REQUIRED.  Identifier of the grant type the client uses with the particular token request.  This specification defines the values
Code change:
This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM

Related discussion:
text: %x5D-7E. The parameters are included in the content of the HTTP response using <del> the "application/json" media type as defined by RFC7159.  The 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 as JSON numbers.  The order of parameters does not matter and can vary. </del> <ins> the "application/json" media type as defined in json-serialization. </ins> For example:
Code change:
This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM

Related discussion:
text: The client constructs the request URI by adding the following parameters to the query component of the authorization endpoint URI <del> using the "application/x-www-form-urlencoded" format, per application-x-www-form-urlencoded: </del> <ins> as described by query-string-serialization: </ins> REQUIRED.  The authorization endpoint supports different sets of request and response parameters.  The client determines the type
Code change:
This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM

Related discussion:
text: If the resource owner grants the access request, the authorization server issues an authorization code and delivers it to the client by adding the following parameters to the query component of the <del> redirect URI using the "application/x-www-form-urlencoded" format, per application-x-www-form-urlencoded: </del> <ins> redirect URI using the query string serialization described by query- string-serialization, unless specified otherwise by an extension: </ins> REQUIRED.  The authorization code is generated by the authorization server and opaque to the client.  The authorization
Code change:
This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM

Related discussion:
text: 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:
Code change:
Edited intro to reflect what this document is about changed some OAuth 2.0 references to OAuth 2.1 when referring to this document changed document name to follow ID standard name (repo and filename should be updated as well?) pulled out acknowledgments as this doc will be different

Related discussion:
text: The OAuth 2.1 Authorization Framework <del> oauth-2.1 </del> <ins> draft-parecki-oauth-v2-1 </ins> Abstract
Code change:
Edited intro to reflect what this document is about changed some OAuth 2.0 references to OAuth 2.1 when referring to this document changed document name to follow ID standard name (repo and filename should be updated as well?) pulled out acknowledgments as this doc will be different

Related discussion:
text: behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.  This <del> specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. </del> <ins> specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749. </ins> 1.
Code change:
Edited intro to reflect what this document is about changed some OAuth 2.0 references to OAuth 2.1 when referring to this document changed document name to follow ID standard name (repo and filename should be updated as well?) pulled out acknowledgments as this doc will be different

Related discussion:
text: 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.
Code change:
Edited intro to reflect what this document is about changed some OAuth 2.0 references to OAuth 2.1 when referring to this document changed document name to follow ID standard name (repo and filename should be updated as well?) pulled out acknowledgments as this doc will be different

Related discussion:
text: 1.2. <del> The abstract OAuth 2.0 flow illustrated in fig-protocol-flow </del> <ins> The abstract OAuth 2.1 flow illustrated in fig-protocol-flow </ins> describes the interaction between the four roles and includes the following steps:
Code change:
Edited intro to reflect what this document is about changed some OAuth 2.0 references to OAuth 2.1 when referring to this document changed document name to follow ID standard name (repo and filename should be updated as well?) pulled out acknowledgments as this doc will be different

Related discussion:
text: 1.8. <del> OAuth 2.0 provides a rich authorization framework with well-defined </del> <ins> OAuth 2.1 provides a rich authorization framework with well-defined </ins> security properties.  However, as a rich and highly extensible framework with many optional components, on its own, this specification is likely to produce a wide range of non-interoperable
Code change:
align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.

Related discussion:
text: "confidentiality", "credential", "encryption", "identity", "sign", "signature", "trust", "validate", and "verify". <ins> The term "payload" is to be interpreted as described in Section 3.3 of RFC7231. </ins> Unless otherwise noted, all the protocol parameter names and values are case sensitive.
Code change:
align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.

Related discussion:
text: The client makes a request to the token endpoint by sending the following parameters using the "application/x-www-form-urlencoded" format per Appendix B with a character encoding of UTF-8 in the HTTP <del> request entity-body: </del> <ins> request payload: </ins> REQUIRED.  Value MUST be set to "authorization_code".
Code change:
align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.

Related discussion:
text: The client makes a request to the token endpoint by adding the following parameters using the "application/x-www-form-urlencoded" format per Appendix B with a character encoding of UTF-8 in the HTTP <del> request entity-body: </del> <ins> request payload: </ins> REQUIRED.  Value MUST be set to "client_credentials".
Code change:
align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.

Related discussion:
text: The authorization server issues an access token and optional refresh token, and constructs the response by adding the following parameters <del> to the entity-body of the HTTP response with a 200 (OK) status code: </del> <ins> to the payload of the HTTP response with a 200 (OK) status code: </ins> REQUIRED.  The access token issued by the authorization server.
Code change:
align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.

Related discussion:
text: 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.
Code change:
align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.

Related discussion:
text: 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
Code change:
align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.

Related discussion:
text: client makes a refresh request to the token endpoint by adding the following parameters using the "application/x-www-form-urlencoded" format per Appendix B with a character encoding of UTF-8 in the HTTP <del> request entity-body: </del> <ins> request payload: </ins> REQUIRED.  Value MUST be set to "refresh_token".
Code change:
align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.

Related discussion:
text: 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:
Code change:
RFC7230 references HTTP Messaging aka HTTP/1.1. OAuth2.1 is agnostic of the HTTP version instead. Consider that httpbis moves further definitions to including "user agent" and the and provides some details on validation

Related discussion:
text: (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
Code change:
uses the ::boilerplate macro of URL
I'm not sure what I'm doing wrong but when I try this I get an error: I'm using kramdown-rfc2629 version 1.4.3
fixed in URL NAME
Friendly reminder ;)
PTAL

Related discussion:
text: An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token.  This specification defines three <del> grant types -- authorization code, refresh token, and client credentials -- as well as an extensibility mechanism for defining </del> <ins> grant types - authorization code, refresh token, and client credentials - as well as an extensibility mechanism for defining </ins> additional types. 1.3.1.
Code change:
uses the ::boilerplate macro of URL
I'm not sure what I'm doing wrong but when I try this I get an error: I'm using kramdown-rfc2629 version 1.4.3
fixed in URL NAME
Friendly reminder ;)
PTAL

Related discussion:
text: 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
Code change:
uses the ::boilerplate macro of URL
I'm not sure what I'm doing wrong but when I try this I get an error: I'm using kramdown-rfc2629 version 1.4.3
fixed in URL NAME
Friendly reminder ;)
PTAL

Related discussion:
text: 2.2. The authorization server issues the registered client a client <del> identifier -- a unique string representing the registration </del> <ins> identifier - a unique string representing the registration </ins> information provided by the client.  The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication.  The client identifier is unique to