On 11/21/2017 04:06 PM, Martin Thomson wrote:
> I ask because your example highlighted two types of problems. That
> they could be aggregated doesn't seem an necessary or innate property.
>
> The difficulty with the sort of aggregation design you propose is that
> you need to aggregate and I
On Wed, Nov 22, 2017 at 5:55 AM, Jacob Hoffman-Andrews wrote:
> On 11/20/2017 08:24 PM, Martin Thomson wrote:
>> Is this better cast as "sub" problems, or just "additional" problems?
>
> I think "additional" is the wrong semantic, because it implies that the
> first error is hoisted
On 11/21/2017 11:48 AM, Niklas Keller wrote:
> How about "causes"?
I think this also implies more meaning than there really is. It also has
the unfortunate property of being both a plural noun and a transitive
verb, which could be confusing.
Is there a problem with sub-problems?
2017-11-21 19:55 GMT+01:00 Jacob Hoffman-Andrews :
> On 11/20/2017 08:24 PM, Martin Thomson wrote:
> > Is this better cast as "sub" problems, or just "additional" problems?
>
> I think "additional" is the wrong semantic, because it implies that the
> first error is hoisted to the
On 11/20/2017 08:24 PM, Martin Thomson wrote:
> Is this better cast as "sub" problems, or just "additional" problems?
I think "additional" is the wrong semantic, because it implies that the
first error is hoisted to the top position, so a naive client would only
show the first error. Instead,
Is this better cast as "sub" problems, or just "additional" problems?
On Tue, Nov 21, 2017 at 10:19 AM, Jacob Hoffman-Andrews wrote:
> I've submitted a PR adding this to the spec:
>
> https://github.com/ietf-wg-acme/acme/pull/354
>
> commit a6cc0aedf96067e8b3aaf37662785fcf8b38dd18
I think this is a solid proposal addressing a real need. I'm +1 for
supporting it both in spec and in Boulder/Pebble.
Thanks Jacob,
On Wed, Nov 15, 2017 at 8:23 PM, Jacob Hoffman-Andrews wrote:
> In previous versions of ACME, there was sometimes a need to return
> multiple
Oh, my bad, my eyes turn out to be a terrible JSON parser.
On Thu, Nov 16, 2017 at 4:49 PM, Matthew A. Miller
wrote:
> On 17/11/16 16:47, Jacob Hoffman-Andrews wrote:
>> On 11/16/2017 12:45 AM, Martin Thomson wrote:
>>> I don't know what a random JSON parser
On 17/11/16 16:47, Jacob Hoffman-Andrews wrote:
> On 11/16/2017 12:45 AM, Martin Thomson wrote:
>> I don't know what a random JSON parser would do with your stacked error
>> codes.
> I don't understand. What I'm proposing is an array of JSON objects under
> the sub-problems field, which should be
On 11/16/2017 12:45 AM, Martin Thomson wrote:
> I don't know what a random JSON parser would do with your stacked error codes.
I don't understand. What I'm proposing is an array of JSON objects under
the sub-problems field, which should be supported by any JSON parser.
Have you considered json text sequences: https://tools.ietf.org/html/rfc7464 ?
I don't know what a random JSON parser would do with your stacked error codes.
On Thu, Nov 16, 2017 at 3:54 PM, Jacob Hoffman-Andrews wrote:
> On 11/15/2017 07:07 PM, Richard Barnes wrote:
>> Following
On 11/15/2017 07:07 PM, Richard Barnes wrote:
> Following Daniel's lead on looking for implementation: Is this
> something LE would be implementing?
Yep, we would definitely implement this. I'll send a PR.
___
Acme mailing list
Acme@ietf.org
This sounds pretty inoffensive to me. Want to send a PR?
Following Daniel's lead on looking for implementation: Is this something LE
would be implementing?
On Thu, Nov 16, 2017 at 9:23 AM, Jacob Hoffman-Andrews wrote:
> In previous versions of ACME, there was sometimes a need to
In previous versions of ACME, there was sometimes a need to return
multiple errors, broken out by domain name. For instance, when issuing a
certificate by making a new-cert request, the CA has to check CAA, which
may fail for multiple domains. Ideally, the client should not have to
guess which
14 matches
Mail list logo