RegTAP 1.1 PR

[Markus Demleitner]

Hi Mark,

On Thu, Sep 27, 2018 at 11:42:09AM +0100, Mark Taylor wrote:
> On Wed, 1 Aug 2018, Markus Demleitner wrote:
> > I've uploaded a Proposed Recommendation for RegTAP 1.1 to the
> > document repository.  Here's the changelog since WD-20171206:
> 
> I have a comment/query on the RegTAP 1.1 PR, concerning security method IDs.
> The change log in appendix E.2 says:
> 
>    "securityMethod/@standardID is now included in interface in a
>     security_method_id column. Consequently, the
>     /capability/interface/securityMethod/@standardID res_detail key
>     has been removed (but services can of course still provide it)."
> 
> This removal of a standard key could be seen as a backwards compatibility
> violation.  In practical terms, a client now has to know whether it's

Ye-es.  However, I don't think there has ever been such a key in the
registry, and there certainly is none now -- the whole securityMethod
business is quite obviously an example of specification without
implementation, which usually results in trouble.  As is the case
here.

Anyway, since there's probably never been a securityMethod row in
rr.res_details, I can't imagine that any actual code does anything
sensible with such rows.  I'd dearly like to get rid of them, though,
because they talk about interfaces, where res_detail is only designed
to go to the capability level.  It's therefore doubtful if any actual
code even *could* do something sensible with it if it tried to.

> talking to a RegTAP 1.0 or RegTAP 1.1 service in order to know where
> to look for the security method ID information, so if it's not 1.1-aware
> it may not find security method information that a RegTAP 1.1 service
> is providing.  For backward compatibility reasons, I would therefore
> suggest that the res_detail key stays put, and a SHOULD is introduced
> to encourage 1.1 services to duplicate the security_method_id content
> from rr.interface in rr.detail.
> 
> What do you think?

My reasoning was that both VOResource 1.0 and RegTAP 1.0 are
insufficient to support registry-based discovery of services with
restricted access, and hence neither should be used when dealing with
them.  That was also the reasoning behind the
non-quite-ok-for-a-point-release changes to securityMethod in
VOResource 1.1.

In that sense my hope has been that if you need to work with
securityMethod, you can already rely on the 1.1 versions of the
underlying standards.  I give you we're not quite there yet for the
whole VO, but: how hard would it be to structure your discovery that
you simply disable all authentication-related functionality when you
talk to a RegTAP 1.0 service?

        -- Markus