TAP 1.1 authentication

[Mark Taylor]

Pat,

On Wed, 12 Sep 2018, Patrick Dowler wrote:

> On the whole topic of base URL vs usable endpoints:
> 
> I have been convinced for a long time that the whole approach we took in
> TAP-1.0 (8+ years ago) was wrong. We did specify that TAP has both sync and
> async query execution but we tried to pretend that it was one thing instead
> of two things. VOSpace has several different endpoints that behave
> differently and they are separate capabilities. If sync and async were just
> treated as separate capabilities from the start we would not have this
> problem and we don't have this problem with any other services.
> 
> On Wed, 12 Sep 2018 at 09:17, Paul Harrison <paul.harrison at manchester.ac.uk>
> wrote:
> >
> and blurs the distinction about what *the* URL of a service is
> 
> In my mind this idea is wrong and has always been wrong -- there is no
> *the* URL of a (TAP) service that is directly usable (eg that you can POST
> to) --  but we (DAL-WG and TAP-1.0 authors) had to make compromises to get
> TAP-1.0 to REC. We got the cardinality of
> service-capability-interface-accessURL wrong. It is more complicated than
> that because you have to just know to append one more special strings to
> the path to create usable URLs. That makes TAP special, which is sad when
> VOSI-capabilities is perfectly capable of describing endpoints so you don't
> need bespoke solutions and knowledge and we have proven that one can write
> and use a generic capabilities client to work out all the details.
> I am not arguing that it is impossible to comply with VOSI and DALI and
> keep a facade of "the URL" in TAP-1.1, but all the things needed to do that

[you did argue exactly that in your RFC comment dated 2018-08-23:

   "But: the only way to go the bundle way is for TAP-1.1 to violate
    DALI-1.1 and/or retract that bit from DALI (admit mistake;
    issue erratum)."
]

> and avoid fixing the mistakes of TAP-1.0 make TAP more special and bespoke
> and less like the standard patterns in other services and the spirit of
> upstream standards. That means more text, more unforeseen consequences of
> that text, and less flexibility to use other standards to the fullest. It
> also means more code specific to TAP.
> 
> If you still disagree with my claim that there is no "the URL to a TAP
> service" and there doesn't need to be one, then stop reading now because
> the rest is about how to fix things.

So, I stopped reading.  To a client like TOPCAT or taplint, and to
the users of such a client, the TAP service feels like one thing
not a loose assembly of half a dozen things and it's helpful to be able
to address it thus.  The fact that you have to "just know to append
one more special strings to the path to create usable URLs" really
doesn't seem like a big problem to me - the table in section 2,
minus the service-specific lines, is not very difficult to understand
(compared either to the rest of the TAP protocol stack,
or to the UWSRegExt Note plus the language introduced at my request
in PR-TAP-1.1-20180830 that we need to make authenticated services
usable now).  The benefits of what Paul nicely called the TAP URL
"that I can cut and paste into an email/twitter message etc."
are to me considerable - I very often use TAP base URLs by e.g.
passing them to topcat/stilts to identify a TAP service,
or using curl and just slapping a "/tables" etc on the end.

I suppose which option you like is driven by what clients you have.
If you're thinking about generic VOSI/DALI clients, then reading
capabilities documents is a given, and TAP-specific rules are a pain.
If you're thinking about task-specific clients like topcat's TAP
window, a single base URL makes sense and TAP-specific rules are
no problem.  To me, TAP is such an important standard from a
user point of view that bending, special-casing or stepping outside
some of the generic rules to improve its usability is well
worth doing.

As you can tell, I don't agree with your arguments; I think doing
it this way will make things more complicated for TAP client authors
and TAP service users.  But, I get the impression you're not about to
change your mind, so unless others want to weigh in I'll stop
fighting and try to implement it.  For now, this feels to me like
somewhat special-interest stuff since the default fixed endpoints
are still present for TAP-1.0 compatibility, and it's only for the
few authenticated services out there that people are going to have
to go dredging through capabilities files to locate endpoints.
If I thought that TAP 2.0 with capabilities-only endpoint location
was coming any time soon I'd be more worked up about it.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/