<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<p>Just a note that the STScI fully searchable registry is now running RegTAP 1.1 operationally, using this latest version of the spec. This makes for two reference implementations and a general consensus, so we're set for RFC in Paris. (and I hope to see many
of you there.)</p>
<p><br>
</p>
<p>--Theresa</p>
<br>
<div style="color: rgb(0, 0, 0);">
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> registry-bounces@ivoa.net <registry-bounces@ivoa.net> on behalf of Markus Demleitner <msdemlei@ari.uni-heidelberg.de><br>
<b>Sent:</b> Thursday, April 25, 2019 3:37 AM<br>
<b>To:</b> registry@ivoa.net<br>
<b>Subject:</b> Re: Late RegTAP rr.interface update [was: rr.interface+auth=ouch]</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi Theresa,<br>
<br>
On Wed, Apr 24, 2019 at 04:41:52PM +0000, Theresa Dower wrote:<br>
> case is met. NAVO's validation/uptime monitor is already using<br>
> information in the detail table for test queries where available; a<br>
> similar search seems possible. (Though it does raise a question of<br>
> whether we can, even in some convoluted way, query through the<br>
> various cap and intf indices in res_detail for test queries<br>
> associated with particular security methods, and I haven't yet<br>
> tried.)<br>
<br>
With the traditional model of test queries attached to capabilities<br>
that's implied -- the same test query is expected to run on each<br>
interface (which becomes somewhat questionable with SSA's<br>
queryDataCmd, but then I don't see we'll ever have something other<br>
than vs:ParamHTTP for SSA).<br>
<br>
With VOResource 1.1, people can attach testQueryStrings to interfaces<br>
(where they, really, belong). RegTAP 1.1 doesn't (properly) map<br>
these, the logic being that they aren't really user interface (we<br>
could still change this, claiming validators are users, too). If I<br>
ran a validator with the current draft, I'd add a local<br>
test_query_string column to my rr.interface table.<br>
<br>
> The current proposal to add a bit flag (effectively) column per<br>
> interface for having unauthenticated access or not gives today's<br>
> clients the info we need today for discovering<br>
> unsecured/public-access endpoints. We won't be able to remove it<br>
> without a major version change. That change could be paired with<br>
<br>
I don't think we should remove it later, as I suspect the use case we<br>
have for it now will stay dominant. If and when we will have<br>
finer-grained auth info later, I expect replicating with it what we'd<br>
do with authenticated_only now will be more fuss for clients than<br>
keeping the column will be for RegTAP services. So: I'd argue it<br>
should be there for... well, what part of eternity we can reasonably<br>
predict.<br>
<br>
> creating a full table for security method information if it turns<br>
> out we need it (or technically we could add the table in a minor<br>
> rev and leave the redundant data, which smells). Are we OK with<br>
<br>
I give you there is a slight odour in the air above<br>
authenticated_only and a future rr.security_method table. But I'd<br>
say it's still safely on the good side of the fragnance-stink<br>
line.<br>
<br>
-- Markus<br>
</div>
</span></font></div>
</div>
</body>
</html>