Per-Entity Metadata Working Group

[Tom Mitchell <>]

+1

If the MDQ protocol really is straight up HTTP documents, which it appears to be by design, there should be ample opportunity to make those documents highly available via CDNs or similar.

Is there a more recent update to the MDQ protocol than the one that expires October 26, 2015 (https://www.ietf.org/archive/id/draft-young-md-query-05.txt)?

Thanks,

Tom

On Jul 27, 2016, at 4:46 PM, Nick Roy <> wrote:

If we design the service to be highly available, I don't think we need to worry about on-disk cache, which as Scott has mentioned is at the expense of the ability of other non-Shibboleth clients to support the same assumed requirement.  I think we should focus on a highly available per-entity metadata delivery architecture with the assumption that many clients will never have the ability to support the on-disk caching.

That said, if others want to run their own local copy, why don't they just stand up local HTTP proxies?  This isn't that difficult for them, but I think that part of the equation is out of scope for this group.

Nick

On 7/27/16, 1:33 PM, " on behalf of Cantor, Scott" < on behalf of > wrote:

   On 7/27/16, 3:20 PM, " on behalf of Tom Scavo" < on behalf of > wrote:

What's the difference? I'm talking about HTTP 304, not HTTP 404.

   Well, one is an error, one is not.

You are absolutely correct but I claim a two-week outage of the
aggregates served from md.incommon.org has probability zero.

   And I claim a two week outage of an MDQ service is pretty much also probability zero. Still not getting it. I really just missed the point of the example.

From where I sit, aggregate distribution and per-entity distribution
are like apples and oranges.

   I do understand that one can tolerate outages that are an order of magnitude larger, but in terms of fundamental requirements, they're both potentially a highly redundant web presence serving static documents. That's apples and some other more expensive kind of apples to me.

   But I seem to be in the minority on this, so maybe we could focus this discussion on your original subject line. What exactly do people need us to implement? At minimum, on-disk cache, clearly.

   -- Scott