Original text:
against an intermediary changing the request URL to another ACME URL. As noted in request-authentication above, all ACME request objects <del> carry a "url" parameter in their protected header.  This header parameter encodes the URL to which the client is directing the </del>  request.  On receiving such an object in an HTTP request, the server <del> MUST compare the "url" parameter to the request URL.  If the two do not match, then the server MUST reject the request as unauthorized. </del>  Except for the directory resource, all ACME resources are addressed with URLs provided to the client by the server.  For these resources, <del> the client MUST set the "url" field to the exact string provided by the server (rather than performing any re-encoding on the URL).  The server SHOULD perform the corresponding string equality check, configuring each resource with the URL string provided to clients and having the resource check that requests have the same string in their "url" fields. </del>  6.3.1. The "url" header parameter specifies the URL RFC3986 to which this <del> JWS object is directed.  The "url" parameter MUST be carried in the protected header of the JWS.  The value of the "url" header MUST be a string representing the URL. </del>  6.4. The status of this account.  Possible values are: "valid", "deactivated", and "revoked".  The value "deactivated" should be <del> used to indicate user initiated deactivation whereas "revoked" should be used to indicate administratively initiated deactivation. </del>  An array of URIs that the server can use to contact the client for issues related to this account.  For example, the server may wish authorization valid for all orders until the authorization expires. <del> The challenges that the client can fulfill in order to prove possession of the identifier (for pending authorizations).  For final authorizations, the challenges that were used.  Each array entry is an object with parameters required to validate the challenge.  A client should attempt to fulfill one of these challenges, and a server should consider any one of the challenges sufficient to make the authorization valid.  For final authorizations it contains the challenges that were completed. </del>  The only type of identifier defined by this specification is a fully- qualified domain name (type: "dns").  If a domain name contains non- request-authentication).  The inner JWS MUST meet the normal requirements, with the following exceptions: <del> The inner JWS MUST have the same "url" parameter as the outer JWS. </del>  <del> The inner JWS is NOT REQUIRED to have a "nonce" parameter.  The server MUST ignore any value provided for the "nonce" header </del>  parameter. This transaction has signatures from both the old and new keys so

Reviewer comments:
This pull request includes changes to: Consistently use "header parameter" when referring to JWS header parameters. Insert a missing right curly bracket in a section reference. Use "server-initiated" instead of "administratively initiated" for clarity. Use parallel sentence structure for clarity/readability.

Revised text:
against an intermediary changing the request URL to another ACME URL. As noted in request-authentication above, all ACME request objects  <ins> carry a "url" header parameter in their protected header.  This header parameter encodes the URL to which the client is directing the </ins> request.  On receiving such an object in an HTTP request, the server  <ins> MUST compare the "url" header parameter to the request URL.  If the two do not match, then the server MUST reject the request as unauthorized. </ins> Except for the directory resource, all ACME resources are addressed with URLs provided to the client by the server.  For these resources,  <ins> the client MUST set the "url" header parameter to the exact string provided by the server (rather than performing any re-encoding on the URL).  The server SHOULD perform the corresponding string equality check, configuring each resource with the URL string provided to clients and having the resource check that requests have the same string in their "url" header parameter. </ins> 6.3.1. The "url" header parameter specifies the URL RFC3986 to which this  <ins> JWS object is directed.  The "url" header parameter MUST be carried in the protected header of the JWS.  The value of the "url" header parameter MUST be a string representing the URL. </ins> 6.4. The status of this account.  Possible values are: "valid", "deactivated", and "revoked".  The value "deactivated" should be  <ins> used to indicate client-initiated deactivation whereas "revoked" should be used to indicate server-initiated deactivation. </ins> An array of URIs that the server can use to contact the client for issues related to this account.  For example, the server may wish authorization valid for all orders until the authorization expires.  <ins> For pending authorizations, the challenges that the client can fulfill in order to prove possession of the identifier.  For final authorizations, the challenges that were used.  Each array entry is an object with parameters required to validate the challenge. A client should attempt to fulfill one of these challenges, and a server should consider any one of the challenges sufficient to make the authorization valid.  For final authorizations it contains the challenges that were completed. </ins> The only type of identifier defined by this specification is a fully- qualified domain name (type: "dns").  If a domain name contains non- request-authentication).  The inner JWS MUST meet the normal requirements, with the following exceptions:  <ins> The inner JWS MUST have the same "url" header parameter as the outer JWS. </ins>  <ins> The inner JWS is NOT REQUIRED to have a "nonce" header parameter. The server MUST ignore any value provided for the "nonce" header </ins> parameter. This transaction has signatures from both the old and new keys so