Per-Entity Metadata Working Group

[Nick Roy <>]

Thanks Ian, this is very helpful for my understanding of the relevant 
interactions.

Nick

On 9/20/16 4:06 AM, Ian Young wrote:
> > On 14 Sep 2016, at 17:41, Nick Roy 
> > <>
> >  wrote:
> >
> > Just my personal opinions, take with appropriate grain(s) of salt.
> [...]
>
> > > 2) Does the server need to support HTTP Conditional GET?
> > I don't see why - any change to a _signed_ entity descriptor would probably 
> > mean the entire signed entity descriptor needs to get completely re-retrieved.
> Yes, by definition, if something changes then you need to fetch it again; 
> there's no provision for retrieval of partial documents in the specs.
>
> It's possible that you mean that any change to the aggregate probably means 
> all the per-entity metadata needs to be re-signed and that will result in a 
> need to re-retrieve any per-entity metadata. That's pretty much true with the 
> current production implementation, but it isn't necessarily a permanent 
> characteristic. There is nothing that says that the validUntil has to be the 
> same for all entities at any given instant, so the MDQ server (or batch 
> signer) could in principle retain older signed metadata for individual 
> entities through signing events. Whether that's worth doing would need some 
> thought, but there is implementation flexibility here (server-side or as part 
> of the tooling) if it looks like a worthwhile optimisation at some point in 
> the future.
>
> [...]
>
> > > 4) Is there a cacheDuration on each entity descriptor, and if so, what
> > > is its value?
> > I think the answer to this depends on how frequently we intend to publish new 
> > signed metadata, so currently, maybe put it at 2 hours to ensure changes are 
> > picked up in a relatively timely fashion, but we aren't hammering the servers 
> > too hard.
> If you want to push down the value of cacheDuration for whatever reason, the 
> ability to support conditional GET at the server end becomes more important 
> because the likelihood that the GET will be satisfied by what the client 
> already has becomes higher. As Scott points out, you're not only re-fetching 
> the document (with bandwidth implications, but also with latency implications 
> for the client if you're not hiding that latency in a background pre-fetch 
> thread, which at present we don't), but you're probably doing other work on 
> receipt as well.
>
> Conditional GET is simple to support, and I can't think of any reasons not to do so in 
> practice. The MDQ spec requires responders to pass out the appropriate headers, and 
> requires clients to make use of conditional GET for requests "to the same 
> URL", but in practice the server could ignore that.
>
>      -- Ian