Original text:
In order to help clients configure themselves with the right URLs for each ACME operation, ACME servers provide a directory object.  This should be the only URL needed to configure clients.  It is a JSON <del> object, whose keys are drawn from the following table and whose values are the corresponding URLs. </del>  There is no constraint on the actual URL of the directory except that it should be different from the other ACME server resources' URLs, a host which only functions as an ACME server could place the directory under the path "/". <del> The object MAY additionally contain a key "meta".  If present, it </del>  MUST be a JSON object; each field in the object is an item of metadata relating to the service provided by the ACME server. reflect them as already valid in any orders submitted by the client. If a CA wishes to allow pre-authorization within ACME, it can offer a <del> "new authorization" resource in its directory by adding the key "new- authz" with a URL for the new authorization resource. </del>  To request authorization for an identifier, the client sends a POST request to the new-authorization resource specifying the identifier Template: <del> Field name: The string to be used as a key in the JSON object </del>  Field type: The type of value to be provided, e.g., string, boolean, array of string Template: <del> Key: The value to be used as a field name in the directory object </del>  <del> Resource type: The type of resource labeled by the key </del>  Reference: Where the resource type is defined

Reviewer comments:
In the JSON , could be called a "field name" or a "key." We use both in this document, but we should consolidate one one. I think "field name" is better (and NAME agrees). In part this avoids any ambiguity with cryptographic keys.

Revised text:
In order to help clients configure themselves with the right URLs for each ACME operation, ACME servers provide a directory object.  This should be the only URL needed to configure clients.  It is a JSON  <ins> object, whose fields names are drawn from the following table and whose values are the corresponding URLs. </ins> There is no constraint on the actual URL of the directory except that it should be different from the other ACME server resources' URLs, a host which only functions as an ACME server could place the directory under the path "/".  <ins> The object MAY additionally contain a field "meta".  If present, it </ins> MUST be a JSON object; each field in the object is an item of metadata relating to the service provided by the ACME server. reflect them as already valid in any orders submitted by the client. If a CA wishes to allow pre-authorization within ACME, it can offer a  <ins> "new authorization" resource in its directory by adding the field "new-authz" with a URL for the new authorization resource. </ins> To request authorization for an identifier, the client sends a POST request to the new-authorization resource specifying the identifier Template:  <ins> Field name: The string to be used as a field name in the JSON object </ins> Field type: The type of value to be provided, e.g., string, boolean, array of string Template:  <ins> Field name: The value to be used as a field name in the directory object </ins>  <ins> Resource type: The type of resource labeled by the field </ins> Reference: Where the resource type is defined