Change:
A refinement on Servers reflect their state in and Clients can request a retry by re-ing

Discussion:
encoded in the format specified in RFC 3339 RFC3339.  This field is REQUIRED if the "status" field is "valid". <del> The error that occurred while the server was validating the challenge, if any.  This field is structured as a problem document RFC7807. </del> <ins> Errors that occurred while the server was validating the challenge, if any, structured as problem documents RFC7807.  The server MUST NOT modify the array except by appending entries onto the end.  The server can limit the size of this object by limiting the number of times it will retry a challenge. </ins> All additional fields are specified by the challenge type.  If the server sets a challenge's "status" to "invalid", it SHOULD also

8.2. <ins> ACME challenges typically require the client to set up some network- accessible resource that the server can query in order to validate that the client controls an identifier.  In practice it is not uncommon for the server's queries to fail while a resource is being set up, e.g., due to information propagating across a cluster or firewall rules not being in place. Clients SHOULD NOT respond to challenges until they believe that the server's queries will succeed.  If a server's initial validation query fails, the server SHOULD retry the query after some time. While the server is still trying, the status of the challenge remains "pending"; it is only marked "invalid" once the server has given up. The server MUST provide information about its retry state to the client via the "errors" field in the challenge and the Retry-After HTTP header field in response to requests to the challenge resource. The server MUST add an entry to the "errors" field in the challenge after each failed validation query.  The server SHOULD set the Retry- After header field to a time after the server's next validation query, since the status of the challenge will not change until that time. Clients can explicitly request a retry by re-sending their response to a challenge in a new POST request (with a new nonce, etc.).  This allows clients to request a retry when state has changed (e.g., after firewall rules have been updated).  Servers SHOULD retry a request immediately on receiving such a POST request.  In order to avoid denial-of-service attacks via client-initiated retries, servers SHOULD rate-limit such requests. 8.3. </ins> With HTTP validation, the client in an ACME transaction proves its control over a domain name by proving that for that domain name it can provision resources to be returned by an HTTP server.  The ACME

successful.  If the request fails, or the body does not pass these checks, then it has failed. <del> 8.3. </del> <ins> 8.4. </ins> The TLS with Server Name Indication (TLS SNI) validation method proves control over a domain name by requiring the client to

If all of the above verifications succeed, then the validation is successful.  Otherwise, the validation fails. <del> 8.4. </del> <ins> 8.5. </ins> When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a TXT resource record

successful.  If no DNS record is found, or DNS record and response payload do not pass these checks, then the validation fails. <del> 8.5. </del> <ins> 8.6. </ins> There may be cases where a server cannot perform automated validation of an identifier, for example, if validation requires some manual