jiebi/TextFlow huggingface dataset:
Original 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>  REQUIRED.  The authorization code is generated by the authorization server and opaque to the client.  The authorization

Reviewer comments:
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

Revised 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  <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
Original 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>  REQUIRED.  A single ASCII USASCII error code from the following:

Reviewer comments:
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

Revised 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  <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:
Original text:
The OAuth 2.1 Authorization Framework <del> oauth-2.1 </del>  Abstract

Reviewer comments:
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

Revised text:
The OAuth 2.1 Authorization Framework  <ins> draft-parecki-oauth-v2-1 </ins> Abstract
Original 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>  1.

Reviewer comments:
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

Revised 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  <ins> specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749. </ins> 1.
Original 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>  1.1.

Reviewer comments:
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

Revised text:
This specification is designed for use with HTTP (RFC2616).  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 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.
Original text:
1.2. <del> The abstract OAuth 2.0 flow illustrated in fig-protocol-flow </del>  describes the interaction between the four roles and includes the following steps:

Reviewer comments:
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

Revised text:
1.2.  <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:
Original text:
1.8. <del> OAuth 2.0 provides a rich authorization framework with well-defined </del>  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

Reviewer comments:
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

Revised text:
1.8.  <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
Original text:
"confidentiality", "credential", "encryption", "identity", "sign", "signature", "trust", "validate", and "verify".  Unless otherwise noted, all the protocol parameter names and values are case sensitive.

Reviewer comments:
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.

Revised 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.
Original 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>  REQUIRED.  Value MUST be set to "authorization_code".

Reviewer comments:
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.

Revised 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  <ins> request payload: </ins> REQUIRED.  Value MUST be set to "authorization_code".
Original 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>  REQUIRED.  Value MUST be set to "client_credentials".

Reviewer comments:
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.

Revised 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  <ins> request payload: </ins> REQUIRED.  Value MUST be set to "client_credentials".
Original 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>  REQUIRED.  The access token issued by the authorization server.

Reviewer comments:
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.

Revised text:
The authorization server issues an access token and optional refresh token, and constructs the response by adding the following parameters  <ins> to the payload of the HTTP response with a 200 (OK) status code: </ins> REQUIRED.  The access token issued by the authorization server.
Original 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>  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.

Reviewer comments:
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.

Revised text:
otherwise, REQUIRED.  The scope of the access token as described by access-token-scope.  <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.
Original 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>  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

Reviewer comments:
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.

Revised text:
thus MUST NOT include characters outside the set %x21 / %x23-5B / %x5D-7E.  <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
Original 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>  REQUIRED.  Value MUST be set to "refresh_token".

Reviewer comments:
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.

Revised 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  <ins> request payload: </ins> REQUIRED.  Value MUST be set to "refresh_token".
Original 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>  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>  <del> The HTTP request entity-body is single-part. </del>  <del> The content to be encoded in the entity-body MUST consist entirely of ASCII USASCII characters. </del>  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>  For example, the client makes the following HTTP request using transport-layer security:

Reviewer comments:
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.

Revised text:
7.2.1.2.  <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".  <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>  <ins> The HTTP request payload is single-part. </ins>  <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.  <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:
Original 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>  Since the publication of the OAuth 2.0 Authorization Framework (RFC6749) in October 2012, it has been updated by OAuth 2.0 for

Reviewer comments:
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

Revised text:
(authorization server), which issues the printing service delegation- specific credentials (access token).  <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
Original 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>  additional types. 1.3.1.

Reviewer comments:
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

Revised 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  <ins> grant types - authorization code, refresh token, and client credentials - as well as an extensibility mechanism for defining </ins> additional types. 1.3.1.
Original 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>  This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234.  Additionally, the rule URI-reference is

Reviewer comments:
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

Revised text:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and  <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
Original text:
2.2. The authorization server issues the registered client a client <del> identifier -- a unique string representing the registration </del>  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

Reviewer comments:
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

Revised text:
2.2. The authorization server issues the registered client a client  <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