RegTAP 1.1, updated PR

[Mark Taylor]

Markus + Reg,

I can think of one discovery use case for securityMethod that
is not satisfied by authenticated_only: client developers looking
for services with diverse security methods against which they can
test their software.  This is not a very important use case,
and such discovery queries certainly don't need to be especially
optimised, especially if it's at a high cost in RegTAP design.
But it would be nice to do.

In absence of the security_method_id in rr.interface, I'd expect to see
a rr.res_details key /capability/interface/securityMethod/@standardID
listed in Appendix A, but the note in the change log Appendix D.1
says you've decided not to do that.  Does the existence of this use
case make a difference?

Mark


On Mon, 6 May 2019, Markus Demleitner wrote:

> Dear Registry WG,
> 
> On the way to RegTAP 1.1, I've uploaded a new PR, with the main
> change that we've pulled the security_method_id from rr.interface; it
> was found that the de-normalisation required to have it is a large
> implementation burden, because there is a foreign key into interface
> from intf_param, and thus everything in there would need to be
> duplicated as well.
> 
> Instead, there's now a column authenticated_only that satisfies the
> only discovery use case we have identified so far for securityMethod.
> Additional use cases will probably require an extra
> rr.security_method table, but waiting for these to become clearer
> should IMHO not delay RegTAP 1.1.
> 
> Theresa and I hope this is what the basis for the RFC will be.  So --
> please have a look.
> 
> Thanks,
> 
>           Markus
> 

--
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/