Subject: Re: [Acme] Application/Authorization statuses

From: Daniel McCarney <[email-masked]>
Date: Tue, 6 Sep 2016 14:18:43 -0400

+1.

Removing 'processing' and 'unknown' makes sense to me. I think the
remaining statuses are comprehensive enough.

On Fri, Aug 26, 2016 at 6:12 PM, Roland Bracewell Shoemaker <
[email-masked]> wrote:

> Currently the specification defines the statuses 'unknown' and
> 'processing' as valid for both applications and authorizations. Given
> that both also have 'valid', 'pending', and 'invalid' I can't really see
> a reason to keep 'unknown' and for applications in particular the
> meaning of 'processing' seems quite similar to 'pending' (whereas with
> an authorization I think it makes sense when a validation is actively
> being done by the server).
>
> Any objections to removing these statuses?
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Ron <[email-masked]>
Date: Wed, 7 Sep 2016 14:18:04 +0930

> remaining statuses are comprehensive enough.

I agree with this.  It was one of the original review nits I posted
to this list many months back.

'unknown' was basically an internal state of Boulder that had no real
reason to ever be leaked out into a protocol message, and the
distinction between 'pending' and 'processing' was never defined in
the spec, only as an implementation detail of Boulder (though it did
make some sense how Boulder was using it).

I still think it would also be useful for the spec to give some
definition for what each of the remaining statuses are supposed to
mean and when a server should send them, and some guidance for what
a client should do if it receives them - even though that should be
a bit more obvious now if we prune away the more ambiguous ones.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 8 Sep 2016 13:17:56 -0400

This sounds fine to me too, though I have some quibbles with the PRs.

- We should get rid of "processing" globally (#186 leaves it for
authorizations)
- It seems duplicative to have "deactivated", "revoked", and "invalid".
Maybe we can keep "invalid" as "this failed without ever being valid", but
let's decide on one for "this was valid, and is no longer".  Between
"deactivated" and "revoked", I slightly prefer "revoked", but then it seems
like we should change the wording of the sections about deactivation to
talk about revocation instead.   Not something I want to waste a lot of
bikeshed paint on, though.

Roland, if you could update the PRs, sounds like we could go ahead and
merge.

---

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Thu, 8 Sep 2016 17:00:40 -0700

On 09/08/2016 10:17 AM, Richard Barnes wrote:
> Maybe we can keep "invalid" as "this failed without ever being valid",
> but let's decide on one for "this was valid, and is no longer".  Between
> "deactivated" and "revoked", I slightly prefer "revoked", but then it
> seems like we should change the wording of the sections about
> deactivation to talk about revocation instead.   Not something I want to
> waste a lot of bikeshed paint on, though.

The reason for having 'deactivated' and 'revoked' was to differentiate
accounts disabled by a user voluntarily and accounts disabled
administratively for terms violations etc.

> On Wed, Sep 7, 2016 at 12:48 AM, Ron <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     > [email-masked] <mailto:[email-masked]>> wrote:
>     >
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/acme>
> 
>