Text error messages

[Mark Taylor]

Weighing in late on this thread:

On Thu, 18 Jun 2026, Patrick Dowler via dal wrote:

> In my opinion, the "errors in VOTable" were a simple but bad idea and
> we should figure out how to stop requiring it.

I agree with this; requiring services to format errors as VOTables
is unneccessarily burdensome and a bit pointless too, since
clients are going to have to make sense of error messages that
get generated by non-VO-aware communication layers as well as
whatever VO standards dictate.  So I would support moving away
from requiring VOTable formatting in error messages.

On Thu, 18 Jun 2026, Stelios Voutsinas via dal wrote:

> The machine-readable signal is the status code and that's what's
> authoritative (400 means bad parameters, 422 means invalid values, 503 try
> again later)
> The body is context for a human and I would say mandating a specific format
> for it is only justified if some client behaviour depends on parsing it,
> and to my understanding clients just display it. (Though client writers can
> chime in and disagree if this is incorrect)

I also agree with this.  As a client writer, the main thing I want
is a human-readable message I can present to the user.
Additional machine-readable coding is not something that topcat
is likely to act upon.

There are a few exceptions to that, but I think(?) they are
all covered by existing 4xx/5xx HTTP response codes,
e.g. A+A (401/403) and Not Found (404).  But in most cases
topcat/stilts treats any 4xx/5xx code the same: it's an error,
pass on relevant information, including server-generated human-readable
text if any, to the user.

RFC9457 seems to be addressed to the situation where clients
can perform problem-detail-specific actions based on problem
details supplied in an error response.  Such error responses
have to be associated with semantics defined by a "type" member
which is either from the IANA registry at
https://www.iana.org/assignments/http-problem-types/http-problem-types.xhtml
- none of them look much use to us - or which we'd have to define
ourselves.  I am interested in what kind of client behaviour the
advocates of using RFC9457 expect it to be used to initiate.
If the answer is none, this looks like an additional standardisation,
generation and parsing burden without much benefit.

Mark

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/