On 11/28/2016 06:37 PM, Richard Barnes wrote: > I actually thought you were the one that suggested we keep the > "status" fields
Nope, I have always been in favor of not inlining the status fields. We talked about this directly, but also it was in my previous PR and thread about merging requirements and authorizations: >> 3. "Inline" the authorization objects into the order/application object, just as challenges are inlined into authorizations (while still keeping them addressable, as challenges are) > I don't see the need for this, and actually think it's a negative. GETs are cheap for the client, especially with HTTP/2. Inlining like this means there are two ways for a client to check the status of an authorization: by polling the authz, or by polling the application / order. We've seen in Boulder that having two ways to do things leads to bugs, so I'd rather say you must poll the authorization. > Also, for orders with lots of authz's in them, polling the order object will be more expensive for the server than polling individual authzs, because each poll of the order object has to reconstruct a larger number of objects from the DB. When clients poll individual authzs, they only check each authz until it is done, then stop. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
