Re: [Acme] Returning multiple errors

2017-11-21 Thread Jacob Hoffman-Andrews 
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 don't know what the logic would be in the
> general case.  On the other hand, additional problems are easy to
> accumulate and emit.  They are also easy to consume, either by just
> doing the dumb thing and handling only the first, or by working
> through a list.
> 
> The alternative is to provide a specific type (e.g.,
> "urn:ietf:params:acme:error:multiple"), that says "there were multiple
> problems", and list the real problems in the body.  The text for the
> specific type could be more helpful - just as in your example - or
> not.

The current text allows the CA to choose whatever error type at the top
level it wants, including its own type. I think that flexibility is
fine. Is your main problem that this doesn't specify a top-level
"multiple" error type?

> list the real problems in the body

This is insufficient, because the goal is to allow clients to
programmatically remove identifiers from a request. So we need some
specific field in JSON.

We can't have a raw list, because identifiers are objects, not strings.
So we have a list of objects containing identifiers. It happens to be
handy to attach a type and a value to each.

>  additional problems are easy to accumulate and emit.

As an implementer, I find sub-problems easy and more natural than a list
of problems that gets appended to.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Returning multiple errors

2017-11-21 Thread Martin Thomson 
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 to the top position, so a naive client would only
> show the first error. Instead, there's a top-level generic error ("some
> identifiers were rejected"), and then there are potentially multiple
> errors that are part of it (_example.com, example.net).

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 don't know what the logic would be in the
general case.  On the other hand, additional problems are easy to
accumulate and emit.  They are also easy to consume, either by just
doing the dumb thing and handling only the first, or by working
through a list.

The alternative is to provide a specific type (e.g.,
"urn:ietf:params:acme:error:multiple"), that says "there were multiple
problems", and list the real problems in the body.  The text for the
specific type could be more helpful - just as in your example - or
not.

"sub-problems" seems like the worst of these options.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Returning multiple errors

2017-11-21 Thread Jacob Hoffman-Andrews 
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?

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Returning multiple errors

2017-11-21 Thread Niklas Keller 
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 top position, so a naive client would only
> show the first error. Instead, there's a top-level generic error ("some
> identifiers were rejected"), and then there are potentially multiple
> errors that are part of it (_example.com, example.net).


How about "causes"?

Regards, Niklas
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Returning multiple errors

2017-11-21 Thread 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 top position, so a naive client would only
show the first error. Instead, there's a top-level generic error ("some
identifiers were rejected"), and then there are potentially multiple
errors that are part of it (_example.com, example.net).

> 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
>> Author: Jacob Hoffman-Andrews 
>> Date:   Mon Nov 20 15:14:29 2017 -0800
>>
>> Define sub-problems.
>>
>> diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md
>> index a2c11ab..a9e3535 100644
>> --- a/draft-ietf-acme-acme.md
>> +++ b/draft-ietf-acme-acme.md
>> @@ -521,6 +521,53 @@ set to a URI other than those defined above.
>> Servers MUST NOT use the ACME URN
>>  namespace for errors other than the standard types.  Clients SHOULD
>> display the
>>  "detail" field of all errors.
>>
>> +### Sub-problems
>> +
>> +Sometimes a CA may need to return multiple errors to a single
>> +request. Additionally, the CA may need to attribute errors to specific
>> +identifiers.  For instance, a new-order request may contain multiple
>> +identifiers for which the CA cannot issue. In this situation, an ACME
>> +problem document MAY contain the "sub-problems" field, contains a JSON
>> +array of problem documents, each of which MAY contain an "identifier"
>> +field. If present, the "identifier" field MUST contain an ACME identifier
>> +({{iana-identifier}}). The "identifier" field MUST NOT be present at
>> +the top level in ACME problem documents. It can only be present in
>> sub-problems.
>> +Sub-problems need not all have the same type, and do not need to match
>> the top level type.
>> +
>> +ACME clients may choose to use the "identifier" field as a hint that
>> +an operation would succeed if certain identifiers were omitted. For
>> +instance, if an order contains ten DNS identifiers, and the new-order
>> +request returns a problem document with two sub-problems, referencing two
>> +of those identifiers, the ACME client may choose to submit another order
>> +containing only the eight identifiers not listed in the problem document.
>> +
>> +~
>> +HTTP/1.1 403 Forbidden
>> +Content-Type: application/problem+json
>> +
>> +{
>> +"type": "urn:ietf:params:acme:error:malformed",
>> +"detail": "Some of the identifiers requested were rejected",
>> +"sub-problems": [
>> +{
>> +"type": "urn:ietf:params:acme:error:malformed",
>> +"value": "Invalid underscore in DNS name \"_example.com\"",
>> +"identifier": {
>> +"type": "dns",
>> +"value": "_example.com"
>> +}
>> +},
>> +{
>> +"type": "urn:ietf:params:acme:error:rejectedIdentifier",
>> +"value": "This CA will not issue for \"example.net\"",
>> +"identifier": {
>> +"type": "dns",
>> +"value": "example.net"
>> +}
>> +}
>> +]
>> +}
>> +~
>>
>>  # Certificate Management
>>
>> ___
>> 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 mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme