Subject: [Acme] UX design by standards

From: Josh Soref <[email-masked]>
Date: Fri, 17 Feb 2017 08:42:06 -0500

I'm still working on reviewing the document. I have one large PR which
I haven't finished and haven't published, and I have an entire design
issue (relating to errors) which I want to talk about. (And I need to
file a bug against rfc7807.) But...

> Clients SHOULD display the "detail" field of all errors. [1]

I'm reminded ... there was one specification (i can't remember if it
was Cookie, HTTP, or HTML) which had a UAs must tell users about
something (redirects? cookies?).

Browser authors never implemented the thing I'm thinking about (all I
remember is this quirk, I can't remember which thing it was).

[1] https://github.com/ietf-wg-acme/acme/blob/68a87b4/draft-ietf-acme-acme.md#errors

---

From: Martin Thomson <[email-masked]>
Date: Sat, 18 Feb 2017 21:07:24 +1100

> something (redirects? cookies?).

HTTP did, at one time have such text.  I would agree with you that
attempting to push messages on users is foolish.  Record the details
in a log, sure, but trying to find a user, that's not gonna happen if
you are running acme clients on 1000s of machines.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Sat, 18 Feb 2017 10:40:22 -0800

> you are running acme clients on 1000s of machines.
This is a fair point. The language here is in response to one client
that is interactive, but chose to display the "Description" from the
errors table rather than the detail field. This was a problem because
one error type can manifest with a lot of different details, so exposing
the detail field to the end user in some way is critical. I don't think
it matters whether the end user interacts primarily through log
aggregation or interactively.

Do you have proposed alternate langauge, given the above?

---

From: Josh Soref <[email-masked]>
Date: Sat, 18 Feb 2017 21:39:59 -0500

Jacob Hoffman-Andrews wrote:
> errors table rather than the detail field.

The solution here is probably to say not to do that!
Something like "the description field here is general advice to server
implementations to indicate whether a condition fits a message, it is
not designed for clients to report to their users." (This is not RFC
spec format, but perhaps it's a useful direction.)

> This was a problem because

> Do you have proposed alternate langauge, given the above?

I intend to write something more detailed about this entire area
(error reporting), as I don't like its general design. But right now
I'm just working through the main document in a couple of passes.

The table seems to say that other items can be used beyond its defined
set, but it doesn't say that new things *should* be used unless
they're very good matches for the existing ones.

If a client encounters an item that it doesn't recognize, then it
would make a lot of sense for it to display the detail field. If a
server has an error condition that isn't a good match for a message
but uses it anyway, it shouldn't be surprised w/ a bad client
behavior.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Feb 2017 09:33:48 +1100

> Do you have proposed alternate langauge, given the above?

Simply state the the description is designed for human consumption.
It's not localized, but it might help in more precisely identifying
the issue.  Then, let the clients decide what to do with that.