jiebi/TextFlow huggingface dataset:
Original text:
An endpoint MAY send ACK-FREQUENCY frames multiple times during a connection and with different values. <del> 4. An endpoint could receive an ACK-FREQUENCY frame with either or both Time Tolerance and Packet Tolerance values specified.  In addition, the endpoint will have committed a max_ack_delay value to the peer, </del>  which specifies the maximum amount of time by which the endpoint will <del> delay sending acknowledgments; see Section XX of QUIC-TRANSPORT. </del>  <del> The endpoint MUST send an acknowledgement when any of the three thresholds are met.  Doing so results in the fewest acknowledgements possible within the sender's tolerance and honors the receiver's commitment. loss and batch section describes exceptions to this strategy. </del>  An endpoint is expected to bundle acknowledgements when possible. Every time an acknowledgement is sent, bundled or otherwise, all counters and timers related to delaying of acknowledgments are reset. <del> 4.1. </del>  To expedite loss detection, endpoints SHOULD send an acknowledgement immediately on receiving an ack-eliciting packet that is out of

Reviewer comments:
This PR changes a few things: Introduces a TP for negotiating extension use Changes to Makes the fields required Specifies invalid values
I'm merging this, let's address issues in later PRs.
I think it'll be easier to make both parameters required. Not doing so saves 1 to 2 bytes, which is really not much in a frame I expect will be sent a few times a connection. Also, I think 0 should be an invalid value for both params, and 1 should be invalid for the number of packets, though I can see someone arguing that point.
addresses these issues, with the exception that 1 is allowed for packet tolerance. I think that's actually useful for some startup schemes, so we shouldn't disallow it.

Revised text:
An endpoint MAY send ACK-FREQUENCY frames multiple times during a connection and with different values.  <ins> An endpoint will have committed a max_ack_delay value to the peer, </ins> which specifies the maximum amount of time by which the endpoint will  <ins> delay sending acknowledgments.  When the endpoint receives an ACK- FREQUENCY frame, it MUST update this maximum time to the value proposed by the peer in the Update Max Ack Delay field. </ins>  <ins> 5. On receiving an ACK-FREQUENCY frame, an endpoint will have an updated maximum delay for sending an acknowledgement, and a packet threshold as well.  The endpoint MUST send an acknowledgement when either of the two thresholds are met. loss and batch section describes exceptions to this strategy. </ins> An endpoint is expected to bundle acknowledgements when possible. Every time an acknowledgement is sent, bundled or otherwise, all counters and timers related to delaying of acknowledgments are reset.  <ins> 5.1. </ins> To expedite loss detection, endpoints SHOULD send an acknowledgement immediately on receiving an ack-eliciting packet that is out of
Original text:
codepoint in the IP header SHOULD be acknowledged immediately, to reduce the peer's response time to congestion events. <del> 4.2. </del>  For performance reasons, an endpoint can receive incoming packets from the underlying platform in a batch of multiple packets.  This

Reviewer comments:
This PR changes a few things: Introduces a TP for negotiating extension use Changes to Makes the fields required Specifies invalid values
I'm merging this, let's address issues in later PRs.
I think it'll be easier to make both parameters required. Not doing so saves 1 to 2 bytes, which is really not much in a frame I expect will be sent a few times a connection. Also, I think 0 should be an invalid value for both params, and 1 should be invalid for the number of packets, though I can see someone arguing that point.
addresses these issues, with the exception that 1 is allowed for packet tolerance. I think that's actually useful for some startup schemes, so we shouldn't disallow it.

Revised text:
codepoint in the IP header SHOULD be acknowledged immediately, to reduce the peer's response time to congestion events.  <ins> 5.2. </ins> For performance reasons, an endpoint can receive incoming packets from the underlying platform in a batch of multiple packets.  This
Original text:
whether a threshold has been met and an acknowledgement is to be sent in response. <del> 5. </del>  An endpoint can send multiple ACK-FREQUENCY frames, and each one of them can have different values.

Reviewer comments:
This PR changes a few things: Introduces a TP for negotiating extension use Changes to Makes the fields required Specifies invalid values
I'm merging this, let's address issues in later PRs.
I think it'll be easier to make both parameters required. Not doing so saves 1 to 2 bytes, which is really not much in a frame I expect will be sent a few times a connection. Also, I think 0 should be an invalid value for both params, and 1 should be invalid for the number of packets, though I can see someone arguing that point.
addresses these issues, with the exception that 1 is allowed for packet tolerance. I think that's actually useful for some startup schemes, so we shouldn't disallow it.

Revised text:
whether a threshold has been met and an acknowledgement is to be sent in response.  <ins> 6. </ins> An endpoint can send multiple ACK-FREQUENCY frames, and each one of them can have different values.
Original text:
If the enclosing packet number is not greater than the recorded one, the endpoint MUST ignore this ACK-FREQUENCY frame. <del> 6. </del>  TBD. <del> 7. </del>  TBD.

Reviewer comments:
This PR changes a few things: Introduces a TP for negotiating extension use Changes to Makes the fields required Specifies invalid values
I'm merging this, let's address issues in later PRs.
I think it'll be easier to make both parameters required. Not doing so saves 1 to 2 bytes, which is really not much in a frame I expect will be sent a few times a connection. Also, I think 0 should be an invalid value for both params, and 1 should be invalid for the number of packets, though I can see someone arguing that point.
addresses these issues, with the exception that 1 is allowed for packet tolerance. I think that's actually useful for some startup schemes, so we shouldn't disallow it.

Revised text:
If the enclosing packet number is not greater than the recorded one, the endpoint MUST ignore this ACK-FREQUENCY frame.  <ins> 7. </ins> TBD.  <ins> 8. </ins> TBD.
Original text:
A "revoke-certificate" resource  For the "new-X" resources above, the server MUST have exactly one resource for each function.  This resource may be addressed by multiple URIs, but all must provide equivalent functionality.

Reviewer comments:
This uses two JWS signatures to achieve the two-signature property during rollover, instead of using extra layers of encoding and embedding. It also simplifies the logic and splits it out into its own resource.

Revised text:
A "revoke-certificate" resource <ins> A "key-change" resource </ins> For the "new-X" resources above, the server MUST have exactly one resource for each function.  This resource may be addressed by multiple URIs, but all must provide equivalent functionality.
Original text:
The public key of the account key pair, encoded as a JSON Web Key object RFC7517. <del> "valid" or "deactivated" </del>  An array of URIs that the server can use to contact the client for issues related to this authorization.  For example, the server may

Reviewer comments:
what's the difference between "deactivated" and "revoked"?
Deactivated is done by the user; revoked is done by an administrator.
OK, so we need to either say that or use clearer terms :) I talked with NAME offline, and I think he's going to propose something.

Revised text:
The public key of the account key pair, encoded as a JSON Web Key object RFC7517.  <ins> The status of this registration.  Possible values are: "valid", "deactivated", and "revoked". "deactivated" should be used to indicate user initiated deactivation whereas "revoked" should be used to indicate administratively initiated deactivation. </ins> An array of URIs that the server can use to contact the client for issues related to this authorization.  For example, the server may
Original text:
Fulfill the server's requirements for issuance <del> Finalize the application and request issuance </del>  The client's application for a certificate describes the desired certificate using a PKCS#10 Certificate Signing Request (CSR) plus a

Reviewer comments:
Based on the acme mailing list discussion[0] on "proactive" vs "on-finalization" issuance it seems there is more support for the proactive approach. Speaking on behalf of Let's Encrypt and the Boulder developers we're willing to compromise and support proactive issuance as the sole issuance method in order to simplify the protocol & implementations. This PR changes the language around certificate issuance to reflect that the server MUST issue the certificate proactively once all the required challenges for an application have been fulfilled. The open issue corresponding to making this decision is removed now that there is one supported option. In an effort to close out open questions around applications this commit also removes the open issue around multiple certificates per application. If there is a demand for automating repeat issuance there should be a new thread started with a concrete proposal. 0: URL
NAME apologies! I missed your comments until today. Both are resolved in URL Thank you for the feedback.
Oh! They were fresh and I misread the dates. Not such a bad turn around after all :-)
NAME Fantastic, thanks. Merging. Hi folks, I wanted to revisit a discussion on the server proactively issuing certificates. Section 4, "Protocol Overview"[0] currently has a paragraph that reads: the the application be to the There is also an "Open Issue" remark related to proactive issuance in Section [1]. I think the specification should decide whether proactive issuance or on-finalization issuance should be used instead of allowing both with no indication to the client which will happen. It's the preference of Let's Encrypt that the specification only support on-finalization issuance. This is cheaper to implement and seems to be the path of least surprise. It also seems to better support large volume issuance when the client may want explicit control over when the certificates for multiple applications are issued. In the earlier "Re: [Acme] Preconditions" thread[2] Andrew Ayer seems to agree that there should be only one issuance method to simplify client behaviours, though he favours proactive issuance instead of on-finalization issuance. While it saves a round-trip message I'm not sure that this alone is convincing enough to choose proactive issuance as the one issuance method. What are the thoughts of other list members? Daniel/cpu [0] URL [1] URL [2] URL

Revised text:
Fulfill the server's requirements for issuance  <ins> Await issuance and download the issued certificate </ins> The client's application for a certificate describes the desired certificate using a PKCS#10 Certificate Signing Request (CSR) plus a
Original text:
"alg" <del> "jwk" (only for requests to new-reg and revoke-cert resources) </del>  "kid" (for all other requests).

Reviewer comments:
In the term "registration" was changed to "account". In and in some of the remaining references to "registration" were removed, but some 'new-reg' and references to "registration" remained. This PR removes, hopefully, the last references to "registration".

Revised text:
"alg"  <ins> "jwk" (only for requests to new-account and revoke-cert resources) </ins> "kid" (for all other requests).
Original text:
The "jwk" and "kid" fields are mutually exclusive.  Servers MUST reject requests that contain both. <del> For new-reg requests, and for revoke-cert requests authenticated by certificate key, there MUST be a "jwk" field. </del>  For all other requests, there MUST be a "kid" field.  This field must <del> contain the account URI received by POSTing to the new-reg resource. </del>  Note that authentication via signed JWS request bodies implies that GET requests are not authenticated.  Servers MUST NOT respond to GET

Reviewer comments:
In the term "registration" was changed to "account". In and in some of the remaining references to "registration" were removed, but some 'new-reg' and references to "registration" remained. This PR removes, hopefully, the last references to "registration".

Revised text:
The "jwk" and "kid" fields are mutually exclusive.  Servers MUST reject requests that contain both.  <ins> For new-account requests, and for revoke-cert requests authenticated by certificate key, there MUST be a "jwk" field. </ins> For all other requests, there MUST be a "kid" field.  This field must  <ins> contain the account URI received by POSTing to the new-account resource. </ins> Note that authentication via signed JWS request bodies implies that GET requests are not authenticated.  Servers MUST NOT respond to GET
Original text:
The server MUST ignore any updates to the "key", or "order" fields or any other fields it does not recognize.  The server MUST verify that the request is signed with the private key corresponding to the "key" <del> field of the request before updating the registration. </del>  For example, to update the contact information in the above account, the client could send the following request:

Reviewer comments:
In the term "registration" was changed to "account". In and in some of the remaining references to "registration" were removed, but some 'new-reg' and references to "registration" remained. This PR removes, hopefully, the last references to "registration".

Revised text:
The server MUST ignore any updates to the "key", or "order" fields or any other fields it does not recognize.  The server MUST verify that the request is signed with the private key corresponding to the "key"  <ins> field of the request before updating the account object. </ins> For example, to update the contact information in the above account, the client could send the following request:
Original text:
the CA may consider the new account associated with the external account corresponding to the MAC key, and MUST reflect value of the "external-account-binding" field in the resulting account object.  If <del> any of these checks fail, then the CA MUST reject the new- registration request. </del>  6.3.3.

Reviewer comments:
In the term "registration" was changed to "account". In and in some of the remaining references to "registration" were removed, but some 'new-reg' and references to "registration" remained. This PR removes, hopefully, the last references to "registration".

Revised text:
the CA may consider the new account associated with the external account corresponding to the MAC key, and MUST reflect value of the "external-account-binding" field in the resulting account object.  If  <ins> any of these checks fail, then the CA MUST reject the new-account request. </ins> 6.3.3.
Original text:
a POST request with an empty update.  That is, it should send a JWS whose payload is an empty object ({}). <del> 7.3.1. </del>  As described above, a client can indicate its agreement with the CA's terms of service by setting the "terms-of-service-agreed" field in

Reviewer comments:
This PR is a first go at addressing the following points I raised on the mailing list.
This allows us to address the account URL recovery use case in without having special handling for empty payloads.

Revised text:
a POST request with an empty update.  That is, it should send a JWS whose payload is an empty object ({}).  <ins> 7.3.4. </ins> As described above, a client can indicate its agreement with the CA's terms of service by setting the "terms-of-service-agreed" field in
Original text:
human user to visit in order for instructions on how to agree to the terms. <del> 7.3.2. </del>  The server MAY require a value to be present for the "external- account-binding" field.  This can be used to an ACME account with an

Reviewer comments:
This PR is a first go at addressing the following points I raised on the mailing list.
This allows us to address the account URL recovery use case in without having special handling for empty payloads.

Revised text:
human user to visit in order for instructions on how to agree to the terms.  <ins> 7.3.5. </ins> The server MAY require a value to be present for the "external- account-binding" field.  This can be used to an ACME account with an
Original text:
any of these checks fail, then the CA MUST reject the new-account request. <del> 7.3.3. </del>  A client may wish to change the public key that is associated with an account in order to recover from a key compromise or proactively

Reviewer comments:
This PR is a first go at addressing the following points I raised on the mailing list.
This allows us to address the account URL recovery use case in without having special handling for empty payloads.

Revised text:
any of these checks fail, then the CA MUST reject the new-account request.  <ins> 7.3.6. </ins> A client may wish to change the public key that is associated with an account in order to recover from a key compromise or proactively
Original text:
responds with an error status code and a problem document describing the error. <del> 7.3.4. </del>  A client can deactivate an account by posting a signed update to the server with a status field of "deactivated."  Clients may wish to do

Reviewer comments:
This PR is a first go at addressing the following points I raised on the mailing list.
This allows us to address the account URL recovery use case in without having special handling for empty payloads.

Revised text:
responds with an error status code and a problem document describing the error.  <ins> 7.3.7. </ins> A client can deactivate an account by posting a signed update to the server with a status field of "deactivated."  Clients may wish to do
Original text:
then the server SHOULD change the status of the order to "invalid" and MAY delete the order resource. <del> The server MUST issue the requested certificate and update the order resource with a URL for the certificate shortly after the client has fulfilled the server's requirements.  If the client has already satisfied the server's requirements at the time of this request (e.g., by obtaining authorization for all of the identifiers in the certificate in previous transactions), then the server MUST proactively issue the requested certificate and provide a URL for it in the "certificate" field of the order.  The server MUST, however, still list the completed authorizations in the "authorizations" array. </del>  Once the client believes it has fulfilled the server's requirements, it should send a GET request to the order resource to obtain its

Reviewer comments:
This change replaces "shortly" in the normative language of Section 7.4, Applying for Certificate Issuance, with the more precise expectation that the server begin the issuance process, as discussed on the mailing list. URL We could say "MUST begin the issuance process" The main things on my mind that could delay issuance slightly: Submitting to CT Checking CAA Internal queuing for available capacity Manual vetting I think "MUST begin" covers for all of those, while allowing some vagueness as to how long they will take. On 03/22/2017 09:39 AM, Daniel McCarney wrote:

Revised text:
then the server SHOULD change the status of the order to "invalid" and MAY delete the order resource.  <ins> The server MUST begin the issuance process for the requested certificate and update the order resource with a URL for the certificate once the client has fulfilled the server's requirements. If the client has already satisfied the server's requirements at the time of this request (e.g., by obtaining authorization for all of the identifiers in the certificate in previous transactions), then the server MUST proactively issue the requested certificate and provide a URL for it in the "certificate" field of the order.  The server MUST, however, still list the completed authorizations in the "authorizations" array. </ins> Once the client believes it has fulfilled the server's requirements, it should send a GET request to the order resource to obtain its
Original text:
not want an account to be created if one does not already exist, then it SHOULD do so by sending a POST request to the new-account URL with a JWS whose payload has an "only-return-existing" field set to "true" <del> ({"only-return-existing": true}). </del>  7.3.2.

Reviewer comments:
Is 200 really correct? This seems like a 404 maybe? Also we should specify the body (empty).
Would a problem document be appropriate (with either a pre-existing ACME error type or a new one like "accountDoesNotExist")?
404 talks about the effective request URI, so that's not going to work. I think that a 400 would be better on the basis that the request checked, but failed (NAME suggestion is a fine enhancement). The reason you make this request is to check; and having a 4xx series code is easier to test than the absence of a header field.
Thanks NAME and NAME implemented this in the latest commit.
As discussed; this is fine.

Revised text:
not want an account to be created if one does not already exist, then it SHOULD do so by sending a POST request to the new-account URL with a JWS whose payload has an "only-return-existing" field set to "true"  <ins> ({"only-return-existing": true}).  If a client sends such a request and an account does not exist, then the server MUST return an error response with status code 400 (Bad Request) and type "urn:ietf:params:acme:error:accountDoesNotExist". </ins> 7.3.2.
Original text:
(OK) status code and the current contents of the account object. Once an account is deactivated, the server MUST NOT accept further <del> requests authorized by that account's key.  A server may take a variety of actions in response to an account deactivation, e.g., deleting data related to that account or sending mail to the account's contacts.  Servers SHOULD NOT revoke certificates issued by the deactivated account, since this could cause operational disruption for servers using these certificates.  ACME does not provide a way to reactivate a deactivated account. </del>  7.4.

Reviewer comments:
It makes sense to cancel any pending cert orders when an account is deactivated, where the cert has not been issued yet.

Revised text:
(OK) status code and the current contents of the account object. Once an account is deactivated, the server MUST NOT accept further  <ins> requests authorized by that account's key.  The server SHOULD cancel any pending operations authorized by the account's key, such as certificate orders.  A server may take a variety of actions in response to an account deactivation, e.g., deleting data related to that account or sending mail to the account's contacts.  Servers SHOULD NOT revoke certificates issued by the deactivated account, since this could cause operational disruption for servers using these certificates.  ACME does not provide a way to reactivate a deactivated account. </ins> 7.4.