Subject: [Acme] Sections 9.7.1 and 7.3.2 are unclear

From: Kas <[email-masked]>
Date: Thu, 4 Oct 2018 21:24:58 +0300

From Section 9.7.1 :
"This registry lists field names that are defined for use in ACME 
account objects. Fields marked as “configurable” may be included in a 
new-account request."
"Client configurable:...."
"Initial contents: The fields and descriptions defined in Section 7.1.2"

1_ The section is unclear, if it is only for account objects listed in 
Section 7.1.2 then "externalAccountBinding" should not be listed or 
section 7.1.2 is missing "externalAccountBinding",which is defined as 
optional in Section 7.3 , along with "onlyReturnExisting" ,so should 
Section 9.7.1 contain other mentioned fields in other account sections 
like "oldKey" in (Section 7.3.5  Account Key Roll-over) ? ....!!??
2_ "status" is listed as not configurable while it is configurable in 
(Section 7.3.6. Account Deactivation) .

 From (7.3.2. Account Update) :
"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 the “orders” field, “termsOfServiceAgreed” 
field (see Section 7.3.3), the “status” field (except as allowed by 
Section 7.3.6), or any other fields it does not recognize. "

So basically server should check at first for "contact" field changes 
for every POST request and skip anything else, if that is the case then 
this logic should be mentioned in clear way in earlier sections, on 
other hand some changes to this sections might be enough to fix this and 
remove any confusion, so i suggest changing that paragraph to the 
following :
"If the client wishes to update this information in the future, it sends 
a POST request with updated information to the account URL. The request 
MUST NOT contain "orders" field, “termsOfServiceAgreed” field, “status” 
field or "externalAccountBinding" field, and should contain "contact" 
field with the updated account information. If the server accepts the 
update, it MUST return a response with a 200 (OK) status code and the 
resulting account object."

There is no need to mention (Section 7.3.6) as it is very clear, all 
responses from POST or POST-as-GET to a deactivated account MUST be 
unauthorized error response.

Last thing : (Sections 9.7 New Registries) has sections 9.7.1 , 9.7.2 
and 9.7.3 describing Account Objects, Order Objects and Authorization 
Objects and that i think cover all, except for 7.6. Certificate 
Revocation identifiers which left out , "certificate" and "reason" 
fields are new and deserve to be registered.

Kind regards,
K. Obaideen