jiebi/CodeConvo huggingface dataset:
authenticating to, and interacting with the captive portal is out of scope of this document. <del> RFC7710 used DHCP code point 160.  Due to a conflict, this document specifies TBD. </del> <ins> This document replaces RFC 7710.  RFC 7710 used DHCP code point 160. Due to a conflict, this document specifies TBD. </ins> [ This document is being collaborated on in Github at: https://github.com/capport-wg/7710bis.  The most recent version of
Networks with no captive portals MAY explicitly indicate this condition by using this option with the IANA-assigned URI for this <del> purpose (see ietf_params_capport-unrestricted).  Clients observing the URI value "urn:ietf:params:capport-unrestricted" MAY forego time- consuming forms of captive portal detection. </del> <ins> purpose (see iana-urn).  Clients observing the URI value "urn:ietf:params:capport-unrestricted" MAY forego time-consuming forms of captive portal detection. </ins> 2.1.
4.1. <del> 4.1.1. </del> <ins> This document registers a new entry under the IETF URN Sub-namespace defined in RFC3553: </ins> <del> Registry name: Captive Portal Unrestricted Identifier </del> <ins> Captive Portal Unrestricted Identifier </ins> <del> URN: urn:ietf:params:capport-unrestricted </del> <ins> urn:ietf:params:capport-unrestricted </ins> <del> Specification: RFC TBD (this document) </del> <ins> RFC TBD (this document) </ins> <del> Repository: RFC TBD (this document) </del> <ins> RFC TBD (this document) </ins> <del> Index value: Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. </del> <ins> Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. </ins> 4.2.
To avoid additional delays to connection migration confirmation when using this extension, a client can bundle an IMMEDIATE_ACK frame with the first non-probing frame (Section 9.2 of QUIC-TRANSPORT) it sends <del> or it can simply send an IMMEDIATE_ACK frame, which is a non-probing </del> <ins> or it can send only an IMMEDIATE_ACK frame, which is a non-probing </ins> frame. An endpoint's congestion controller and RTT estimator are reset upon
ACK-Eliciting Threshold, an endpoint can expect that the peer will not need to wait for its "max_ack_delay" period before sending an acknowledgement.  In such cases, the endpoint MAY therefore exclude <del> the peer's 'max_ack_delay' from its PTO calculation.  Note that this optimization requires some care in implementation, since it can cause premature PTOs under packet loss when "ignore_order" is enabled. </del> <ins> the peer's 'max_ack_delay' from its PTO calculation.  When Ignore Order is enabled and loss causes the peer to not receive enough packets to trigger an immediate acknowledgement, the receiver will wait 'max_ack_delay', increasing the chances of a premature PTO. Therefore, if Ignore Order is enabled, the PTO MUST be larger than the peer's 'max_ack_delay'. </ins> 9.
intensive, and reducing acknowledgement frequency reduces this cost at a data sender. <del> Severely asymmetric link technologies, such as DOCSIS, LTE, and satellite links, connection throughput in the data direction becomes constrained when the reverse bandwidth is filled by </del> <ins> For severely asymmetric link technologies, such as DOCSIS, LTE, and satellite links, connection throughput in the forward path can become constrained when the reverse path is filled by </ins> acknowledgment packets.  When traversing such links, reducing the <del> number of acknowledgments allows connection throughput to scale much further. </del> <ins> number of acknowledgments can achieve higher connection throughput. The rate of acknowledgment packets can impact link efficiency, including transmission opportunities or battery life. </ins> As discussed in implementation however, there can be undesirable consequences to congestion control and loss recovery if a receiver
A variable-length integer that indicates how many out of order packets can arrive before eliciting an immediate ACK.  If no <del> ACK_FREQUENCY frames have been received, this value defaults to 3, which is the recommended packet threhold for loss detection in (Section 18.2 of QUIC-RECOVERY).  A value of 0 indicates immediate ACKs SHOULD never be sent due to receiving an out-of-order packet. </del> <ins> ACK_FREQUENCY frames have been received, the endpoint immediately acknowledges any subsequent packets that are received out of order, as specified in Section 13.2 of QUIC-TRANSPORT, as such the default value is 1.  A value of 0 indicates immediate ACKs SHOULD never be sent due to receiving an out-of-order packet. </ins> ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission if an ACK_FREQUENCY frame with a larger
reordered ack-eliciting packet.  This extension modifies this behavior. <del> If an endpoint has not yet received an ACK_FREQUENCY frame, the endpoint immediately acknowledges any subsequent packets that are received out of order, as specified in Section 13.2 of QUIC- TRANSPORT.  An endpoint, that receives an ACK_FREQUENCY frame with a Reordering Threshold value other than 0x00, MUST immediately send an ACK frame when the packet number of largest unacknowledged packet since the last detected reordering event exceeds the Reordering Threshold. </del> <ins> In order to ensure timely loss detection, the Reordering Threshold provided in the ACK_FREQUENCY frame SHOULD NOT be larger than the re- ordering threshold used by the data sender for loss detection. (Section 18.2 of QUIC-RECOVERY) recommends a default packet threshold for loss detection of 3. An endpoint, that receives an ACK_FREQUENCY frame with a Reordering Threshold value other than 0x00, MUST immediately send an ACK frame when the packet number of largest unacknowledged packet since the last detected reordering event exceeds the Reordering Threshold. </ins> If the most recent ACK_FREQUENCY frame received from the peer has a "Reordering Threshold" value of 0x00, the endpoint does not make this
receivers to ignore obsolete frames. A variable-length integer representing the maximum number of ack- <del> eliciting packets the recipient of this frame can receive without sending an acknowledgment.  In other words, an acknowledgement is sent when more than this number of ack-eliciting packets have been received.  Since this is a maximum value, a receiver can send an acknowledgement earlier.  A value of 0 results in a receiver immediately acknowledging every ack-eliciting packet. </del> <ins> eliciting packets the recipient of this frame receives before sending an acknowledgment.  A receiving endpoint SHOULD send at least one ACK frame when more than this number of ack-eliciting packets have been received.  A value of 0 results in a receiver immediately acknowledging every ack-eliciting packet.  By default, an endpoint sends an ACK frame for every other ack-eliciting packet, as specified in Section 13.2.2 of QUIC-TRANSPORT, which corresponds to a value of 1. </ins> A variable-length integer representing the value to which the endpoint requests the peer update its "max_ack_delay"
which is in milliseconds.  Sending a value smaller than the "min_ack_delay" advertised by the peer is invalid.  Receipt of an invalid value MUST be treated as a connection error of type <del> PROTOCOL_VIOLATION. </del> <ins> PROTOCOL_VIOLATION.  On receiving a valid value in this field, the endpoint MUST update its "max_ack_delay" to the value provided by the peer. </ins> A variable-length integer that indicates how many out of order packets can arrive before eliciting an immediate ACK.  If no
the Sequence Number value in the frame is not greater than the largest processed thus far. <del> An endpoint will have committed a "max_ack_delay" value to the peer, which specifies the maximum amount of time by which the endpoint will 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 Request Max Ack Delay field. </del> 5. A sender can use an ACK_FREQUENCY frame to reduce the number of
Prior to receiving an ACK_FREQUENCY frame, endpoints send acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT. <del> On receiving an ACK_FREQUENCY frame and updating its recorded "max_ack_delay" and "Ack-Eliciting Threshold" values (ack-frequency- frame), the endpoint MUST send an acknowledgement when one of the following conditions are met: </del> <ins> On receiving an ACK_FREQUENCY frame and updating its "max_ack_delay" and "Ack-Eliciting Threshold" values (ack-frequency-frame), the endpoint sends an acknowledgement when one of the following conditions are met: </ins> Since the last acknowledgement was sent, the number of received <del> ack-eliciting packets is greater than or equal to the recorded "Ack-Eliciting Threshold". </del> <ins> ack-eliciting packets is greater than the "Ack-Eliciting Threshold". </ins> Since the last acknowledgement was sent, "max_ack_delay" amount of time has passed.
3. <ins> Endpoints advertise their support of the extension described in this document by sending the following transport parameter: A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an acknowledgement.  Values of 0 and 2^14 or greater are invalid, and receipt of these values MUST be treated as a connection error of type PROTOCOL_VIOLATION. An endpoint's min_ack_delay MUST NOT be greater than the its max_ack_delay.  Endpoints that support this extension MUST treat receipt of a min_ack_delay that is greater than the received max_ack_delay as a connection error of type PROTOCOL_VIOLATION.  Note that while the endpoint's max_ack_delay transport parameter is in milliseconds (Section 18.2 in QUIC-TRANSPORT), min_ack_delay is specified in microseconds. 4. </ins> Delaying acknowledgements as much as possible reduces both work done by the endpoints and network load.  An endpoint's loss detection and congestion control mechanisms however need to be tolerant of this
ACK-FREQUENCY frames have a type of 0xXX, and contain the following fields: <del> An optional variable-length integer representing the maximum number of ack-eliciting packets after which the receiver sends an acknowledgement. </del> <ins> A variable-length integer representing the maximum number of ack- eliciting packets after which the receiver sends an acknowledgement.  A value of 1 will result in an acknowledgement being sent for every ack-eliciting packet received.  A value of 0 is invalid. A variable-length integer representing an update to the peer's "max_ack_delay" transport parameter (Section 18.2 in QUIC- TRANSPORT).  The value of this field is in microseconds.  Any value smaller than the min_ack_delay advertised by this endpoint is invalid. </ins> <del> An optional variable-length integer representing the maximum amount of time, in microseconds, after which the receiver sends an acknowledgement.  The value of the Time Tolerance field is scaled by multiplying the encoded value by 2 to the power of the value of the "ack_delay_exponent" transport parameter set by the sender of the ACK-FREQUENCY frame (see Section XX in QUIC-TRANSPORT). Scaling in this fashion allows for a larger range of values with a shorter encoding at the cost of lower resolution. </del> <ins> Receipt of invalid values in an ACK-FREQUENCY frame MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> ACK-FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission.
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> <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 <del> delay sending acknowledgments; see Section XX of QUIC-TRANSPORT. </del> <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> <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> <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. <del> 4.1. </del> <ins> 5.1. </ins> To expedite loss detection, endpoints SHOULD send an acknowledgement immediately on receiving an ack-eliciting packet that is out of
The public key of the account key pair, encoded as a JSON Web Key object RFC7517. <del> "valid" or "deactivated" </del> <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
the client has accomplished the challenge. Once the validation process is complete and the server is satisfied <del> that the client has met its requirements, the server can either proactively issue the requested certificate or wait for the client to request that the application be "finalized", at which point the certificate will be issued and provided to the client. </del> <ins> that the client has met its requirements, the server will issue the requested certificate and make it available to the client. </ins> To revoke a certificate, the client simply sends a revocation request indicating the certificate to be revoked, signed with an authorized
A URL for the certificate that has been issued in response to this application. <del> [[ Open issue: There are two possible behaviors for the CA here. Either (a) the CA automatically issues once all the requirements are fulfilled, or (b) the CA waits for confirmation from the client that it should issue.  If we allow both, we will need a signal in the application object of whether confirmation is required.  I would prefer that auto-issue be the default, which would imply a syntax like "confirm": true ]] [[ Open issue: Should this syntax allow multiple certificates?  That would support reissuance / renewal in a straightforward way, especially if the CSR / notBefore / notAfter could be updated. ]] </del> The elements of the "requirements" array are immutable once set, except for their "status" fields.  If any other part of the object changes after the object is created, the client MUST consider the
then the server SHOULD change the status of the application to "invalid" and MAY delete the application resource. <del> The server SHOULD issue the requested certificate and update the </del> <ins> The server MUST issue the requested certificate and update the </ins> application resource with a URL for the certificate as soon as 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 <del> in the certificate in previous transactions), then the server MAY </del> <ins> in the certificate in previous transactions), then the server MUST </ins> proactively issue the requested certificate and provide a URL for it in the "certificate" field of the application.  The server MUST, however, still list the satisfied requirements in the "requirements"
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> <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 <del> contain the account URI received by POSTing to the new-reg resource. </del> <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
supported scheme but an invalid value then the server MUST return an error of type "invalidContact". <ins> If the server wishes to present the client with terms under which the ACME service is to be used, it MUST indicate the URL where such terms can be accessed in the "terms-of-service" subfield of the "meta" field in the directory object, and the server MUST reject new-account requests that do not have the "terms-of-service-agreed" set to "true".  Clients SHOULD NOT automatically agree to terms by default. Rather, they SHOULD require some user interaction for agreement to terms. </ins> The server creates an account and stores the public key used to verify the JWS (i.e., the "jwk" element of the JWS header) to authenticate future requests from the account.  The server returns this account object in a 201 (Created) response, with the account URL in a Location header field. <ins> 7.3.1. </ins> If the server already has an account registered with the provided account key, then it MUST return a response with a 200 (OK) status code and provide the URL of that account in the Location header field.  This allows a client that has an account key but not the <del> corresponding account URI to recover the account URL. </del> <ins> corresponding account URL to recover the account URL. </ins> <del> If the server wishes to present the client with terms under which the ACME service is to be used, it MUST indicate the URL where such terms can be accessed in the "terms-of-service" subfield of the "meta" field in the directory object, and the server MUST reject new-account requests that do not have the "terms-of-service-agreed" set to "true".  Clients SHOULD NOT automatically agree to terms by default. Rather, they SHOULD require some user interaction for agreement to terms. </del> <ins> If a client wishes to recover an existing account and does not want a non existing account to be created, then it SHOULD do so by sending a POST request with an empty update.  That is, it should send a JWS whose payload is an empty object ({}). 7.3.2. </ins> If the client wishes to update this information in the future, it sends a POST request with updated information to the account URL. The server MUST ignore any updates to "order" fields or any other <del> fields it does not recognize. </del> <ins> fields it does not recognize.  If the server accepts the update, it MUST return a response with a 200 (OK) status code and the resulting account object. </ins> For example, to update the contact information in the above account, the client could send the following request: <ins> 7.3.3. </ins> Servers SHOULD NOT respond to GET requests for account resources as these requests are not authenticated.  If a client wishes to query the server for information about its account (e.g., to examine the
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> <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
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> <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.
(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> <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.
8.1. <del> Several of the challenges in this document make use of a key </del> <ins> All challenges defined in this document make use of a key </ins> authorization string.  A key authorization is a string that expresses a domain holder's authorization for a specified key to satisfy a specified challenge, by concatenating the token for the challenge with a key fingerprint, separated by a "." character: The "JWK_Thumbprint" step indicates the computation specified in <del> RFC7638, using the SHA-256 digest FIPS180-4.  As noted in JWA RFC7518 any prepended zero octets in the fields of a JWK object MUST be stripped before doing the computation. </del> <ins> RFC7638, using the SHA-256 digest FIPS180-4.  As noted in RFC7518 any prepended zero octets in the fields of a JWK object MUST be stripped before doing the computation. </ins> As specified in the individual challenges below, the token for a challenge is a string comprised entirely of characters in the URL-