I'm not totally sold on the utility of including extra information in the ARI response, if that extra information will not modify client behavior. If the purpose is to modify human behavior, then I believe the current explanationURL is sufficient. Adding a machine-readable problem document that would only be read by machines that are not part of the ACME client/server relationship feels odd to me.
Aaron On Wed, Mar 22, 2023 at 1:31 PM Andrew Ayer <a...@andrewayer.name> wrote: > Hi Corey, > > On Wed, 22 Mar 2023 17:55:59 +0000 > Corey Bonnell <Corey.Bonnell=40digicert....@dmarc.ietf.org> wrote: > > > Hi Andrew, > > Is the purpose of the "revocationTime" field such that ACME client > > behavior would be different than the recommended replacement > > time-selection algorithm in section 4.1, or is it to provide richer > > metadata about the pending replacement window that is potentially > > human or machine-readable? > > It is the latter - to provide richer metadata about why the window is > what it is. ACME client behavior would not be affected. > > > If the latter, I'm wondering if we could consider defining a RFC > > 7807-style "problem document" format that would provide fuller > > information that is both human- and machine-readable. The > > "explanationURL" field as it currently exists in the draft might be > > useful for conveying human-readable information, but defining a > > fuller representation of replacement-related metadata would also > > allow machine-readable information to be conveyed. > > That could potentially be useful. Do you have any other information in > mind that would be included? > > Regards, > Andrew > > _______________________________________________ > 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
