Original text:
supported scheme but an invalid value then the server MUST return an error of type "invalidContact".  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.  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>  <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>  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>  For example, to update the contact information in the above account, the client could send the following request:  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

Reviewer comments:
This PR is a first go at addressing the following points I raised on the mailing list.
This allows us to address the account URL recovery use case in without having special handling for empty payloads.

Revised text:
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  <ins> corresponding account URL to recover the account URL. </ins>  <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  <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