Hi Zach, I agree with your assessment. I think adding language specifying that the server not treat the account creation request as an update to the existing account is the best option.
- Daniel On Wed, Mar 22, 2017 at 1:14 AM, Zach Shepherd <[email protected]> wrote: > 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 > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
