Mostly fine, some comments: If a server processes different things in parallel, multiple errors could occur. Should the "error" field be an array?
Moreover, is there any utility in mandating that this "error" field only be used after (all?) authorizations have been completed? That meshes with the implementation model this list is expecting, but it seems simpler from a client implmentation perspective simply for the client to balk whenever it retrieves an order object which has an error set on it. This maximizes the flexibility of implementation on the server side. On Fri, Feb 17, 2017 at 01:02:07PM -0800, Jacob Hoffman-Andrews wrote: > Introduces an error field for orders. Orders can fail independent of > authorizations because of last-minute CAA checking, failure to submit to > CT logs, timeouts, etc. -- Hugo Landau I know of no warrant or notice of a kind defined within the Investigatory Powers Act 2016 or the Regulation of Investigatory Powers Act 2000 that has not been brought to the attention of the public. I will always answer questions about these or similar matters, assuming reasonable request rates, unless legally prevented from doing so. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
