x-www-form-urlencoded prohibition

[Mark Taylor]

Russ,

thank you for the wealth of technical detail that you've posted.
I have not attempted to absorb much of it so far, but I'm sure it will
be an extremely useful resource as the proposed changes are considered.

However I have a comment on this point:

On Thu, 23 May 2024, Russ Allbery via grid wrote:

> Paul Harrison via grid <grid at ivoa.net> writes:
> 
> > In the recent P3T session, someone (I think Alberto Micol) pointed out
> > that the proposed deprecation of x-www-form-urlencoded POSTs was a big
> > change - and I agree it is probably the most disruptive change to
> > protocols that is being suggested
> 
> In our last discussion, I suggested that one of the encodings that we
> could standardize as part of the new framework could be
> x-www-form-urlencoded POST.  It sounds like there was a lot of interest in
> this specific use case, which makes me further convinced that this would
> be a good idea.  That also solves one of the questions we had, namely what
> second useful network encoding to define alongside RESTful JSON to ensure
> that the framework for multiple encodings worked correctly.
> 
> That encoding, as discussed below, has different security properties than
> RESTful JSON that would need to be discussed, and some sites may choose
> not to implement it.  This is fine; that's exactly the point of having a
> layered standard.  It gives us a clear place to discuss general properties
> of the encoding that apply to any service that uses that encoding, and it
> will provide a way for sites to advertise exactly what they implement.

I do not support the idea of drawing up a menu of optional APIs
from which different sites can choose which options to offer.

The situation at the moment is that any service offering a cone search,
and any client wanting to execute a cone search, have exactly one
way to talk to each other.  This is how you get interoperability.
The effect of defining API options which "some sites may choose 
not to implement" is that low-effort clients will just choose the 
option they find easiest to work with and be unable to work with 
some fraction of the services, while high-effort clients will have 
to implement all the different options to support all available 
services, and would require protocol negotiation of some sort to boot.

If a decision is made to ditch x-www-form-urlencoded POSTs
in favour of JSON as the required API for TAP et al.,
I see no benefit, and some harm, in standardising a set of
additional optional APIs that communicate the same thing
in different ways to sit alongside that.

Mark

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