<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
I realize it is splitting hairs. <br>
<br>
InCommon's <span class="sv-ti-done">"Migrating to the MDQ Service"
(<a class="moz-txt-link-freetext" href="https://spaces.at.internet2.edu/display/MDQ/migrate-to-mdq">https://spaces.at.internet2.edu/display/MDQ/migrate-to-mdq</a>)
speaks to:<br>
<br>
1) retiring the legacy metadata service at </span><span class="sv-ti-done"><b>md.incommon.org</b><br>
2) changing to </span><span class="sv-ti-done"><span style="letter-spacing: 0.0px;">consuming metadata from <b><span class="external-link">mdq.incommon.org</span></b></span><br>
</span><span class="sv-ti-done">3) the legacy </span>metadata
service is approaching the 100MB mark when aggregated & is no
longer sustainable for the vast majority of deployments<br>
4) InCommon will continue to provide aggregates at the new metadata
location, signed with the new key, for the foreseeable future (at
least the next five years), barring an unforeseen event that forces
us to retire aggregates.<br>
<span class="sv-ti-done"><br>
So my read on this is, moving from the <b>md</b> url to the new <b>mdq</b>
url is all that is needed to move to the new mdq service, no
matter how you configure it. The new <b>mdq</b> service supports
(as document by InCommon):<br>
<br>
a) caching the entries as needed by using </span><span class="sv-ti-done">DynamicHTTPMetadataProvider <br>
</span><span class="sv-ti-done">b) caching entries as ne</span>eded
by using DynamicHTTPMetadataProvider + pre-fetching metadata for
specific SPs by using FileBackedHTTPMetadataProvider<br>
<span class="sv-ti-done">
<style type="text/css">p { margin-bottom: 0.1in; direction: ltr; color: #000000; line-height: 115%; text-align: left; orphans: 2; widows: 2; background: transparent }p.western { font-family: "Liberation Serif", serif; font-size: 12pt; so-language: en-US }p.cjk { font-family: "Songti SC"; font-size: 12pt; so-language: zh-CN }p.ctl { font-family: "Arial Unicode MS"; font-size: 12pt; so-language: hi-IN }a:visited { color: #800000; so-language: zxx; text-decoration: underline }code.western { font-family: "Liberation Mono", serif }code.cjk { font-family: "Liberation Mono" }code.ctl { font-family: "Liberation Mono" }a:link { color: #000080; so-language: zxx; text-decoration: underline }</style>c)
caching the entire aggregate by using </span><span class="sv-ti-done">FileBackedHTTPMetadataProvider as supported via
the md service<br>
<br>
Switching to the new mdq service is changing the url. Configuring
for the new mdq for any of its features (based on the needs of the
organization - with one of the above a-c options) is the second
part. While the two can be done together, they should not be
married together to exclusively mean or not mean switching to or
not switching to the new MDQ service.<br>
<br>
While the a benefit to the new mdq service is grabbing only the
metadata (just-in-time) needed by the organization, meaning less
cached metadata. The one negative would be if the mdq site is down
and metadata can not be obtained when using </span><span class="sv-ti-done"><span class="sv-ti-done">DynamicHTTPMetadataProvider
for per-entity or the full aggregate. The advantage on using </span></span><span class="sv-ti-done"><span class="sv-ti-done">FileBackedHTTPMetadataProvider
is having the local copy.<br>
<br>
I'm not saying the uptime of InCommon mdq service is poor, I'm
just trying to have the best of all options available from a
configuration using the mdq service.<br>
<br>
Don <br>
<br>
</span></span>
<div class="moz-cite-prefix">On 2/3/21 12:32 PM, Les LaCroix via
users wrote:<br>
</div>
<blockquote type="cite" cite="mid:CA+0uUd-af_XB_69Xe=qK00jZ6bT=eoUOaH9wg9ckeRF+rjwPJA@mail.gmail.com">
<b><span style="font-size: 10pt; color: rgb(112, 48, 160);
background: rgb(255, 235, 156);">CAUTION:
</span></b><span style="font-size: 10pt; color: black;
background: rgb(255, 235, 156);">This email originated from
outside of JMU. Do not click links or open attachments unless
you recognize the sender and know the content is safe.</span>
<hr>
<div>
<div dir="ltr">
<div class="gmail_default" style="font-family:trebuchet
ms,sans-serif;font-size:small;color:#073763">
Donald,</div>
<div class="gmail_default" style="font-family:trebuchet
ms,sans-serif;font-size:small;color:#073763">
<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px
solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
...the thinking is to initially configure MDQ for "All
Entities"</blockquote>
<div class="gmail_default" style="font-family:trebuchet
ms,sans-serif;font-size:small;color:#073763">
<br>
</div>
<div class="gmail_default" style="font-family:trebuchet
ms,sans-serif;font-size:small;color:#073763">
IIUC you're reading the "Retrieving metadata as aggregates"
section, which lists URLs that can be used with
the FileBackedHTTPMetadataProvider in lieu of the old URLs.
If you replace the URL in your legacy configuration, I
believe that all you are doing is creating an equivalent
file using a new source URL. In my mind, that's not really
"configuring MDQ". Configuring MDQ would be defining a
DynamicHTTPMetadataProvider to use the InCommon MDQ service,
along with removing (or commenting out) the
old FileBackedHTTPMetadataProvider stanza for the old way of
acquiring metadata from InCommon.</div>
<div class="gmail_default" style="font-family:trebuchet
ms,sans-serif;font-size:small;color:#073763">
<br>
</div>
<div class="gmail_default" style="font-family:trebuchet
ms,sans-serif;font-size:small;color:#073763">
-Les</div>
<div>
<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr"><br>
<table style="color:rgb(136,136,136);border:none;border-collapse:collapse">
<tbody>
<tr style="height:0pt;border-top:1pt solid
rgb(204,204,204)">
<td style="border-right:1pt solid
rgb(204,204,204);vertical-align:middle;padding:5pt;overflow:hidden">
<p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.carleton.edu_&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=YuDkHVbNM9swmUy8F09P-iTUoavftOtQrZe4sv7jJ98&s=mPdTXa0OrmpjuXLqvY1x2XImtYgjZp_Nh1X_ZJESw2A&e=" target="_blank" moz-do-not-send="true"><span style="font-size:11pt;font-family:Arial;color:rgb(17,85,204);vertical-align:baseline;white-space:pre-wrap"><span style="border:none;display:inline-block;overflow:hidden;width:70px;height:73px"><img src="https://lh6.googleusercontent.com/QEL1To3Ci_dJA1huaKzfZ0Lf4MaZlAy_f-W3vQjbyzNq_yXq_ZYGv3tuT4dkaZS_bZ5X6fZR4iKzBboZhxbCF5htZFnLNKGqmrzHsVJtsjsy0pfK5w2z0Dlq-EtZcWhv0PxBpWmR" style="margin-left:0px;margin-top:0px" moz-do-not-send="true" width="70" height="73"></span></span></a></p>
</td>
<td style="border-left:1pt solid
rgb(204,204,204);vertical-align:top;padding:10.8pt;overflow:hidden">
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font face="Arial" color="#dea410"><span style="font-size:14.6667px;white-space:pre-wrap"><b>Les LaCroix '79</b></span></font></p>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(11,80,145)"><span style="font-size:11pt;font-family:Arial;vertical-align:baseline;white-space:pre-wrap">Strategic Technologist</span></span></p>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(11,80,145)"><span style="font-size:11pt;font-family:Arial;vertical-align:baseline;white-space:pre-wrap">Information Technology Services</span></span></p>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(11,80,145)"><span style="font-size:11pt;font-family:Arial;vertical-align:baseline;white-space:pre-wrap">t: (507) 222-5455</span></span></p>
</td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Feb 3, 2021 at 11:03
AM Donald Lohr <<a href="mailto:lohrda@jmu.edu" moz-do-not-send="true">lohrda@jmu.edu</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
1) <br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__spaces.at.internet2.edu_display_federation_Download-2BInCommon-2Bmetadata&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=YuDkHVbNM9swmUy8F09P-iTUoavftOtQrZe4sv7jJ98&s=XWPY5gzkRmSP9VR8xuUf6klXpmYZbRb0DV_K-5FuA0g&e=" rel="noreferrer" target="_blank" moz-do-not-send="true">https://spaces.at.internet2.edu/display/federation/Download+InCommon+metadata</a>
<br>
and <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__spaces.at.internet2.edu_display_MDQ_production-2Dmetadata&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=YuDkHVbNM9swmUy8F09P-iTUoavftOtQrZe4sv7jJ98&s=ToxeSKZ5ufyu25ESZCQJd35MqVRWrKT83mP_O63iUJA&e=" rel="noreferrer" target="_blank" moz-do-not-send="true">
https://spaces.at.internet2.edu/display/MDQ/production-metadata</a><br>
<br>
...speaks to their MDQ "akin to legacy" offering which gets
the entire <br>
file.<br>
<br>
2) I believe I just answered my original question. In all
their MDQ <br>
examples DynamicHTTPMetadataProvider is used. In our current
MD (legacy) <br>
configuration FileBackedHTTPMetadataProvider is used.<br>
<br>
Thanks,<br>
Don<br>
<br>
On 2/3/21 11:44 AM, Cantor, Scott wrote:<br>
> CAUTION: This email originated from outside of JMU. Do
not click links or open attachments unless you recognize the
sender and know the content is safe.<br>
> ________________________________<br>
><br>
>> In the new MDQ configuration to support this
"akin to legacy" approach, does it support writing to a file
similar to the<br>
>> old MD service like:<br>
> No. Doing that is something you would do with the older
batch metadata provider by pointing it at that URL. I would
not think InCommon would want that unless they intend people
to move off the old URL for some reason but continue to suck
down the whole file. That's not my impression.<br>
><br>
> -- Scott<br>
><br>
><br>
> --<br>
> For Consortium Member technical support, see <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=kyaNL4qLve7vrv2fAj0zytujAQ87UhscZGPXxDyV9Z0&s=yf5zydTHnILqRhBXTutaKqSbAQDgIh7V7E0XtWJVabA&e=" rel="noreferrer" target="_blank" moz-do-not-send="true">
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=kyaNL4qLve7vrv2fAj0zytujAQ87UhscZGPXxDyV9Z0&s=yf5zydTHnILqRhBXTutaKqSbAQDgIh7V7E0XtWJVabA&e=</a><br>
> To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank" moz-do-not-send="true">
users-unsubscribe@shibboleth.net</a><br>
<br>
-- <br>
D o n a l d L o h r<br>
I n f o r m a t i o n S y s t e m s<br>
J a m e s M a d i s o n U n i v e r s i t y<br>
5 4 0 . 5 6 8 . 3 7 3 0<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=YuDkHVbNM9swmUy8F09P-iTUoavftOtQrZe4sv7jJ98&s=EQ254IY8Tz5fJSwq9vJKTw3qT5Y9eyibfV3okxLOIDg&e=" rel="noreferrer" target="_blank" moz-do-not-send="true">
https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank" moz-do-not-send="true">
users-unsubscribe@shibboleth.net</a><br>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
D o n a l d L o h r
I n f o r m a t i o n S y s t e m s
J a m e s M a d i s o n U n i v e r s i t y
5 4 0 . 5 6 8 . 3 7 3 0
</pre>
</body>
</html>