Good catch. I think the right answer is to keep the challenge in "processing". We already have the following text in "Retrying Challenges" (amended s/pending/processing/):
""" While the server is still trying, the status of the challenge remains “pending”; it is only marked “invalid” once the server has given up. """ I added some prose and tweaked the diagram to show retry events leading the processing state back to itself: https://github.com/ietf-wg-acme/acme/pull/400/commits/bfaf4231ffb26309f71913f3e1cb03c6e7cd0e18 Thanks, --Richard On Fri, Mar 2, 2018 at 9:31 AM, Logan Widick <logan.wid...@gmail.com> wrote: > Are challenge retries still supported? If so, how will retries affect the > state transitions? What state would a server use to indicate that something > had an error but could be retried later? > > Sincerely, > > Logan Widick > > On Mar 2, 2018 08:04, "Richard Barnes" <r...@ipv.sx> wrote: > > Hey all, > > We had a couple of GitHub issues and mailing list posts expressing > confusion about the "status" field in ACME objects. To try to clear all of > that up, I've posted a PR that lays out required state transitions and > aligns the field descriptions with that description. All the description > should look very familiar. The only innovation is to introduce a "ready" > state on orders, to give clients an easy way to know when to finalize. > > https://github.com/ietf-wg-acme/acme/pull/400 > > As you're probably aware the I-D deadline is Monday, so please send > comments ASAP. If I don't hear anything back from this list, I'll confer > with my fellow editors and we'll make a unilateral decision for us to > discuss in London (and obviously roll back if needed). > > Thanks, > --Richard > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
