Re: [Acme] Renewal Information extension: Proposal to add an Explanation URL

In fact, what BCP 18 has to say on the matter is:
> ...protocols are not subject to internationalization; text strings are.
So yes, the appropriate place for internationalization here would be at the
level of the site pointed at by the URI, not at the level of the URI itself.

Regardless, I like this proposal. It provides good value (especially for
certificate monitoring services) at very little cost (completely optional
for both server and client). It does feel a little odd to include something
directly in the protocol that is not actually intended for consumption by
most ACME clients (they're non-interactive, the most they're likely to do
is log it to a file their operator isn't going to look at anyway). But I
think it makes sense to recognize the reality of the current ecosystem.
ACME clients do one thing well -- renew certs. Cert monitors do one thing
well -- alert site operators when something unusual is happening. No reason
not to enable both.

Aaron

On Mon, Feb 14, 2022 at 1:17 AM Stefan Eissing <stefan@eissing.org> wrote:

>
>
> > Am 13.02.2022 um 06:39 schrieb Benjamin Kaduk <kaduk@mit.edu>:
> >
> > On Thu, Feb 10, 2022 at 02:31:15PM -0500, Michael Richardson wrote:
> >>
> >> J.C. Jones <ietf@insufficient.coffee> wrote:
> >>> Hence, I propose we add an optional field to the ARI response
> >>> structure, "explanationURL", which when populated should be presented
> >>> in any user-visible context (logging, alerting, etc) by the
> >>> ARI-compatible client. It would be up to the Certificate Authority to
> >>> ensure the URL presented appropriately translated information for the
> >>> operator, and the CA _should_ only provide the field if there was
> >>> something exceptional that warranted additional explanation or
> >>> context.
> >>
> >> Sounds good.
> >>
> >> If it's for human consumption, then it might need to be an array or
> dict,
> >> with per-language versions.
>
> Unnecessary. HTTP servers can redirect to language specific resources just
> fine. Let's not i18n the protocol urls, please.
>
> >
> > Yes, BCP 18 has a few things to say on this matter.
> >
> > -Ben
> >
> > _______________________________________________
> > 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
>