<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Following up on this after having a chance to play with some code and speak with Pat:</p>
<p><br>
</p>
<p>So long as we keep the ability to share the security_method information in the detail table, an existing operational discovery case is met. NAVO's validation/uptime monitor is already using information in the detail table for test queries where available;
a similar search seems possible. (Though it does raise a question of whether we can, even in some convoluted way, query through the various cap and intf indices in res_detail for test queries associated with particular security methods, and I haven't yet tried.)</p>
<p><br>
</p>
<p>The current proposal to add a bit flag (effectively) column per interface for having unauthenticated access or not gives today's clients the info we need today for discovering unsecured/public-access endpoints. We won't be able to remove it without a major
version change. That change could be paired with creating a full table for security method information if it turns out we need it (or technically we could add the table in a minor rev and leave the redundant data, which smells). Are we OK with this? I think
the most involved parties are, if anyone else wants to speak up, please do. We are still hoping to call this done in Paris.</p>
<p><br>
</p>
<p>Cheers,</p>
<p>--Theresa</p>
</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> Tuesday, April 16, 2019 3:31:57 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 Pat,<br>
<br>
On Mon, Apr 15, 2019 at 08:31:47AM -0700, Patrick Dowler wrote:<br>
> A side issue: we have had what I think are under-informed discussions about<br>
> what services actually implement and which securityMethod(s) are actually<br>
> in use in the past. That started from "don't need to register all the<br>
<br>
I'm pretty sure there simply haven't been any securityMethods defined<br>
for many years (except for, IIRC, some astrogrid VOSpace that's now<br>
disappeared) in records that made it to the VO Registry. <br>
<br>
I know that because RegTAP 1.0 (optionally) mapped securityMethod to<br>
the<br>
<br>
/capability/interface/securityMethod/@standardID<br>
<br>
rr.res_details key. RegTAP 1.1 still lets you do that, and<br>
<a href="http://dc.g-vo.org/tap">http://dc.g-vo.org/tap</a> (for instance) does. So, you can run<br>
<br>
select * <br>
from rr.res_detail <br>
where detail_xpath like '%securityMethod%'<br>
<br>
and see what's there.<br>
<br>
> interface/securityMethod combinations" and would continue if we didn't<br>
> capture the set of securityMethod(s) that services used in RegTAP. Then<br>
> later on we either can or cannot use RegTAP to see what's actually in use,<br>
> depending on what gets captured in the relational mapping. I think we will<br>
> want that information in the future.<br>
<br>
So do I; but for this kind of research, we can always just locate the<br>
records that have nonempty securityMethods and pull their full<br>
records from an OAI-PMH endpoint. At least until we've figured out<br>
what to do with this information on the client side (and, more<br>
critically, what information that is), I don't expect there's going<br>
to be prohibitively many such records.<br>
<br>
I guess my point is that I feel "research-level statistics" isn't<br>
quite a sufficient use case for mapping something into RegTAP<br>
("operational statistics" might be a different matter, though).<br>
<br>
-- Markus<br>
</div>
</span></font>
</body>
</html>