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 [email protected] https://www.ietf.org/mailman/listinfo/acme
