Using role="std" in standard protocol discovery

[Markus Demleitner]

Dear authors of VO applications,

TL;DR: Please update your discovery queries to constrain
intf_role="std" rather than intf_type="vs:ParamHTTP".

In the context of getting the VO Registry ready for a VO with (more)
published authenticated services (and for general tidyness -- see
http://ivoa.net/documents/caproles for more background), we will have
to phase out the RegTAP 1.0 hack of saying "to discover the standard
interface of a VO standard capability, use an interface of type
vs:ParamHTTP" as soon as possible.

I've put in that hack back then because in the RegTAP 1.0 days, there
were many services that did not do the right thing of marking the
standard interfaces with role="std", and it seemed hopeless to fix
all these records.

In RegTAP 1.1 (now in late PR) the recommended query patterns now are
as they were intended by VOResource (see
http://www.ivoa.net/documents/RegTAP/20190529/PR-RegTAP-1.1-20190529.html#tth_sEc10),
essentially like

  SELECT ivoid, access_url
  FROM rr.capability
  NATURAL JOIN rr.interface
  WHERE standard_id like 'ivo://ivoa.net/std/tap%'
    AND intf_role='std'
    AND authenticated_only=0

If, as I suspect, we will have to introduce new interface types
beyond vs:ParamHTTP (my guess for a time scale: a few years), clients
still using the RegTAP 1.0 hack will stop finding the services.  It
would therefore be great if the fixed query patterns could be phased
in just about now (well -- in your next release).

The good news: In the last few months, the Registry community has
managed to clean up the Registry so the correct query pattern at this
point finds all the services that that hacked pattern did [thanks a
lot to everyone who contributed!]; don't take my word for it, see for
yourself:

  select ivoid, intf_type, intf_role, standard_id
    from rr.interface
    natural join rr.capability
    where intf_type='vs:paramhttp'
    and intf_role is null
    and standard_id in (
	    'ivo://ivoa.net/std/tap',
	    'ivo://ivoa.net/std/sia',
	    'ivo://ivoa.net/std/sia#query-2.0',
	    'ivo://ivoa.net/std/ssa',
	    'ivo://ivoa.net/std/conesearch'

at this point returns nothing (on http://dc.g-vo.org/tap; if a
different RegTAP service still returns records on, say, Friday,
please let me know so we can investigate).

        -- Markus