Original text:
In addition to the human readable "detail" field of the error response, the server MAY send one or multiple tokens in the "Link" header pointing to documentation about the specific hit rate limits <del> using the "rate-limit" relation. </del>  5.7. client may fetch a chain of CA certificates that could be used to validate the certificate in the original resource. <del> The "directory" link relation is present on all resources other than the directory and indicates the directory URL. </del>  The following diagram illustrates the relations between resources on an ACME server.  For the most part, these relations are expressed by anchors.  Clients can fetch these alternates and use their own heuristics to decide which is optimal. <del> The server MUST also provide a link relation header field with relation "author" to indicate the order under which this certificate was issued. If the CA participates in Certificate Transparency (CT) RFC6962, then they may want to provide the client with a Signed Certificate Timestamp (SCT) that can be used to prove that a certificate was submitted to a CT log.  An SCT can be included as an extension in the certificate or as an extension to OCSP responses for the certificate. The server can also provide the client with direct access to an SCT for a certificate using a Link relation header field with relation "ct-sct". </del> A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new order process to request one.

Reviewer comments:
As they are all fulfilled by the endpoint and are unnecessary. The relation is removed as the SCT will be provided by the CA via the certificate or a OCSP response, if it doesn't provide these then the client should be able to retrieve the SCT itself from the logs it expects to find the certificate in (or submit it itself). Also removes a paragraph about Certificate Transparency from the 'Downloading the Certificate' section as it is irrelevant to the section and discusses operations of the CA unrelated to the ACME protocol. Additionally changes the relation which is not registered with a URI extension using the ACME URN namespace .
Looks good. Was posted on the list two weeks ago, with no objections, so merging.

Revised text:
In addition to the human readable "detail" field of the error response, the server MAY send one or multiple tokens in the "Link" header pointing to documentation about the specific hit rate limits  <ins> using the "urn:ietf:params:acme:documentation" relation. </ins> 5.7. client may fetch a chain of CA certificates that could be used to validate the certificate in the original resource.  <ins> The "index" link relation is present on all resources other than the directory and indicates the directory URL. </ins> The following diagram illustrates the relations between resources on an ACME server.  For the most part, these relations are expressed by anchors.  Clients can fetch these alternates and use their own heuristics to decide which is optimal.  A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new order process to request one.