Jacob Hoffman-Andrews wrote: > 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.
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 > 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? 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. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
