On 02/19/2017 06:54 PM, Hugo Landau wrote:
> If a server processes different things in parallel, multiple errors
> could occur. Should the "error" field be an array?
Reading the Problem Document spec, it seems like the expected way to
handle multiple errors is with fields within the problem
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
On 02/17/2017 02:41 PM, Roland Bracewell Shoemaker wrote:
> Splitting the tables up based on where the errors may be encountered is
> useful but adding the new 'error' field to the order object makes this
> slightly confusing. Will the errors on the order be from the first table
> or the second,
+1 this seems like a good change. I've left one typo comment on the PR
(code -> type).
Splitting the tables up based on where the errors may be encountered is
useful but adding the new 'error' field to the order object makes this
slightly confusing. Will the errors on the order be from the first
https://github.com/ietf-wg-acme/acme/pull/264
Removes dnssec error type for a broader "dns" error type. It's very hard
to split out dnssec errors from regular dns problems, because recursive
resolvers can only return SERVFAIL. The new dns error type also subsumes
"unknownHost."
Introduces a new
