[p3t] Structured error messages and RFC 7807

[Russ Allbery]

Dave Morris via p3t <p3t at ivoa.net> writes:

> Apparently RFC7807 has been replaced by RFC9457, which is almost but not
> quite the same.

> https://blog.frankel.ch/problem-details-http-apis/

> https://datatracker.ietf.org/doc/html/rfc9457

Ah, yes, thank you!  There's now a registry, so if we did define some
IVOA-specific problem types, we could register their URIs and make them
easier to find.

Message templates are an interesting question.  Off the top of my head, I
can see two different approaches that look like they would work with this
standard, with different trade-offs:

* Put the message template into detail, and then put the fields it
  references into separate problem fields, either at the top level of the
  data structure or (probably better) under a key that contains the values
  of variables.

* Put the fully-expanded template (with all the variables substituted in)
  into detail, and define new fields for the template and its variables.

The second is probably a bit friendlier to any clients that know about
the data type but don't know anything about the IVOA standard, but it's
duplicative (that may not really matter).  The first is a bit cleaner, but
it means unaware clients may get the unexpanded detail text.

It looks like title is supposed to be invariant for all instances of a
given problem type, so I think the way this standard is intended to be
used is that we register a problem type for each general class of error?
That part isn't clear to me: whether the IVOA should register one (or a
small number) of problem types and put all the variation into details, or
whether we should register every error we define as a separate problem
type.  The registry is almost empty; the only additional problem types
registered outside of the one in this RFC are two from the RFC for
oblivious HTTP.

It's worth noting that this standard also defines an XML schema, so in
theory we could retrofit existing services that don't have well-defined
error handling to the same general standard without switching them to
JSON.  I think most existing services tend to use VOTables to communicate
errors, though.

-- 
Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>