jiebi/TextFlow huggingface dataset:
Original text:
MUST be able to dereference or process the key information in order to be able to sign the request.  OPTIONAL.  Flag indicating a hint of AS behavior on token <del> rotation.  If this flag is set to the value "true", then the client instance can expect a previously-issued access token to continue to work after it has been rotate-access-token or the underlying grant request has been continue-modify, resulting in the issuance of new access tokens.  If this flag is set to the boolean value "false" or is omitted, the client instance can </del>  anticipate a given access token will stop working after token rotation or grant request modification.  Note that a token flagged as "durable" can still expire or be revoked through any normal

Reviewer comments:
URL match the flags array in the token request. While this is technically a breaking change, I think we should consider this editorial as this should have been changed when we made the original change to use a flags array in the request in .
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: 8c793bb446d82f053536358106485568fc457842 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
You know, I had that thought, and I checked the request section and it doesn't have quotes. I'm going to add the quotes to both parts. This ended up with some other language changing, not just the examples, so let me know what you think.

Revised text:
MUST be able to dereference or process the key information in order to be able to sign the request. <ins> OPTIONAL.  A set of flags that represent attributes or behaviors of the access token issued by the AS. The values of the "flags" field defined by this specification are as follows: This flag indicates whether the token is bound to the client instance's key.  If the "bearer" flag is present, the access token is a bearer token, and the "key" field in this response MUST be omitted.  If the "bearer" flag is omitted and the "key" field in this response is omitted, the token is bound the request-client in its request for access.  If the "bearer" flag is omitted, and the "key" field is present, the token is bound to the key and proofing mechanism indicated in the "key" field. </ins> OPTIONAL.  Flag indicating a hint of AS behavior on token  <ins> rotation.  If this flag is present, then the client instance can expect a previously-issued access token to continue to work after it has been rotate-access-token or the underlying grant request has been continue-modify, resulting in the issuance of new access tokens.  If this flag is omitted, the client instance can </ins> anticipate a given access token will stop working after token rotation or grant request modification.  Note that a token flagged as "durable" can still expire or be revoked through any normal
Original text:
unless the client instance has specifically requested it by use of the "split" flag.  The following non-normative example shows a single access token bound to the client instance's key used in the initial request, with a management URL, and that has access to three described resources (one

Reviewer comments:
URL match the flags array in the token request. While this is technically a breaking change, I think we should consider this editorial as this should have been changed when we made the original change to use a flags array in the request in .
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: 8c793bb446d82f053536358106485568fc457842 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
You know, I had that thought, and I checked the request section and it doesn't have quotes. I'm going to add the quotes to both parts. This ended up with some other language changing, not just the examples, so let me know what you think.

Revised text:
unless the client instance has specifically requested it by use of the "split" flag. <ins> Flag values MUST NOT be included more than once. Additional flags can be defined by extensions using IANA. </ins> The following non-normative example shows a single access token bound to the client instance's key used in the initial request, with a management URL, and that has access to three described resources (one
Original text:
sends the "split" flag as described in request-token-single. If the AS has split the access token response, the response MUST <del> include the "split" flag set to "true". </del>  [[ See issue #69 [17] ]]

Reviewer comments:
URL match the flags array in the token request. While this is technically a breaking change, I think we should consider this editorial as this should have been changed when we made the original change to use a flags array in the request in .
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: 8c793bb446d82f053536358106485568fc457842 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
You know, I had that thought, and I checked the request section and it doesn't have quotes. I'm going to add the quotes to both parts. This ended up with some other language changing, not just the examples, so let me know what you think.

Revised text:
sends the "split" flag as described in request-token-single. If the AS has split the access token response, the response MUST  <ins> include the "split" flag. </ins> [[ See issue #69 [17] ]]
Original text:
multiple access token structure containing one access token. If the AS has split the access token response, the response MUST <del> include the "split" flag set to "true". </del>  Each access token MAY be bound to different keys with different proofing mechanisms.

Reviewer comments:
URL match the flags array in the token request. While this is technically a breaking change, I think we should consider this editorial as this should have been changed when we made the original change to use a flags array in the request in .
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: 8c793bb446d82f053536358106485568fc457842 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
You know, I had that thought, and I checked the request section and it doesn't have quotes. I'm going to add the quotes to both parts. This ended up with some other language changing, not just the examples, so let me know what you think.

Revised text:
multiple access token structure containing one access token. If the AS has split the access token response, the response MUST  <ins> include the "split" flag in the "flags" array. </ins> Each access token MAY be bound to different keys with different proofing mechanisms.
Original text:
REQUIRED.  The URI at which the client instance can make continuation requests.  This URI MAY vary per request, or MAY be <del> stable at the AS if the AS includes an access token.  The client instance MUST use this value exactly as given when making a continue-request. </del>  RECOMMENDED.  The amount of time in integer seconds the client instance SHOULD wait after receiving this continuation handle and

Reviewer comments:
In the current version, the AS must include an access token. "if the AS includes an access token" sounds like the inclusion of an access token is optional.
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 323dd6c268368857c2d9942048f94658b806b8ad Inspect the deploy log: Browse the preview:

Revised text:
REQUIRED.  The URI at which the client instance can make continuation requests.  This URI MAY vary per request, or MAY be  <ins> stable at the AS.  The client instance MUST use this value exactly as given when making a continue-request. </ins> RECOMMENDED.  The amount of time in integer seconds the client instance SHOULD wait after receiving this continuation handle and
Original text:
If the AS determines that the request cannot be issued for any reason, it responds to the client instance with an error message. <del> The error code is one of the following, with additional values available in IANA: </del> [[ See issue #79 [15] ]] 3.7.

Reviewer comments:
for
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: c7273a059b212bf18879f131a5a18d9a776a2918 Inspect the deploy log: Browse the preview:
Error Response: Editor's note: I think we will need a more robust error mechanism, and we need to be more clear about what error states are allowed in what circumstances. Additionally, is the "error" parameter exclusive with others in the return?
As a starting point, I would suggest adding these sentences The error code parameter MUST be required and its value SHOULD be limited to ASCII characters. The error code indicates that a request is malformed. The AS MUST return an HTTP 401 (Unauthorized) status code to indicate that it can't identify a client instance (the error code can be ). The AS MUST return an HTTP 401 (Unauthorized) status code to indicate that it can't authenticate a client instance (the error code can be ). The AS MAY uncover additional information about the cause of the error when it can authenticate a client instance (the error code can be , , and so on).
Addressed by , still need error codes for things like token management.
The type of the of the error property in a response is currently ambiguous. In section 3 it is defined as an and in section 3.6 it is defined as a .
NAME thanks for catching that -- looks like both "error" and "errordescription" should be added to the list of parameters. I think the intent might have been for the value of "error" to be an object with "errorcode" and "error_description" fields inside of it though, so it might be better to align things in that direction instead. Do you have thoughts on which is preferable? Interop testing of error conditions is really difficult in practice, so this is a great catch!
Yaron: The AS MUST ignore any unknown extension. Justin: I’m OK with this stance, but it needs to be consistent throughout the protocol, not just at this level. Yaron: we can actually have one policy for an AS that doesn't understand something defined in the RFC (e.g. a token binding method) vs. extensions. Unknown extensions clearly must be ignored, otherwise you cannot deploy extensions incrementally. For RFC elements, this is more nuanced.
With the guidance on extension points from and error codes from and similar, this should now be covered by the current text.

Revised text:
If the AS determines that the request cannot be issued for any reason, it responds to the client instance with an error message.  [[ See issue #79 [15] ]] 3.7.
Original text:
Any keys presented by the client instance to the AS or RS MUST be validated as part of the request in which they are presented.  The <del> type of binding used is indicated by the proof parameter of the key object in key-format.  Values defined by this specification are as follows: </del>  Additional proofing methods are defined by IANA.  All key binding methods used by this specification MUST cover all relevant portions of the request, including anything that would change the nature of the request, to allow for secure validation of

Reviewer comments:
Expands the key parameter to allow it to be an object or a string, to facilitate methods with multiple parameters such as HTTPSig.
To edit notification comments on pull requests, go to your .
Some key proofing methods have additional options that could be signaled in the GNAP protocol structure. Notable, HTTP Message Signatures has the ability to use different HTTP Signing Algorithms and different HTTP Digest Algorithms. The field could be changed to an object to accomodate this kind of use, allowing each proofing method to define its own parameters: Each method can also define "Default" values for missing parameters, allowing this to collapse in the simple case back to a string as it is today: These string values would have a deterministic expansion defined in the core protocol.
Note that the httpsig document itself wavers between and and does not require either of them. Though maybe this is OK if the current document makes mandatory for the appropriate cases.
There are some updates pending in the Digest draft -- once that's out, we'll reference using as that's the most appropriate for our use case, and examples will be updated.

Revised text:
Any keys presented by the client instance to the AS or RS MUST be validated as part of the request in which they are presented.  The  <ins> type of binding used is indicated by the "proof" parameter of the key object in key-format.  This parameter is formally specified by an object with at least the following member: Individual methods MAY define additional parameters as members in this object. Values for the "method" defined by this specification are as follows: </ins> Additional proofing methods are defined by IANA. <ins> For example, the "httpsig" method can be specified with its parameters as: If additional parameters are not required or used for a specific method, the method MAY be passed as a string instead of an object. For example, the "mtls" method with no additional parameters could be sent by the client instance as: The AS would map this to the equivalent expanded form as follows: </ins> All key binding methods used by this specification MUST cover all relevant portions of the request, including anything that would change the nature of the request, to allow for secure validation of
Original text:
7.3.1. <del> This method is indicated by "httpsig" in the "proof" field.  The signer creates an HTTP Message Signature as described in I-D.ietf- httpbis-message-signatures. </del>  The covered components of the signature MUST include the following:

Reviewer comments:
Expands the key parameter to allow it to be an object or a string, to facilitate methods with multiple parameters such as HTTPSig.
To edit notification comments on pull requests, go to your .
Some key proofing methods have additional options that could be signaled in the GNAP protocol structure. Notable, HTTP Message Signatures has the ability to use different HTTP Signing Algorithms and different HTTP Digest Algorithms. The field could be changed to an object to accomodate this kind of use, allowing each proofing method to define its own parameters: Each method can also define "Default" values for missing parameters, allowing this to collapse in the simple case back to a string as it is today: These string values would have a deterministic expansion defined in the core protocol.
Note that the httpsig document itself wavers between and and does not require either of them. Though maybe this is OK if the current document makes mandatory for the appropriate cases.
There are some updates pending in the Digest draft -- once that's out, we'll reference using as that's the most appropriate for our use case, and examples will be updated.

Revised text:
7.3.1.  <ins> This method is indicated by the method value "httpsig".  The signer creates an HTTP Message Signature as described in I-D.ietf-httpbis- message-signatures.  This method defines the following parameters: </ins> The covered components of the signature MUST include the following:
Original text:
7.3.2. <del> This method is indicated by "mtls" in the "proof" field.  The signer presents its TLS client certificate during TLS negotiation with the verifier. </del>  In this example, the certificate is communicated to the application through the "Client-Cert" header from a TLS reverse proxy, leading to

Reviewer comments:
Expands the key parameter to allow it to be an object or a string, to facilitate methods with multiple parameters such as HTTPSig.
To edit notification comments on pull requests, go to your .
Some key proofing methods have additional options that could be signaled in the GNAP protocol structure. Notable, HTTP Message Signatures has the ability to use different HTTP Signing Algorithms and different HTTP Digest Algorithms. The field could be changed to an object to accomodate this kind of use, allowing each proofing method to define its own parameters: Each method can also define "Default" values for missing parameters, allowing this to collapse in the simple case back to a string as it is today: These string values would have a deterministic expansion defined in the core protocol.
Note that the httpsig document itself wavers between and and does not require either of them. Though maybe this is OK if the current document makes mandatory for the appropriate cases.
There are some updates pending in the Digest draft -- once that's out, we'll reference using as that's the most appropriate for our use case, and examples will be updated.

Revised text:
7.3.2.  <ins> This method is indicated by the method value "mtls".  This method defines no additional parameters.  The signer presents its TLS client certificate during TLS negotiation with the verifier. </ins> In this example, the certificate is communicated to the application through the "Client-Cert" header from a TLS reverse proxy, leading to
Original text:
7.3.3. <del> This method is indicated by "jwsd" in the "proof" field.  A JWS RFC7515 object is created as follows: </del>  To protect the request, the JOSE header of the signature contains the following claims:

Reviewer comments:
Expands the key parameter to allow it to be an object or a string, to facilitate methods with multiple parameters such as HTTPSig.
To edit notification comments on pull requests, go to your .
Some key proofing methods have additional options that could be signaled in the GNAP protocol structure. Notable, HTTP Message Signatures has the ability to use different HTTP Signing Algorithms and different HTTP Digest Algorithms. The field could be changed to an object to accomodate this kind of use, allowing each proofing method to define its own parameters: Each method can also define "Default" values for missing parameters, allowing this to collapse in the simple case back to a string as it is today: These string values would have a deterministic expansion defined in the core protocol.
Note that the httpsig document itself wavers between and and does not require either of them. Though maybe this is OK if the current document makes mandatory for the appropriate cases.
There are some updates pending in the Digest draft -- once that's out, we'll reference using as that's the most appropriate for our use case, and examples will be updated.

Revised text:
7.3.3.  <ins> This method is indicated by the method value "jwsd".  This method defines no additional parameters.  A JWS RFC7515 object is created as follows: </ins> To protect the request, the JOSE header of the signature contains the following claims:
Original text:
7.3.4. <del> This method is indicated by "jws" in the "proof" field.  A JWS RFC7515 object is created as follows: </del>  To protect the request, the JWS header contains the following claims.

Reviewer comments:
Expands the key parameter to allow it to be an object or a string, to facilitate methods with multiple parameters such as HTTPSig.
To edit notification comments on pull requests, go to your .
Some key proofing methods have additional options that could be signaled in the GNAP protocol structure. Notable, HTTP Message Signatures has the ability to use different HTTP Signing Algorithms and different HTTP Digest Algorithms. The field could be changed to an object to accomodate this kind of use, allowing each proofing method to define its own parameters: Each method can also define "Default" values for missing parameters, allowing this to collapse in the simple case back to a string as it is today: These string values would have a deterministic expansion defined in the core protocol.
Note that the httpsig document itself wavers between and and does not require either of them. Though maybe this is OK if the current document makes mandatory for the appropriate cases.
There are some updates pending in the Digest draft -- once that's out, we'll reference using as that's the most appropriate for our use case, and examples will be updated.

Revised text:
7.3.4.  <ins> This method is indicated by the method value "jws".  This method defines no additional parameters.  A JWS RFC7515 object is created as follows: </ins> To protect the request, the JWS header contains the following claims.
Original text:
This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and <del> other elements.  Some examples use a single trailing backslash '' to </del>  indicate line wrapping for long values, as per RFC8792.  The "" character and leading spaces on wrapped lines are not part of the value.

Reviewer comments:
Deploy Preview for gnap-resource-servers-editors-draft ready! Built Explore the source changes: 611af53328d71bac58f517702c5775a9c514d88d Inspect the deploy log: Browse the preview:

Revised text:
This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and  <ins> other elements.  Some examples use a single trailing backslash "" to </ins> indicate line wrapping for long values, as per RFC8792.  The "" character and leading spaces on wrapped lines are not part of the value.
Original text:
secure delegation.  The zone signing and secure delegation may be performed either by the Homenet Naming Authority or by the Outsourcing Infrastructure. sec-dnssec-deplyment discusses these two <del> alternatives. sec-views discusses the consequences of publishing multiple representations of the same zone also commonly designated as views.  This section provides guidance to limit the risks associated with multiple views.  sec-reverse discusses management of the reverse zone. sec-renumbering discusses how renumbering should be handled. </del>  Finally, sec-privacy and sec-security respectively discuss privacy and security considerations when outsourcing the Homenet Zone.  3. Customer Premises Equipment: (CPE) is a router providing

Reviewer comments:
…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.

Revised text:
secure delegation.  The zone signing and secure delegation may be performed either by the Homenet Naming Authority or by the Outsourcing Infrastructure. sec-dnssec-deplyment discusses these two  <ins> alternatives. sec-reverse discusses management of the reverse zone. sec-renumbering discusses how renumbering should be handled. </ins> Finally, sec-privacy and sec-security respectively discuss privacy and security considerations when outsourcing the Homenet Zone. <ins> The Homenet Zone is expected to host public information only.  It is not the scope of this DNS service to define local home network boundaries.  Instead, local scope information is expected to be provided to the home network using local scope naming services. mDNS RFC6762 DNS-SD RFC6763 are two examples of these services.  Currently mDNS is limited to a single link network.  However, future protocols are expected to leverage this constraint as pointed out in RFC7558. </ins> 3. Customer Premises Equipment: (CPE) is a router providing
Original text:
Server.  On the other hand, if the HNA signs the Homenet Zone itself, the zone would be collected by the Synchronization Server and directly transferred to the Public Authoritative Server(s).  These <del> policies are discussed and detailed in sec-dnssec-deplyment and sec- views. </del>  4.2.

Reviewer comments:
…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.

Revised text:
Server.  On the other hand, if the HNA signs the Homenet Zone itself, the zone would be collected by the Synchronization Server and directly transferred to the Public Authoritative Server(s).  These  <ins> policies are discussed and detailed in sec-dnssec-deplyment. </ins> 4.2.