Re: [Acme] "Status" field clarification
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 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" 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
Re: [Acme] "Status" field clarification
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" 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
[Acme] "Status" field clarification
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
