PR for 1.-3.
<https://github.com/ietf-wg-acme/acme/pull/280>

PR for 4.
<https://github.com/ietf-wg-acme/acme/pull/281>

Issue related to 4.
<https://github.com/ietf-wg-acme/acme/issues/278>

On 20/02/17 16:17, Sophie Herold wrote:
> 1.
>   I cannot find where the response to account updates is specified.
> 
>   Boulder replies with "202 Accepted" and an account object. Since
>   updates with trivial payload should be used for account information,
>   it seems to be expected that an account object is returned. The
>   specified response status for "Account deactivation" is "200 OK".
>   It would be consistent to specify the same response status for
>   account updates I guess?
> 
> 2.
>   The client should be able to choose between "Account URI recovery"
>   and "Account Creation", if needed. A possible way would be to clarify
>   that account creations with trivial payload MUST be rejected. However,
>   if an account exists, the "Content-Location" header and "200 OK" is
>   returned, independent of the payloads content. Therefore a trivial
>   payload could be used to check if an account with the used key exists,
>   without creating it.
> 
> 3.
>   As "6.3.4.  Account deactivation", other queries should get their own
>   sub-sub sections. Something like
>    - "6.3.x Account URI recovery" ("new-account", maybe trivial payload)
>    - "6.3.x Account update"
>    - "6.3.x Account information" (update with trivial payload)
> 
> 4.
>   Is it really an account URI or rather an account URL? Some fields
>   changed from "uri" to "url". I guess, all occurrences of URIs should
>   be URLs. The only exception that I see is the "type" field in the
>   "Problem Details" responses.
> 

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Reply via email to