The following feedback is based on 8010a31 (current HEAD of master). Section 7.3, Account Creation, states "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 URI of that account in the Location header field. This allows a client that has an account key but not the corresponding account URI to recover the account URI."
This section does not specify what the server should do with the data in the request payload, such as contact information. Ignoring the data from the request, using the data from the request to update the registered account, and union-ing the data from the two sources each seem like sane implementation decisions. This may lead to significant behavioral differences between server implementations, complicating client implementation. I would propose either: a) Indicating that the server must discard the information from the account creation request in this case. b) Indicating that the server must treat the request as an account update operation. Given that updating the account as a part of the recovery operation could be perceived as a surprising side effect and given that there is already a well-defined way to perform an update to an account, I would prefer option (a). Regards, Zach Shepherd
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
