On Wed, Nov 22, 2017 at 5:55 AM, Jacob Hoffman-Andrews <j...@eff.org> 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
