Note draft: caproles -- what is a capability?

[Markus Demleitner]

Dear Registry, dear GWS, dear TCG,

Last summer, we've had quite a discussion on how to represent complex
service interfaces (specifically, TAP) in the age of authentication
and mirrors (see, for instance,
http://mail.ivoa.net/pipermail/dal/2018-September/008080.html).

This discussion made me realise that the way VOSI and Registry have
used capabilities in some specifications was fairly flawed.  We
hadn't realised this because our services were relatively plain
(essentially, one service, one access URL) and that TAP 1.0, the one
widespread protocol that actually required interoperable clients to
use a complex API, did something different (and, fortunately, sane).

I realised that TAP 1.0 did it right in practice and that we should
update our theory rather than let TAP 1.1 follow the theory (which I
had adhered to until then, too), as was planned back then.

At a meeting on authentication in TAP in Trieste this January, I
promised to write up what needs to be done to update our theory.  It
turned out that that still was more of an intellectual effort than I
had expected.  That's why I only now have a draft of that writeup
that hopefully is somewhat readable (in case you don't mind words
like "structuralism").  A precompiled PDF is at

http://docs.g-vo.org/caproles.pdf

I'd be very grateful if you could have a look at it and see if you
spot major oversights (or want to sign up as a co-author).  

>From GWS, I'd be particularly grateful for an assessment of what this
*practically* means for VOSpace -- what software, client and server,
would actually be affected if we moved from capability building
blocks to building blocks within interfaces?  What would it mean for
the standard?  Perhaps regrettably, I have zero experience with
VOSpace both server- and client-side, so I'm depending on you here.

I'm also sending this to the TCG; while I expect that the practical
impact of the proposed changes is fairly minimal, as the flawed
features probably have seen very little use in interoperable clients,
I may of course have missed something.  So, again I'd be grateful if
WG chairs could quickly skim the document for unwarranted claims that
nothing will break.

My schedule is that I'll give it another round of editorial review
near the end of the week and, assuming nobody finds major problems,
submit it to the document repository next Monday.  I'll talk about
this at a Registry session in Paris, too, and I'll be available for
live(ly) discussion(s), too.

Thanks,

          Markus