On 01/02/15 21:29, Paul Eggert wrote: >> it does make sense to provide a >> "full set of tz data" option in the protocol to allow clients to get >> the entire >> set of current data without exposing which specific time zone(s) they are >> actually interested in (which would also remove the need for them to >> use etags). > > Yes. Although clients could omit etags, my guess is that it'd be OK in > most cases privacy-wise to use them, so long as the etags are global > (one per tz database version, e.g., "tz2015a") rather than > per-server-and-database-version (e.g., > "tz2015a-04F56E6866304E628CA1C45B"). That way, etags should provide > little tracking info. A bonus is that a client could switch servers > without having to re-get the tz database from the new server.
A debate on how an etag is generated on another list implies that is should include a hash of the data, but I am sure that the spec does not require that and allows a fully defined etag? The strong/weak element could come into play where the 'style' of data is an addition, but every reply with a 'tz2015a' head would contain the same core data (ignoring backzone problem). I'm not sure if that is necessary if the request identifies the correct style required, but either way the tag itself is generic world wide and can be accepted when a different server has to be accessed for any reason. In the context of the 'changedsince', asking for 'latest' where one is currently using 'tz2014j' will return a new packet with 'tz2015a' while asking for 'changedsince=tz2014j' will return just the differences. If 'latest' returns a complete data dump then the local machine has to work out if there are any changes which require further work, while the difference set if sent as a simple list of TZid's allows the client to ignore any update they are not using id's from. It is up to them if they download a 'full dump', just the TZid's that have changed, or only the one's they are using. For embedded devices asking for a simple 'expand' etag will give them a 'same' message until the version changes. If there is a version change, but it does not affect the content of this particular packet then one could say that they don't need to do anything, but given that this is such a rare occurrence, simply downloading again is fine. If the client does need to know if the next transition has changed then that is best handled locally. For this action I don't see that downloading a complete data set is necessary at all? Since the cache mechanism will time out at regular intervals, even the etag mechanism will give a reply when nothing has changed? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk _______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
